From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2322.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc2322.txt (limited to 'doc/rfc/rfc2322.txt') diff --git a/doc/rfc/rfc2322.txt b/doc/rfc/rfc2322.txt new file mode 100644 index 0000000..4c403db --- /dev/null +++ b/doc/rfc/rfc2322.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group K. van den Hout +Request for Comments: 2322 HvU/HIP-networkteam +Category: Informational A. Koopal + UUnet NL/HIP-networkteam + R. van Mook + University of Twente/HIP-networkteam + 1 April 1998 + + + Management of IP numbers by peg-dhcp + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Introduction + + This RFC describes a protocol to dynamically hand out ip-numbers on + field networks and small events that don't necessarily have a clear + organisational body. + + It can also provide some fixed additional fields global for all + clients like netmask and even autoproxyconfigs. It does not depend on + a particular ip-stack. + +History of the protocol. + + The practice of using pegs for assigning IP-numbers was first used at + the HIP event (http://www.hip97.nl/). HIP stands for Hacking In + Progress, a large three-day event where more then a thousand hackers + from all over the world gathered. This event needed to have a TCP/IP + lan with an Internet connection. Visitors and participants of the + 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 how + to assign IP-numbers on such a large scale as was predicted for the + event without running into troubles like assigning duplicate numbers + or skipping numbers. Due to the variety of expected computers with + associated IP stacks a software solution like a Unix DHCP server + would probably not function for all cases and create unexpected + 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 out + to people to use on their computers had to be devised. After some + discussion, the idea came up of using wooden clothes-pegs. Using pegs + has the following advantages in respect to other methods: + + - cheap + - a peg is a 'token' and represents one IP-number, therefore + making the status of the IP-number (allocated or not allocated) + visible. + - a peg can be clipped to a network cable giving a very clear + view of where a given IP-number is in use. + + Credits for the original idea of using wooden pegs go to Daniel + Ockeloen. + +The server. + + The server can have many appearances. At HIP it was a large tent + situated at the central field where all the activities were. It can + 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 paper + 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 be + described according to the following BNF: + + Total ::== IP | Net + + IP ::== num.num.num.num | num.num | num + + Net ::== num.num.num/mask | num.num/mask | num/mask + + num ::== {1..255} + + mask ::== {8..31} + + The Net-method of writing larger nets is an optional part of the + protocol, it doesn't have to be implemented. If it is implemented, it + requires more administration at the server (see below). + + The short versions of the IP-number with only 1 or 2 chunks are meant + for large servers where writing the whole number on the peg is just + boring and time-consuming. It requires the prefix to be mentioned on + the additional field paper, but that can be produced in more + + + +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. It + 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 of + subnetting has to be implemented it is possible to give the pegs from + the different subnets different colors. This has proven to be a very + 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 with + the peg or as a large paper billboard hung at a convenient place + where everybody can read it. + + The information can be described with the following BNF: + + Network ::== num.num.num.num + + Netmask ::== num.num.num.num | num + + Gateway ::== num.num.num.num | num.num | num + + Proxy ::== num.num.num.num:port | num.num:port | num:port + + Paper ::== Network Netmask Gateway Proxy | Network Netmask Gateway + + num ::== {0..255} + + port ::== {1..65535} + + The paper and the peg are of course one part, if two numbers are used + on the peg, two numbers are used on the paper. + + Because it is fixed information, it can be produced with means of + mass-production (printing, copying). + +The IP-repository + + 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 out + attached to it. If you work with different subnets, it is convenient + to group the pegs for the different subnets (colors). + + At large networks where it is not really known how many IP-numbers + are needed, a first set of pegs can be made in advance, and the + administration of produced pegs kept on paper so it is known for + which numbers pegs have already been made. If use is made of the + + + +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 be + 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 on + how secure and controlled you want the process, the client has to ask + for a peg to a responsible person, or he or she can just get a peg + from store himself. + + If someone could apply for a networkrange, and he net-extension isn't + used, coat-hangers can be prepared with sets of pegs attached to + them. + + The vendorfields paper doesn't have to be issued with every peg, it + is only needed when wanted. + +Reclaiming and reusing IP-numbers. + + It is not easy to implement a TTL in this protocol. One obvious TTL + is the duration of the event after which the IP-numbers are not valid + anymore. + + However, if a client decides that it doesn't need an IP-number + anymore it can bring the peg back to the server. + + The server should at that point decide what to do, if desired, it can + bring the peg back into the pool (attach it to the clothes-line + again). + + If the server is not manned (the client has to help themselves), the + only thing possible is that the client just places the peg back into + the pool. + +The client side. + + The optimum location for the peg is clipped to the network cable near + the NIC of the device needing an IP-number allocated. This ensures a + clear visual connection between the device and the IP-number + allocated and makes it an easy task to see which IP-number is + allocated. + + Transfer of the IP information from the peg and the additional + vendorfield paper note to the settings in the IP stack is done by + human transfer. A person reads the information from the peg and from + the additional information and enters this in the configuration of + the used IP stack. This transfer is not completely free of + + + +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 on + the peg. + + A certain amount of knowledge of the logic of IP settings is also + assumed on the part of the person transferring the information. + + Other information on the vendorfield paper note has to be transferred + to the settings within specific application programs. + +Use with other protocols + + This protocol could be combined with avian carriers as described in + RFC 1149 to hand out IP-numbers remote. + + At the first avian carrier, the peg is clipped to the leg of the + carrier after rolling the additional vendorfield paper around it. + + The remote site can take the peg on arrival of the avian carrier and + use the information on it. + + This part of the protocol is still experimental and requires some + additional research on topics like the weight of the peg and loss of + the peg/whole carrier. + +Security Considerations + + Some remarks about security can be made. + + Pegs are small devices and can be lost. At that time, the IP-number + which was lost can't be used anymore because someone else can find + the peg and use the information stored on it. But, once the peg is + attached to a network cable, the chance to loose the peg is + 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 from + peg to IP stack, the information can be misinterpreted, which could + cause network troubles. In the field test at HIP this became + perfectly clear when someone mixed up the numbers and used the + address from the default router as his IP-number, rendering the + 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' Addresses + + Koos van den Hout + Hogeschool van Utrecht / Expertisecentrum Cetis + P.O. box 85029 + 3508 AA Utrecht + The Netherlands + + Phone: +31-30-2586287 + Fax: +31-30-2586292 + EMail: koos@cetis.hvu.nl + + + Andre Koopal + UUnet Netherlands + P.O. box 12954 + 1100 AZ AMSTERDAM + The Netherlands + + Phone: +31-20-4952727 + Fax: +31-20-4952737 + EMail: andre@NL.net + + + Remco van Mook + Van Mook Consulting + Calslaan 10-31 + 7522 MA Enschede + The Netherlands + + Phone: +31-53-4895267 + EMail: remco@sateh.com + + + + + + + + + + + + + + + + + + + +van den Hout, et. al. Informational [Page 6] + +RFC 2322 Management of IP numbers by peg-dhcp 1 April 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +van den Hout, et. al. Informational [Page 7] + -- cgit v1.2.3