Last Resort Registries
Last-Resort local IRs have been established to serve end-users who do not have access to another local IR either because they do not connect to the Internet yet or because Internet service providers were not yet providing registry services. Recently the introduction of route aggregation (CIDR) and the proliferation of local IRs operated by service providers greatly reduce the usefulness of Last-Restort local IRs. Even worse, the routing of non-aggregatable address space negatively impacts the Internet routing system. Such space either is or shortly will be less then useful for the end-user because they have to renumber when connecting. Also there is now private address space available for use of end-users who want address space that is guaranteed not to be used by another end-user on the Internet. Additionally the Last-Resort registries form an anomaly in the RIPE NCC charging system, because they do not contribute to NCC funding while using NCC resources. Consequently it has been proposed several times already to close down the Last-Resort registries. I think it is now time to finally take such a step with a timeframe of end Q3/95 or at the end of the year. Are there any serious problems with this step? Daniel
In message <9507201053.AA09097@ncc.ripe.net>you write: Daniel.Karrenberg@ripe.net said:
Also there is now private address space available for use of end-users who want address space that is guaranteed not to be used by another end-user on the Internet.
Have I missed something? I only know of private address space that is guaranteed not to be routed across the Internet. Any pointers to rfc's etc. concerning this new case of private address space? Gr|_e Oskar ------------------------------------------------------------------------------ Jan-Hinrich Fessel, F424C4, DeTeMobil M|nster Tragbar ist, was nicht herunterfdllt
Jan-Hinrich Fessel <fessel@DeTeMobil.de> writes: In message <9507201053.AA09097@ncc.ripe.net>you write:
Daniel.Karrenberg@ripe.net said:
Also there is now private address space available for use of end-users who want address space that is guaranteed not to be used by another end-user on the Internet.
Have I missed something? I only know of private address space that is guaranteed not to be routed across the Internet. Any pointers to rfc's etc. concerning this new case of private address spac e?
I intended "end-user *on the Internet*" to mean just that.
Additionally the Last-Resort registries form an anomaly in the RIPE NCC charging system, because they do not contribute to NCC funding while using NCC resources.
This is understood.
Consequently it has been proposed several times already to close down the Last-Resort registries. I think it is now time to finally take such a step with a timeframe of end Q3/95 or at the end of the year.
Are there any serious problems with this step?
There will always be companies and individuals who have a need for a last resort registry, and as long as the people here agree that the InterNIC can and *will* provide that service than there should not be any problem. However, if the InterNIC is unwilling to take on this responsibility for the geographical area managed by the RIPE on its "behalf" then someone still has to do it. Maybe a declaration from all RIPE members that they will allocate "real" address space free of charge to non-customers (prospective they may be) would then guarentee the continuing of this service in some other shape. Or even have a last resort tariff that does charge for non-service provider based address spaces and then this could fund any admin overhead. Before anyone says it, I do not see the last two paragraphs as contradictions. Regards, -- Peter Galbavy peter@demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/
Consequently it has been proposed several times already to close down the Last-Resort registries. I think it is now time to finally take such a step with a timeframe of end Q3/95 or at the end of the year.
Daniel, Some comments: - this would seem to imply that RFC1597 is now *compulsory* for private internets (certainly for those where any member also has a public Internet connection). - does the Internic still give out addresses to end customers ? If so, what is to stop an organisation obtaining addresses from the States, possibly through a US office or subsidiary ? I'm sure organisations are doing this now, but removing the last-resorts registries may well increase its prevalence. - though RIPE could discontinue the official last-resort registries, do we have any protection against providers setting themselves up as de-facto LR registries by selling off part of their provider address space to organisation who do not connect to them ? (this will only punch a hole in the providers aggregates if the organisation the addresses were assigned to decides at a later date to connect to the Internet (via another provider) - I could resell my provider addresses to private Internets without anyone knowing). Non-provider/last-resort address assignments are not currently a major problem on their own - after all the traditional class B's are (almost always) non-provider addresses, yet I don't see anyone suggesting that we should all be renumbering from our B's to addresses within a 193.* or 194.* CIDR block. Granted, we need to avoid allocating lots of long-prefix non-aggregateable addresses - this is the main problem with the last resort registries. Small allocations should be avoidable, as small/medium sized organisations ought to be able to renumber to provider addresses when they connect to the Internet. But equally there is a demand for last-resort addresses from large organisations (certainly within the UK), looking either for a class B or a large block of C's, the typical scenario being a large corporation making the transition from SNA to TCP/IP over the course of a coupel of years, with the intention of connecting to the Internet at the end of this process. Where are these organisations left if the last resort registries are discontinued ? (Answer(?): if they are after a B (certainly, and probably if they want a substantial block of traditional C space) they end up talking to the NCC from day one. Which comes back to Daniel's assertion that last-resort registries use NCC resources without contributing to the NCC; currently last-resort registries do some (albeit sometimes negligible) vetting and frontline processing of class B requests before passing them onto the NCC. Without the LR registries, everything falls on the NCC). Kevin Hoadley, JIPS NOSC
Consequently it has been proposed several times already to close down the Last-Resort registries. I think it is now time to finally take such a step with a timeframe of end Q3/95 or at the end of the year.
Daniel,
This is all going severely to fast for my taste. Essentially the decision is not to close down the last-resort registries, but not to allocate unique address space anymore except for Internet connected organisations. This is a decision of a magnitude that needs substantially more support than it currently has.
Some comments:
- this would seem to imply that RFC1597 is now *compulsory* for private internets (certainly for those where any member also has a public Internet connection).
There are perfectly good reasons why an organisation might want unique (but not necessarily globably routable) address space, RFC1597 doesn't provide this. Simon
poole@eunet.ch writes:
This is all going severely to fast for my taste. Essentially the decision is not to close down the last-resort registries, but not to allocate unique address space anymore except for Internet connected organisations.
This is *not* the case! Your observation is right in the sense that there is a clear *trend* in the Internet community towards a situation like this. The particular decision to abandon last-resort registries is not equal to "not allocate unique address space anymore except for Internet connected organisations". All the remaining registries remain free to allocate to non-connected organisations. See ripe-127 for details.
There are perfectly good reasons why an organisation might want unique (but not necessarily globably routable) address space, RFC1597 doesn't provide this.
I agree with you. However, these organisations should also be aware that such address space may not be automatically routable on the Internet. Again see ripe-127 for details. Again: Abandoning last-resort registries does not mean that it will be impossible to obtain public address space without an Internet connection. Yes it will become more difficult and end-users will be warned better about whaqt they are getting. Daniel
Kevin Hoadley <kevin@nosc.ja.net> writes:
- this would seem to imply that RFC1597 is now *compulsory* for private internets
No, see my answer to Simon.
- does the Internic still give out addresses to end customers ? If so, what is to stop an organisation obtaining addresses from the States, possibly through a US office or subsidiary ? I'm sure organisations are doing this now, but removing the last-resorts registries may well increase its prevalence.
The only barrier is that the InterNIC will not assign anything if they are clearly in Europe. Deviousness of course is always a possibility. The only attractivenessof the InterNIC at the moment is that it is free.
- though RIPE could discontinue the official last-resort registries, do we have any protection against providers setting themselves up as de-facto LR registries by selling off part of their provider address space to organisation who do not connect to them ? (this will only punch a hole in the providers aggregates if the organisation the addresses were assigned to decides at a later date to connect to the Internet (via another provider) - I could resell my provider addresses to private Internets without anyone knowing).
There is nothing to stop them. Indeed it is perfectly legitimate for provider IRs to assign PI space if they so choose. But it would be against their own interests to punch holes in their CIDR blocks. ripe-127 suggests that they should use seperate parts of the address space for that. It also says that they not normally get allocations for that, but get it from the NCC on an as-needed basis.
Non-provider/last-resort address assignments are not currently a major prob lem on their own - after all the traditional class B's are (almost always) non-provider addresses, yet I don't see anyone suggesting that we should al l be renumbering from our B's to addresses within a 193.* or 194.* CIDR block .
I mentioned the main problems im my proposal.
Granted, we need to avoid allocating lots of long-prefix non-aggregateable addresses - this is the main problem with the last resort registries. Small allocations should be avoidable, as small/medium sized organisations ought to be able to renumber to provider addresses when they connect to the Inter net. But equally there is a demand for last-resort addresses from large organisations (certainly within the UK), looking either for a class B or a large block of C's, the typical scenario being a large corporation making the transition from SNA to TCP/IP over the course of a coupel of years, wit h the intention of connecting to the Internet at the end of this process. Where are these organisations left if the last resort registries are discontinued ?
They can go to any other IR.
(Answer(?): if they are after a B (certainly, and probably if they want a substantial block of traditional C space) they end up talking to the NCC from day one. Which comes back to Daniel's assertion that last-resort registries use NCC resources without contributing to the NCC; currently last-resort registries do some (albeit sometimes negligible) vetting and frontline processing of class B requests before passing them onto the NCC. Without the LR registries, everything falls on the NCC).
That is true only if no provider IRs decide to provide this service. I have strong suspicions that they will provide this service, for a fee of course. Again: The main problem here is perception. It should be made clear to end-users that getting PI space does not guarantee routability on the Internet. Daniel
- this would seem to imply that RFC1597 is now *compulsory* for privat internets
No, see my answer to Simon.
(I actually meant that as a question, but ...) So dropping the last resort registries does little or nothing to reduce non-provider addresses, since organisations can still acquire address space from one provider and connectivity from another. The allocation of addresses that may not be aggregateable continues, only now by different registries. I'm not sure I see how relocating the registry activities helps global routing.
I mentioned the main problems im my proposal.
Re-reading your proposal there appears to be three lines of discussion, which in order of importance are: 1/ last-resort registries allocate non-aggregateable address space (which in the future may be useless as no one will route it). 2/ last-resort registries are less necessary than was the case because of the proliferation of provider registries 3/ last-resort registries do not currently fit into the NCC charging model. and a fourth point, from one of your replies to Simon: 4/ "end-users will be warned better about what they are getting" if they obtain their addresses from provider registries, rather than last resort registries (Have I missed anything ?) Going through these points, I don't believe dropping last-resort registries solves #1, as non-aggregateable address will still be allocated albeit by different registries. #2 is true, but not necessarily a reason to drop the LR registries: less demand for them is not the same as no demand. A similar argument can be advanced against #3 - the fact that the charging model may need to be modified to accommodate the LR registries is not by itself sufficient reason to drop the registries. I'm not at all convinced by #4. Consider the following scenario: a provider registry allocates a block of addresses to a private internet, that claims it has no intention of connecting to the global Internet. The provider registry levies a charge for this (they win). 18 months later the private internet then decides it does wish to connect to the global Internet. However now they find that the only provider prepared to carry their addresses is the one that allocated them in the first place. Hence unless they are prepared to renumber they are locked into the first provider (thus the provider wins again). The same would have been true had they acquired the addresses from a last-resort registry, however unlike the last-resort registries it is in the provider's interest *NOT* to tell the customer about the possible restrictions in the use of the addresses. I'm happy to see the last-resort registries disappear (we'd be *extremely* happy to get shot of the load from our LR registry :-) ) if it is brings significant benefit to the community. However on the basis of the arguments I've seen here, I personally think that the benefit is not yet proven. Kevin Hoadley, JIPS NOSC.
Daniel,
Last-Resort local IRs have been established to serve end-users who do not have access to another local IR either because they do not connect to the Internet yet or because Internet service providers were not yet providing registry services.
Unfortunately there are still cases of ISPs not providing registry services for their customers. For example US providers selling connectivity in Europe do not provide IP addresses. As far as I know they do not want to be part of the European Regional IR.
Recently the introduction of route aggregation (CIDR) and the proliferation of local IRs operated by service providers greatly reduce the usefulness of Last-Restort local IRs. Even worse, the routing of non-aggregatable address space negatively impacts the Internet routing system. Such space either is or shortly will be less then useful for the end-user because they have to renumber when connecting. Also there is now private address space available for use of end-users who want address space that is guaranteed not to be used by another end-user on the Internet.
I agreee
Additionally the Last-Resort registries form an anomaly in the RIPE NCC charging system, because they do not contribute to NCC funding while using NCC resources.
This can eventually be solved in some way...
Consequently it has been proposed several times already to close down the Last-Resort registries. I think it is now time to finally take such a step with a timeframe of end Q3/95 or at the end of the year.
Are there any serious problems with this step?
I think it could be done but there is a strong need for a document explaining the new address assignment policy. I think this document should have worldwide applicability and be published as an RFC. Local IRs need such a reference when they have to answer to strange address assignment requests eventually coming from network managers or small providers located in dispersed sites around the world. ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito@nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------
bonito@nis.garr.it (Antonio_Blasco Bonito) writes:
Unfortunately there are still cases of ISPs not providing registry services for their customers. For example US providers selling connectivity in Europe do not provide IP addresses. As far as I know they do not want to be part of the European Regional IR.
I do not know of *any* significant cases of this. The issue which regional IR a provider gets allocations from is not relevant in this discussion.
Additionally the Last-Resort registries form an anomaly in the RIPE NCC charging system, because they do not contribute to NCC funding while using NCC resources.
This can eventually be solved in some way...
I agree, if we decide to keep them around we will have to charge them like any other registry. Note however, that this is not the main argument for doing away with them.
I think it could be done but there is a strong need for a document explaining the new address assignment policy.
Fully agree!
I think this document should have worldwide applicability and be published as an RFC.
Do not agree. For European Last-Resort registries a RIPE document is sufficient.
Local IRs need such a reference when they have to answer to strange address assignment requests eventually coming from network managers or small providers located in dispersed sites around the world.
Yep. Daniel
bonito@nis.garr.it (Antonio_Blasco Bonito) writes:
Unfortunately there are still cases of ISPs not providing registry services for their customers. For example US providers selling connectivity in Europe do not provide IP addresses. As far as I know they do not want to be part of the European Regional IR.
I do not know of *any* significant cases of this. The issue which regional IR a provider gets allocations from is not relevant in this discussion.
I think it *is* relevant: we are talking about CIDR aggregatable addresses. Some US providers do not want to provide addresses to customers in Europe from their own address space to save the possibility of continental aggregation. This is a point which needs to be clarified at least to correctly define the role of Regional registries.
I think this document should have worldwide applicability and be published as an RFC.
Do not agree. For European Last-Resort registries a RIPE document is sufficient.
That's not sufficient, I guess. We could start with a RIPE document but I'm convinced the issue is *not* restricted to Europe. RIPE-181 became an RFC for the same reason. Am I right?
Local IRs need such a reference when they have to answer to strange address assignment requests eventually coming from network managers or small providers located in dispersed sites around the world.
Yep.
Daniel
---------- ---------- Antonio_Blasco Bonito E-Mail: bonito@nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------
Antonio_Blasco Bonito <bonito@nis.garr.it> writes:
I think it *is* relevant: we are talking about CIDR aggregatable addresses. Some US providers do not want to provide addresses to customers in Europe from their own address space to save the possibility of continental aggregation. This is a point which needs to be clarified at least to correctly define the role of Regional registries.
I only know of one such case and this provider has since changed their mind (regid eu.sprint).
I think this document should have worldwide applicability and be published as an RFC.
Do not agree. For European Last-Resort registries a RIPE document is sufficient.
That's not sufficient, I guess. We could start with a RIPE document but I'm convinced the issue is *not* restricted to Europe.
We start with a RIPE document. The problem with an RFCs is that there are many highly contentious issues associated with a successor to RFC1466. This document is not going to be agreed quickly. However we need a revision of ripe-104. So far we have been waiting. ripe-104 is now sufficiently outdated to go ahead with a revision anyway. I just hope that we can agree on one in Europe. I would prefer it to go the other way round but there seems to be little choice.
RIPE-181 became an RFC for the same reason. Am I right?
It is an informational RFC about a technology, not about address space policies. Daniel
Daniel,
Last-Resort local IRs have been established to serve end-users who do not have access to another local IR either because they do not connect to the Internet yet or because Internet service providers were not yet providing registry services.
Unfortunately there are still cases of ISPs not providing registry services for their customers. For example US providers selling connectivity in Europe do not provide IP addresses. As far as I know they do not want to be part of the European Regional IR.
As far as I'm concerned this should be left to market forces. Such ISPs deserve to fail, and will do so. Nigel Titley --------------------------------------------------------------------- Nigel Titley --- BTnet Applications Services Manager E-mail: Nigel.Titley@bt.net Tel: +44 1442 237674
I am personally in favor of closing down the last resource registry (one reason is of course that it is starting to take up a serious amount of resources for us :-(). BUT documentation is in that case indeed hardly needed since some "callers" are rather agressive, and in that case it is usefull to point them to a general available document. Stephan Daniel Karrenberg wrote :
Last-Resort local IRs have been established to serve end-users who do not have access to another local IR either because they do not connect to the Internet yet or because Internet service providers were not yet providing registry services.
Recently the introduction of route aggregation (CIDR) and the proliferation of local IRs operated by service providers greatly reduce the usefulness of Last-Restort local IRs. Even worse, the routing of non-aggregatable address space negatively impacts the Internet routing system. Such space either is or shortly will be less then useful for the end-user because they have to renumber when connecting. Also there is now private address space available for use of end-users who want address space that is guaranteed not to be used by another end-user on the Internet.
Additionally the Last-Resort registries form an anomaly in the RIPE NCC charging system, because they do not contribute to NCC funding while using NCC resources.
Consequently it has been proposed several times already to close down the Last-Resort registries. I think it is now time to finally take such a step with a timeframe of end Q3/95 or at the end of the year.
Are there any serious problems with this step?
Daniel
-- Stephan Biesbroeck Tel: +32(0)2-2383470 stephan@belnet.be Fax: +32(0)2-2311531 Service Support Team of the Belgian National Research Network, BELNET
participants (9)
-
Antonio_Blasco Bonito -
bonito＠nis.garr.it
-
Daniel Karrenberg -
Jan-Hinrich Fessel -
Kevin Hoadley -
Nigel Titley -
peter＠demon.net -
poole＠eunet.ch -
Stephan.Biesbroeck＠belnet.be