分享
 
 
 

RFC2322 - Management of IP numbers by peg-dhcp

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

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 RFCdescribes 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.

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

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

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

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

RFC1149 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.

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

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.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有