Re: First draft of the European Template for IP number requests
Format: quantity of numbers requested followed by class of request.
Example - req-typ: 1 class C
In making the application, please be guided by the following EXAMPLES of number of hosts which relate to the quantity of network numbers requested:
1 class C number (up to 255 hosts) 2 class C numbers (up to 510 hosts) 4 class C numbers (up to 1020 hosts) 8 class C numbers (up to 2040 hosts) 16 class C numbers (up to 4080 hosts) 32 class C numbers (up to 8160 hosts)
I have for a while looked at these host numbers as somewhat inaccurate, primarily since this does not take subnetting into account. If you subnet a class C network number (as some people end up doing, as was mentioned by Peter Koch, since sometimes people have a small number of hosts at a given site), you *always* waste address space, since subnet 0 and -1 and host 0 and -1 can (normally) not be used. Thus, the best utilization one can make of a subnetted class C network number is around 75% (if I haven't made an error in my calculation). If there is a need for two large subnets, the largest potential utilization immediately drops to around 50%. It is good to see that the number of subnets is asked for. In connection with this, this is a part of a relatively recent addition to the form I use: + Since there is a danger of IP addresses becoming a scarce resource, + there is a general desire to reduce the waste of IP addresses. + Therefore, please take the following points into consideration when you + evaluate your own need for IP addresses: + - A class C network may also be subnetted, and the subnet mask can at + least be chosen separately for each class C network. You should + probably consider adopting the strategy for assignment of host and + subnet numbers outlined in RFC 1219. + - Newer routing protocols (OSPF) may support variable length subnet + masks. Likewise, if you use OSPF, you may tie together different + pieces of a subnetted network with (pieceds of) another IP network. + Ok, the reference to OSPF is probably too technical for this type of form (and it is perhaps also a bit too advanced for most people), but you get the direction I was thinking in. Sometimes, people do not know (or "want" to know) about subnetting C numbers, but I generally disregard arguments of administrative ease and such... :-)
host-0: Please state the number of machines in your organisation that currently require a unique IP network number (hosts).
The term 'host' often causes confusion here, which may be a local language problem. Hosts are often thought of as > x m^3 big :-) An explanatory text should explicitly tell people to take also into account PCs (terminal servers ...) and the like.
Yep. "Each and every box requiring a separate IP address is considered a host in this terminology." is probably something in the direction of what you want (?).
Somewhere in the information package (here or in (c)) requestors should be guided to not forget transit networks when calculating their needs. And, in close relation with that, people should be asked to give an overview of the size of the different subnets, e.g. 17 subnets, 10 with < 20 hosts, the rest with up to 120 machines. This is often the case when large companies (e.g. insurance comp.) have some central administration and a number of regional offices.
I completely agree. Should one mention unnumbered P-P serial links as a possibility? Or is this again too technical?
provider: Please state whether you have an IP service provider. An "IP service provider" is an organisation which can provide you with connectivity external to your network.
This seems to assume that the applicant already has established relations with an IP service provider, which does not need to be the case. However, people most often know if they are going to connect to a service provider, and who that would be. Unfortunately, I have to agree with Duncan Rogerson that I also don't really like the appearence of the new form too much. The main objection I have goes in the same direction as Duncan's, I think, as I see no reason to "formalize" the application form in the style of the RIPE database entries, as long as this data isn't going to be stored in such a system. I also agree with Duncan that explanatory text should be interspersed with the registration information (at least short versions of it, as shown by Duncan). My initial gut reaction was also that this form looked too complicated for most people to grasp and understand easily, and that this thus may cause more load on us, the delegated registries, explaining what needs to be filled in and what can be left out in each case. In my form I have a "nic-hdl" entry for the persons in addition to address, phone etc., and even though I have stated The nic-hdl is optional, as explained in the attached document (ripe-50). I still get questions about it (ok, not many, but you probably see my point...) - Havard
Havard.Eidnes@runit.sintef.no writes: * > > Format: quantity of numbers requested followed by class of req * uest. * > > * > > Example - req-typ: 1 class C * > > * > > In making the application, please be guided by the following * > > EXAMPLES of number of hosts which relate to the quantity of * > > network numbers requested: * > > * > > 1 class C number (up to 255 hosts) * > > 2 class C numbers (up to 510 hosts) * > > 4 class C numbers (up to 1020 hosts) * > > 8 class C numbers (up to 2040 hosts) * > > 16 class C numbers (up to 4080 hosts) * > > 32 class C numbers (up to 8160 hosts) * * I have for a while looked at these host numbers as somewhat inaccurate, * primarily since this does not take subnetting into account. If you subnet * a class C network number (as some people end up doing, as was mentioned by * Peter Koch, since sometimes people have a small number of hosts at a given * site), you *always* waste address space, since subnet 0 and -1 and host 0 * and -1 can (normally) not be used. Thus, the best utilization one can make * of a subnetted class C network number is around 75% (if I haven't made an * error in my calculation). If there is a need for two large subnets, the * largest potential utilization immediately drops to around 50%. Not quite sure what you mean here. What do you consider the best utilization of a subnetted class C address ? If you split up the C net in 32 hosts parts (actually 31), you loose hostnumbers 0,32,64,96,128,160,192,224 and 255 (which is 9 hostsnumbers out of 255 ~ 3.5%). With two large subnets you loose hostnumbers 0,128 and 255 which is around 1%. The only thing is that you will have to convince people to pack their network numbers as good as possible. * It is good to see that the number of subnets is asked for. Exactly, and I think that the mix of number of hosts and subnets is a good indication for the registries to base the assigments on. I do not think that one should simply give whatever they ask for. We have had more than one case where people had 1500 hosts on 50 subnets and asked for 50 class Cs. You really want these people to only use up 8 or maybe 16 Cs. Besides if you compare the hosts and subnet predictions together with the number of nets they request, you get a fair idea whether of not they have any idea what they are doing ;-) -Marten
Marten.Terpstra@ripe.net writes:
Havard.Eidnes@runit.sintef.no writes:
[...]
* I have for a while looked at these host numbers as somewhat inaccurate, * primarily since this does not take subnetting into account. If you subne t * a class C network number (as some people end up doing, as was mentioned b y * Peter Koch, since sometimes people have a small number of hosts at a give n * site), you *always* waste address space, since subnet 0 and -1 and host 0 * and -1 can (normally) not be used. Thus, the best utilization one can ma ke * of a subnetted class C network number is around 75% (if I haven't made an * error in my calculation). If there is a need for two large subnets, the * largest potential utilization immediately drops to around 50%.
Not quite sure what you mean here. What do you consider the best utilization of a subnetted class C address ? If you split up the C net in 32 hosts parts (actually 31), you loose hostnumbers 0,32,64,96,128,160,192,224 and 255 (which is 9 hostsnumbers out of 255 ~ 3.5%). With two large subnets you loose hostnumbers 0,128 and 255 which is around 1%. The only thing is that you will have to convince people to pack their network numbers as good as possible.
If you have the need for two large subnets, you have to use a mask of 2:6 (see below). This is bad, we have in some cases seen subnets of size 50-70 and then had to assign one C address for each of them. If you actually use subnetting 3:5, you have 2^3-2=6 subnets with 2^5-2=30 hosts each. You have a maximum of 180 hosts here (router(s) not taken into account), an unsubnetted network would offer 254, so this is about 71 %. Looking at all possible subnet masks, you get: subnet mask | # subnets | # hosts/subnet | total # hosts | usage -------------+------------+----------------+---------------+------ 1:7 | not allowed| | | 2:6 | 2 | 62 | 124 | 49 % 3:5 | 6 | 30 | 180 | 71 % 4:4 | 14 | 14 | 196 | 77 % 5:3 | 30 | 6 | 180 | 71 % 6:2 | 62 | 2 | 124 | 49 % 7:1 | not allowed| | | Percentage is nothing to worry about too much. More address space would be wasted if you would assign a full class C net for every subnet the requestor operates.
* It is good to see that the number of subnets is asked for.
Exactly, and I think that the mix of number of hosts and subnets is a good indication for the registries to base the assigments on. I do not think that one should simply give whatever they ask for. We have had more than one case where people had 1500 hosts on 50 subnets and asked for 50 class Cs. You really want these people to only use up 8 or maybe 16 Cs. Besides if you compare the hosts and subnet predictions together with the number of nets they request, you get a fair idea whether of not they have any idea what they are doing ;-)
Agreed. Peter
"Peter Koch" <pmk@deins.informatik.uni-dortmund.de> writes: * * Marten.Terpstra@ripe.net writes: * * > Havard.Eidnes@runit.sintef.no writes: * * [...] * If you have the need for two large subnets, you have to use a mask of 2:6 * (see below). This is bad, we have in some cases seen subnets of size 50-70 * and * then had to assign one C address for each of them. * * If you actually use subnetting 3:5, you have 2^3-2=6 subnets with * 2^5-2=30 hosts each. You have a maximum of 180 hosts here (router(s) not ta * ken * into account), an unsubnetted network would offer 254, so this is about 71 * %. * * Looking at all possible subnet masks, you get: * * subnet mask | # subnets | # hosts/subnet | total # hosts | usage * -------------+------------+----------------+---------------+------ * 1:7 | not allowed| | | * 2:6 | 2 | 62 | 124 | 49 % * 3:5 | 6 | 30 | 180 | 71 % * 4:4 | 14 | 14 | 196 | 77 % * 5:3 | 30 | 6 | 180 | 71 % * 6:2 | 62 | 2 | 124 | 49 % * 7:1 | not allowed| | | * * Percentage is nothing to worry about too much. * More address space would be wasted if you would assign a full class C net * for every subnet the requestor operates. Sorry about my fantastic calculations. You are of course right. I'll make sure I get some more coffee next time ;-) * Peter -Marten
Looking at all possible subnet masks, you get:
subnet mask | # subnets | # hosts/subnet | total # hosts | usage -------------+------------+----------------+---------------+------ 1:7 | not allowed| | | 2:6 | 2 | 62 | 124 | 49 % 3:5 | 6 | 30 | 180 | 71 % 4:4 | 14 | 14 | 196 | 77 % 5:3 | 30 | 6 | 180 | 71 % 6:2 | 62 | 2 | 124 | 49 % 7:1 | not allowed| | |
Just one probably silly question - why should the subnet mask 1:7 not be allowed? If I get it right, you speak of netmask like 255.255.255.128. Which should let you have two subnets of 126 hosts each. Daniel
Looking at all possible subnet masks, you get:
subnet mask | # subnets | # hosts/subnet | total # hosts | usage -------------+------------+----------------+---------------+------ 1:7 | not allowed| | | 2:6 | 2 | 62 | 124 | 49 % 3:5 | 6 | 30 | 180 | 71 % 4:4 | 14 | 14 | 196 | 77 % 5:3 | 30 | 6 | 180 | 71 % 6:2 | 62 | 2 | 124 | 49 % 7:1 | not allowed| | |
Just one probably silly question - why should the subnet mask 1:7 not be allowed? If I get it right, you speak of netmask like 255.255.255.128.
Your interpretation is correct. The mask 1:7 (as 7:1) is not allowed according to the recommendation to use all zeroes and all ones *neither* in the host part, *nor* in the subnet part.
From RFC1009 [Requirements for Internet gateways], page 6:
RFC1009> The bit positions containing this extended network number are RFC1009> indicated by a 32-bit mask called the "subnet mask" [21]; it is RFC1009> recommended but not required that the <Subnet-number> bits be RFC1009> contiguous and fall between the <Network-number> and the RFC1009> <Host-number> fields. No subnet should be assigned the value RFC1009> zero or -1 (all one bits).
Which should let you have two subnets of 126 hosts each.
Similar reasons might have lead to the following B) In order to prevent implementation problems, network numbers ending with 0 or 255 should NOT be reassigned. found in ripe-72.txt . Just walking off the topic ... Peter
found in ripe-72.txt . Just walking off the topic ...
I think so - valid but - somewhat off the main track of the discussion over the overall format of the proposed European IP forms. more soon... Anne.
Havard.Eidnes@runit.sintef.no writes:
+ Since there is a danger of IP addresses becoming a scarce resource, + there is a general desire to reduce the waste of IP addresses. + Therefore, please take the following points into consideration when yo This is nice - you could be stronger and say there is general consensus on
the need to reduce .... ^^^^^^^^^
u + evaluate your own need for IP addresses:
+ - A class C network may also be subnetted, and the subnet mask can at + least be chosen separately for each class C network. You should + probably consider adopting the strategy for assignment of host and + subnet numbers outlined in RFC 1219.
+ - Newer routing protocols (OSPF) may support variable length subnet + masks. Likewise, if you use OSPF, you may tie together different + pieces of a subnetted network with (pieceds of) another IP network. +
Ok, the reference to OSPF is probably too technical for this type of form (and it is perhaps also a bit too advanced for most people), but you get the direction I was thinking in. Sometimes, people do not know (or "want"
I think it is still valid to mention this somewhere in the documentation. (maybe in the more complete documentation that is planned)
to know) about subnetting C numbers, but I generally disregard arguments of administrative ease and such... :-)
host-0: Please state the number of machines in your organisation that currently require a unique IP network number (hosts).
The term 'host' often causes confusion here, which may be a local languag e problem. Hosts are often thought of as > x m^3 big :-) An explanatory text should explicitly tell people to take also into accou nt PCs (terminal servers ...) and the like.
Yep. "Each and every box requiring a separate IP address is considered a host in this terminology." is probably something in the direction of what you want (?).
or you could simply omit the word "host" and use "machine" as in something like the following text: Please state the number of machines in your organisation that currently require a unique IP network number. Do not forget to include terminal servers and transit networks when calculating this figure.
Somewhere in the information package (here or in (c)) requestors should be guided to not forget transit networks when calculating their needs. And, in close relation with that, people should be asked to give an overview of the size of the different subnets, e.g. 17 subnets, 10 with < 20 hosts, the rest with up to 120 machines. This is often the case when large companies (e.g. insurance comp.) have some central administration and a number of regional offices.
I completely agree. Should one mention unnumbered P-P serial links as a possibility? Or is this again too technical?
I also think this is a good idea.
provider: Please state whether you have an IP service provider. An "IP service provider" is an organisation which can provide you with connectivity external to your network.
This seems to assume that the applicant already has established relations with an IP service provider, which does not need to be the case. However, people most often know if they are going to connect to a service provider, and who that would be.
I disagree - I have had many people answer with an "eh?" when I say "have you got a service provider?" The question is just intended as a double check against those who have got service providers and yet think that they have to go to the US for their network numbers ... it doesnt happen very often..but it does happen.
Unfortunately, I have to agree with Duncan Rogerson that I also don't really like the appearence of the new form too much.
The main objection I have goes in the same direction as Duncan's, I think, as I see no reason to "formalize" the application form in the style of the RIPE database entries, as long as this data isn't going to be stored in such a system. I also agree with Duncan that explanatory text should be interspersed with the registration information (at least short versions of it, as shown by Duncan).
It's true that the information in Parts B, C and D is not needed for the RIPE database and therefore strictly there is no need to request the information in such a format from the user. The rationale was, that it would be easier to move the forms between NICs and to keep this very minimal form in English. However if it is felt that the trade off for such a form is lots of confused users (= lots of queries to the NICs), then it obviously won't be worth it. Might it be worth "piloting" various types of forms?? Regards, Anne.
My initial gut reaction was also that this form looked too complicated for most people to grasp and understand easily, and that this thus may cause more load on us, the delegated registries, explaining what needs to be filled in and what can be left out in each case. In my form I have a "nic-hdl" entry for the persons in addition to address, phone etc., and even though I have stated
The nic-hdl is optional, as explained in the attached document (ripe-50 ).
I still get questions about it (ok, not many, but you probably see my point...)
- Havard
participants (5)
-
Anne Lord -
daniel＠digsys.bg -
Havard.Eidnes＠runit.sintef.no -
Marten Terpstra -
Peter Koch