Re: Address space for individuals
Daniel,
Geert Jan de Groot <GeertJan.deGroot@ripe.net> writes:
- If this person only has a few hosts, then it is probably a good idea to ask him to renumber once he connects to the Internet. I don't believe that renumbering 3 PC's would be that much of a problem. 1597 might be useful after all..
This sums up my personal opinion.
Great, quite along my personal opinion, but we need a consistent approach among all Local IRs.
If they are not going to connect immediately, then let them use private address space and renumber their 3 hosts later.
If they are going to connect immediately, let the service provider registry assign numbers.
Sure.
I know of cases where they subnet part of the SP space. Soon - when we have a classless allocation registry, this can even be registered.
The world, now classless, might have /30s and /29s all over the place. I do not want to think of /32s. This gives us a neat "tool" to make sure that everybody has address space assigned to her or him that fits the needs. Looking into my cristal ball (sorry, I sound like somebody else :-) ), I see a world in which the bakery on the corner of the street has a brand new /28 assigned to his one-man company by a ISP he selected. After a few month the guy making bread discovers there is an ISP for the bakery branch in his city and he wants to switch over to the bakery-ISP. This ISP welcomes his new customer with open arms and announces this /28 to the Internet at large. Remember, this /28 is from the first ISP in this story. Think of what this will do to the efficiency of CIDR... Bottom line of this story is that there needs to be a mechanism in place that forces the bakery to renumber to a CIDR range of his new service provider. For the bakery with a /28 this is not too complex, but what about this large company with a /15? __ Erik-Jan.
Erik-Jan Bos <erik-jan.bos@SURFnet.nl> writes:
Bottom line of this story is that there needs to be a mechanism in place that forces the bakery to renumber to a CIDR range of his new service provider.
I don;t like the use of force. Persuasion is enough., Charge for routing announcements and charge a premium if they are out of block.
For the bakery with a /28 this is not too complex, but what about this large company with a /15?
They are not so much of a problem after all. A large hole resembles a big block, doesn;t it?
Erik-Jan Bos <erik-jan.bos@SURFnet.nl> writes:
This sums up my personal opinion.
Great, quite along my personal opinion, but we need a consistent approach among all Local IRs.
We will write something up next week. If someone else does before us we can use that! My proposal would read like: - very small enterprises (VSEs) are those <32 hosts now - last resort registries will not assign address space to VSEs - VSEs can use private address space (RFC1697) - VSEs are easy to renumber once they connect - VSEs are likely to connect with one host only - service provider registries will assign VSEs smaller amounts of address space than 8 bits where possible - service provider registries will register these smaller amounts in the RIPE database when possible Rationale: Very many VSEs with 8 bits of address space each will use up too much address space. Is this acceptable to all? Implementation: If this was accepted the NCC could accept classles inetnums very soon even before the indexing is fully classless. Question: Should we publish such things as RIPE documents or just circulate them among registries as "current practise recommendations". I personally think we should publish them, but have heared reservations. Daniel
Daniel Karrenberg wrote:
My proposal would read like:
- very small enterprises (VSEs) are those <32 hosts now
- last resort registries will not assign address space to VSEs
- VSEs can use private address space (RFC1697) - VSEs are easy to renumber once they connect - VSEs are likely to connect with one host only
- service provider registries will assign VSEs smaller amounts of address space than 8 bits where possible
- service provider registries will register these smaller amounts in the RIPE database when possible
Rationale:
Very many VSEs with 8 bits of address space each will use up too much address space.
Is this acceptable to all?
Fully agree
Implementation: If this was accepted the NCC could accept classles inetnums very soon even before the indexing is fully classless.
Question: Should we publish such things as RIPE documents or just circulate them among registries as "current practise recommendations". I personally think we should publish them, but have heared reservations.
Daniel
-- Arnold Nipper / email: nipper@xlink.net NTG Netzwerk und Telematic GmbH \/ phone: +49 721 9652 0 Geschaeftsbereich XLINK /\ LINK fax: +49 721 9652 210 Vincenz-Priessnitz-Str. 3 /_______ D-76131 Karlsruhe, Germany
Daniel Karrenberg wrote :
We will write something up next week. If someone else does before us we can use that!
My proposal would read like:
- very small enterprises (VSEs) are those <32 hosts now
- last resort registries will not assign address space to VSEs
- VSEs can use private address space (RFC1697) - VSEs are easy to renumber once they connect - VSEs are likely to connect with one host only
- service provider registries will assign VSEs smaller amounts of address space than 8 bits where possible
- service provider registries will register these smaller amounts in the RIPE database when possible
Rationale:
Very many VSEs with 8 bits of address space each will use up too much address space.
Is this acceptable to all?
YES
Implementation: If this was accepted the NCC could accept classles inetnums very soon even before the indexing is fully classless.
Question: Should we publish such things as RIPE documents or just circulate them among registries as "current practise recommendations". I personally think we should publish them, but have heared reservations.
I am in favour of publication because it is then clear that it is a general policy, and not just a register who want to give a hard time to a VSE...
Daniel
Stephan
-- Stephan Biesbroeck Tel: +32(0)2-2383470 stephan@belnet.be Fax: +32(0)2-2315131 Service Support Team of the Belgian National Research Network, BELNET
According to Daniel Karrenberg....
My proposal would read like:
- very small enterprises (VSEs) are those <32 hosts now
- last resort registries will not assign address space to VSEs
- VSEs can use private address space (RFC1697) - VSEs are easy to renumber once they connect - VSEs are likely to connect with one host only
- service provider registries will assign VSEs smaller amounts of address space than 8 bits where possible
- service provider registries will register these smaller amounts in the RIPE database when possible
Rationale:
Very many VSEs with 8 bits of address space each will use up too much address space.
Is this acceptable to all?
Sounds very sensible. Demon would be happy to follow these guidelines. Regards, Mark. -- /\/\ark Turner Demon Systems / Demon Internet Home: mt@kram.org (PGP key available) 42 Hendon Lane, London Office: mark@demon.net (+44 81 3490063) N3 1TT, England *** IP level dialup Internet connectivity for a tenner a month! *** PGP server: email to pgp-public-keys@demon.co.uk with subject 'help'
I beg to differ with most of the opinions voiced up to now. I have big problems with Ripe rushing off and changing the rules yet another time with -no- convincing arguments and analysis that any significant problem will be solved by this change of policy. Before I would agree to a formal "sub-class C" allocation policy, I would like to see: - a study on how much address space will be actually saved by this change. Taking into account: - current available services from ISP's. For example a large number of ISP's already have "single address" dialup IP services where address are allocated out of ISP network numbers. - granularity of allocation. - loss of efficency due to the fact that most ISP's do not use CIDR capable routing protocols internally. - projected demand for address space for less than 32 hosts. This will require statistical information on company size etc. (I don't think the odd hobbyist with more than one machine is of such great concern.) - disussion of alternatives (new classes of Internet numbers etc.) and why they do not solve the problem. - a discussion on the operational pro's and con's on such an allocation policy, including administration. - a "rough consenus" between all parties that this is a good idea, this would at least include the IETF and commercial representatives of all major ISP's. As pointed out in the minutes of the local-ir meeting, there are already substantial differences in allocation policy between the European IR's and others, we cannot afford to embark on yet another Europe-only crusade. Simon
poole@eunet.ch writes:
I beg to differ with most of the opinions voiced up to now. I have big problems with Ripe rushing off and changing the rules yet another time with -no- convincing arguments and analysis that any significant problem will be solved by this change of policy.
Can you please point to other needless and unmotivated changes? Otherwise I will regard this paragraph as noise.
Before I would agree to a formal "sub-class C" allocation policy, I would like to see:
- a study on how much address space will be actually saved by this change.
If any address space can be saved and there are no ill effects this is not really a necessity.
Taking into account:
- current available services from ISP's. For example a large number of ISP's already have "single address" dialup IP services where address are allocated out of ISP network numbers.
This is just a special case of doing what the proposal says.
- granularity of allocation.
I don't understand what you mean exactly. Currently noone can assign anything smaller than 8 bits.
- loss of efficency due to the fact that most ISP's do not use CIDR capable routing protocols internally.
If it cannot be done it cannot be done. If it can be done it should be done. I do not understand what "loss of efficiency" means. If it is too ineficcient for whatever reason (which you do not discuss) then it cannot be done. The proposal just says that "last-resort" IRs will not assign address space and ISPs should do their best. Some will do better and some will do badly.
- projected demand for address space for less than 32 hosts. This will require statistical information on company size etc.
This is shooting a fly with a 122mm gun. Projections can also be called "wild guesses". Any reliable projections in a fast developing market as ours are bound to be either very inaccurate or very short term. Several last-resort registries have experienced demands from individual users and/or very small companies. This is projection enough for me.
(I don't think the odd hobbyist with more than one machine is of such great concern.)
Your personal projection. I for one am quite sure that this case and the case of very small enterprises is all but odd. I see such requests daily and I am sure we see only a fraction of them at the NCC. Other evidence: the discussion about domain names for individuals. If there are only 1024 of these requests (very low estimate) to all EU last-resort registries in the next 12 months we can either assign them 18 bits of address space (4Bs or 1024Cs for old-timers) or nothing.
- disussion of alternatives (new classes of Internet numbers etc.) and why they do not solve the problem.
If you want to discuss an alternative, propose one. (BTW: the IPv4 Internet is going classless. A new "class" is going backwards.)
- a discussion on the operational pro's and con's on such an allocation policy, including administration.
Of course a wirtten up proposal will discuss some of this. But we are just in the stage of discussion. Name a few cons.
- a "rough consenus" between all parties that this is a good idea, this would at least include the IETF,
IETF is for engineering. If you insist I can raise the issue in the IETF cidrd group. I don't quite see the point though.
and commercial representatives of all major ISP's.
That is what we have RIPE for and in this case the local-ir WG. If your representatives there are not commercial enough, you have an internal communication problem. The differences in allocation policies between regional registries are being addressed and not part of this discussion. Daniel
poole@eunet.ch writes:
I beg to differ with most of the opinions voiced up to now. I have big problems with Ripe rushing off and changing the rules yet another time with -no- convincing arguments and analysis that any significant problem will be solved by this change of policy.
Can you please point to other needless and unmotivated changes? Otherwise I will regard this paragraph as noise.
I didn't say that changes up to now have been unmotivated, however one of the the problems of local-ir's are that the criteria for address allocation in Europe have been continuosly changing and that this causes a significant ammount of pain every time.
Before I would agree to a formal "sub-class C" allocation policy, I would like to see:
- a study on how much address space will be actually saved by this change.
If any address space can be saved and there are no ill effects this is not really a necessity.
Life tends not to be so simple, any such decision is a trade off between positive and negative affects. I would be quite willing to accept a significant burden for an order of magnitude gain in address space usage but not for a factor of two. To be able to make a sensible decision we do need the information.
Taking into account:
- current available services from ISP's. For example a large number of ISP's already have "single address" dialup IP services where address are allocated out of ISP network numbers.
This is just a special case of doing what the proposal says.
Yes, however this might -already- cover the major part of what this policy wants to regulate.
- granularity of allocation.
I don't understand what you mean exactly. Currently noone can assign anything smaller than 8 bits.
The efficiency of any "sub-class C" allocation policy will depend on what the recommend "chunk" size is and how that plays into the technical realisation (routing etc.).
- loss of efficency due to the fact that most ISP's do not use CIDR capable routing protocols internally.
If it cannot be done it cannot be done. If it can be done it should be done. I do not understand what "loss of efficiency" means.
If the ISP equipment is not CIDR aware, then the ISP will have no other choice than to allocate complete classful addresses to whatever it uses as routing equipment (support for variable length subnets plays in to this aswell). If it is
too ineficcient for whatever reason (which you do not discuss) then it cannot be done. The proposal just says that "last-resort" IRs will not assign address space and ISPs should do their best. Some will do better and some will do badly.
There are two different issues here: - last-resort IR's will not allocate address space for VSE's, I don't have any problems with this as long as it is coordinated internationally and not an Europe only decision. - allocation of address space for actually Internet connected entities.
- projected demand for address space for less than 32 hosts. This will require statistical information on company size etc.
This is shooting a fly with a 122mm gun.
Projections can also be called "wild guesses". Any reliable projections in a fast developing market as ours are bound to be either very inaccurate or very short term. Several last-resort registries have experienced demands from individual users and/or very small companies. This is projection enough for me.
The numbers of companies per country and their sizes has nothing to do with the Internet per se. The assumptions can be made when we discuss how many will actually connect.
(I don't think the odd hobbyist with more than one machine is of such great concern.)
Your personal projection.
I for one am quite sure that this case and the case of very small enterprises is all but odd. I see such requests daily and I am sure we see only a fraction of them at the NCC. Other evidence: the discussion about domain names for individuals. If there are only 1024 of these requests (very low estimate) to all EU last-resort registries in the next 12 months we can either assign them 18 bits of address space (4Bs or 1024Cs for old-timers) or nothing.
As said above very likely such indvidual sites are already covered by single address allocations by ISP's.
- disussion of alternatives (new classes of Internet numbers etc.) and why they do not solve the problem.
If you want to discuss an alternative, propose one.
(BTW: the IPv4 Internet is going classless. A new "class" is going backwards.)
The IPv4 Internet is going classless at the ISP interconnect level, assuming anything else right now is very speculative. Simon
On Date: Fri, 20 May 1994 09:57:15 +0200 Daniel Karrenberg said:
My proposal would read like:
- very small enterprises (VSEs) are those <32 hosts now
The number may be even smaller. I can't remember what the commonly accepted figure is for the number of staff in a VSE, but SMEs (small-to-medium enterprised) usually range from 10 to 100 employees. I would say that anything with >16 hosts now is really an SME, not a VSE.
- last resort registries will not assign address space to VSEs
- VSEs can use private address space (RFC1697) - VSEs are easy to renumber once they connect - VSEs are likely to connect with one host only
- service provider registries will assign VSEs smaller amounts of address space than 8 bits where possible
- service provider registries will register these smaller amounts in the RIPE database when possible
Rationale:
Very many VSEs with 8 bits of address space each will use up too much address space.
Is this acceptable to all?
Yes.
Implementation: If this was accepted the NCC could accept classles inetnums very soon even before the indexing is fully classless.
Question: Should we publish such things as RIPE documents or just circulate them among registries as "current practise recommendations". I personally think we should publish them, but have heared reservations.
RIPE documents are normally recommendations anyway, but derive a lot of their benefit from being public. I say publish (and be praised ;-)
Daniel
Mike
Daniel Karrenberg wrote:
My proposal would read like:
- VSEs can use private address space (RFC1697)
RFC1597 I suspect.
Is this acceptable to all?
Sounds fair to me. Although I foresee internal routing problems here. I suspect they can be solved with routing entries for each individual host (?). The local routing table would become quite big, but that is not so much of concern (yet? :-)) With time CIDR-aware software will be available. -- Robert Martin-Legene, = EUnet Denmark = DKnet, Fruebjergvej 3, DK-2100 Kobenhavn O, +45 39 17 99 00
Robert Martin-Legene <robert@dknet.dk> writes: Daniel Karrenberg wrote:
My proposal would read like:
- VSEs can use private address space (RFC1697)
RFC1597 I suspect.
Just a test whether people read it.
Sounds fair to me. Although I foresee internal routing problems here. I suspect they can be solved with routing entries for each individual host (?). The local routing table would become quite big, but that is not so much of concern (yet? :-)) With time CIDR-aware software will be available.
What you can do internally depends on the technology you use. I would suspect that you can subnet in your POPs so that customers connected to the same POP can share Cs. If you can't do that the story ends and you have to give customers Cs. But that is only for those who connect eventually and not for everyone who asks a last-resort registry. Daniel
Sounds fair to me. Although I foresee internal routing problems here. I suspect they can be solved with routing entries for each individual host (?). The local routing table would become quite big, but that is not so much of concern (yet? :-)) With time CIDR-aware software will be available.
Assuming we have CIDR-aware software, why should we use the class C address space for these small allocations? Wouldn't it be better to split up one class A (this would allow 4 million allocations of a 3 bit net)? My main problem with supporting "sub-class C" allocations is that the local-IR's don't operate in a vaccum. There's a whole system of: - computer manufactureres - networking equipment companies - consultants - literature that can't be ignored. My experience shows that address allocation works best when the applicant already knows what to expect. Since the above "information system" has barely caught up with subnetting and maybe a bit of CIDR, it's suicidal to change yet another aspect of allocation policy essentially in secret. If we go for some kind of CIDR'zed allocation of small nets, the policy should: - use a clearly identifiable address range (not the current class C's). - be widely published (make it a big event). Simon
On Sat, 21 May 1994 11:27:51 +0200 (MET DST) poole@eunet.ch wrote:
Assuming we have CIDR-aware software, why should we use the class C address space for these small allocations? Wouldn't it be better to split up one class A (this would allow 4 million allocations of a 3 bit net)?
I see no reason why those VSE's cannot have address space from your current provider block. Instead of: 193.0.0.0/24 machine-100 company 193.0.1.0/24 machine-10 company 193.0.2.0/24 machine-10 company 193.0.3.0/24 machine-10 company 193.0.4.0/24 machine-10 company 193.0.5.0/24 machine-4 company you would get something like this: 193.0.0.0/24 machine-100 company 193.0.1.0/28 machine-10 company 193.0.1.16/28 machine-10 company 193.0.1.32/28 machine-10 company 193.0.1.48/28 machine-10 company 193.0.1.64/28 machine-4 company ... and use less than 2 C's instead of 6! I have seen this work at an ISP here on campus who uses a terminal server (which covers only one C or so) to connect to many customers who use leased lines. Chopping up a class A for this purpose means that each chunk (which then would be at a different ISP each) needs to be announced separately, which would break CIDR at large. Why do you want to use separate address space for that? (Intermezzo: you do bring up an interesting subject though - once we run out of the class C address space, we will probably need to chop up blocks of networks from a class A network just we have done now with 193.0.0.0/8 and 194.0.0.0/8. I hope that all equipment that routes to external networks is either classless or knows how to handle disjunct 'subnets' with different subnet masks correctly...) My personal interpretation of this all is that there are many l-IR's who agree that assigning a unique class C to each unconnected network of two PC's is a bad thing. If they don't connect, private address space is fine; once they connect, renumbering to fit in a ISP CIDR block is easy if you have just a few machines and not renumbering would cause the major routing table explosion which we all fear. Playing around with this leads to a few more interesting ideas. These are personal; butcher them down if you don't like them: - Maybe we should make a point that people who want address space 'so they can connect later' to ask them to make a choice of ISP first and only THEN get address space (from the provider registry, that is). If they have a small network, say up to 100 hosts or so, having them use private address space and renumber once they connect should not be so bad. - This would point more work to ISP-registries instead of the L-R registry. This brings down the work on the L-R registries (who do this for free, after all), and brings these costs to ISP registries (who might see this as 'customer service' and thus have justification why their IR-activities cost effort and money) - It makes CIDR work better!
My main problem with supporting "sub-class C" allocations is that the local-IR's don't operate in a vaccum. There's a whole system of:
- computer manufactureres
- networking equipment companies
- consultants
- literature
that can't be ignored. My experience shows that address allocation works best when the applicant already knows what to expect. Since the above "information system" has barely caught up with subnetting and maybe a bit of CIDR, it's suicidal to change yet another aspect of allocation policy essentially in secret.
A large amount of the entities listed above doesn't even know about Internet commodities like DNS and security. This is, IMHO, an area of added value of the ISP. How many times did you have to explain about changing a network from using hosts files or Yellow Plague to DNS, and tell people how to close their network for external access? In the cases I have seen, the ISP is, apart from moving bits around, also the 'interface' to the Internet: providing consultancy, first contact point in case of connectivity problems, knowing where and how to file domain information, NACR's and the like. Assigning sub-class C's could be part of that. No customer-equipment changes are neccessary! I think assigning arbitrary size of network space instead of binary multiples of class C's is simply part of the evolution the Internet is going though. Geert Jan
Geert Jan de Groot writes:
Playing around with this leads to a few more interesting ideas. These are personal; butcher them down if you don't like them: - Maybe we should make a point that people who want address space 'so they can connect later' to ask them to make a choice of ISP first and only THEN get address space (from the provider registry, that is). If they have a small network, say up to 100 hosts or so, having them use private address space and renumber once they connect should not be so bad.
Agree fully but I think this should be announced from some more authorative entity than a local-ir. RIPE will do fine. At least if there is a way to prevent situation where the customer does not go to some ISP other than the one handling the last-resort-ir and gets an address there and later when he's about to connect, feels that he got bad service from the ISP/last- resort-registry and goes to the ISP he got the addresses from. The point is that the above works if RIPE enforces this policy on ISP registries and last-resort-registries. (on all you give address space)
- This would point more work to ISP-registries instead of the L-R registry. This brings down the work on the L-R registries (who do this for free, after all), and brings these costs to ISP registries (who might see this as 'customer service' and thus have justification why their IR-activities cost effort and money) - It makes CIDR work better!
Agree with these two too. When we get a 'RIPE recommendation' that we can hand out to the applicants that apply for address space but are not planning to connect in immediate future ? Pete
poole@eunet.ch writes:
If we go for some kind of CIDR'zed allocation of small nets, the policy should:
- use a clearly identifiable address range (not the current class C's).
Why? And how to do route aggregation?
- be widely published (make it a big event).
Why? I think it would be much better to have something published widely that explained the registry system per se and not the specific details of allocation policy. We will have to start charging which will be yet another change.
poole@eunet.ch writes:
If we go for some kind of CIDR'zed allocation of small nets, the policy should:
- use a clearly identifiable address range (not the current class C's).
Why?
One of my nightmares is giving out a a sub-C allocation to a customer who later on, gets an external company to come in and install a couple of a new machines (don't forget we are talking about very small organisations with little man-power and perhaps little know-how). First reaction will be: "Ah, you've got a class C, you are using a funny subnet, but we can change that." Using a clearly identified address space that will -not- lead to confusion or will at least make people stop and think before changing things, would be a very good idea.
And how to do route aggregation?
I don't think this would be any worse (or just as good) as a completly CIDR'zed class C address space, since these addresses would be provider specific there would be no fragmentation problems). [Note: I'm not convinced that this would actually work, but it is a logical step if we do claim that we are moving towards a classless IPv4 Internet]
- be widely published (make it a big event).
Why? I think it would be much better to have something published widely that explained the registry system per se and not the specific details of allocation policy. We will have to start charging which will be yet another change.
As I've pointed out before, the main problem is that the rules are not known, this does make them easier to change, however is otherwise counterproductive. A 1 page Ripe flyer explaining the current allocation rules and aims would be a good start. There's nothing stoping us from adding a note that address space will be charged for at one point in time. Simon
participants (10)
-
Arnold Nipper -
Daniel Karrenberg -
Erik-Jan Bos -
Geert Jan de Groot -
mark＠demon.co.uk -
Mike Norris -
Petri Helenius -
poole＠eunet.ch -
Robert Martin-Legene -
Stephan.Biesbroeck＠belnet.be