draft-documents: sub-allocations.html
Dear Colleagues! Referring to http://www.ripe.net/ripe/draft-documents/sub-allocations.html, I found a problem which maybe will arise after publishing the document. In 3.2 Restriction on creation of inetnums with an "ASSIGNED" status I read: The creation of an inetnum object with a status of "ASSIGNED PA" or "ASSIGNED PI" will not be allowed if there is either a less specific or more specific inetnum object with an "ASSIGNED" status. The assigned status inetnum is the most specific registration allowed. Now the question I have is if this will apply to all inetnum objects which are already in the database. We, the Academic Network of the Federal State of Baden-Wuerttemberg (BELWUE), manage the internet not only for the universities in Baden-Wuerttemberg, but as well for many public schools. To provide public schools with internet addresses, we are allowed by the universities to use some of the addresses in their own class B network they don't need. (I think there won't be one university which currently uses all their IPv4 addresses in its B block.) So we are able to economise IPv4 resources by using IP addresses which wouldn't be used otherwise. That's why there are overlapping inetnum objects which are both "ASSIGNED PI", which will be forbidden in the future if I understand well the new document. Example: Within 132.230/16 which is FDN (Freiburg University) one can find 132.230.194.0 - 132.230.196.255 (BELWUE-SCHULEN) which are IP addresses of public schools in the Freiburg region. We prefer to have this inetnum object because we don't want the university to deal with abuse mails which may occur because there isn't always specialised staff in the schools to manage firewalls, mailservers etc. correctly. When there is an abuse incident we are able to react quickly by contacting the respective school. We made yet the experience that these entries in the database were very useful. Well, perhaps I misunderstood the draft document and there won't be any problems like the one I mentioned. Anyway, there should be some clarification about the objects the database won't allow to create in the future. Best regards, Christoph Mohr -- -- Christoph Mohr, BelWue Coordination ---------- mailto:mohr@belwue.de ----- Computing Center University of Stuttgart (RUS) Phone: +49 711 685-2079 Allmandring 30, D-70550 Stuttgart Fax: +49 711 678-8363 ------------------------------------------------- http://www.belwue.de/ -----
Hi, On Mon, Jan 20, 2003 at 05:22:01PM +0100, Christoph Mohr wrote:
Referring to http://www.ripe.net/ripe/draft-documents/sub-allocations.html, I found a problem which maybe will arise after publishing the document.
In 3.2 Restriction on creation of inetnums with an "ASSIGNED" status I read:
The creation of an inetnum object with a status of "ASSIGNED PA" or "ASSIGNED PI" will not be allowed if there is either a less specific or more specific inetnum object with an "ASSIGNED" status. The assigned status inetnum is the most specific registration allowed.
Indeed there is a problem here - 3.1 doesn't specify the type of "status:" to be used in the a sub-allocation inetnum object. I propose to use "SUB-ALLOCATED PA", but I'm not sure whether the NCC or community has some other ideas here.
Now the question I have is if this will apply to all inetnum objects which are already in the database.
This section might sound new, but it isn't - it was always a mistake to create "ASSIGNED" inetnum objects inside existing "ASSIGNED" inetnums. The database doesn't enforce this restriction today (for IPv4), but if you run the "asused" check tool, it will complain about overlapping objects (and so will the RIPE hostmasters).
We, the Academic Network of the Federal State of Baden-Wuerttemberg (BELWUE), manage the internet not only for the universities in Baden-Wuerttemberg, but as well for many public schools. To provide public schools with internet addresses, we are allowed by the universities to use some of the addresses in their own class B network they don't need. (I think there won't be one university which currently uses all their IPv4 addresses in its B block.) So we are able to economise IPv4 resources by using IP addresses which wouldn't be used otherwise. That's why there are overlapping inetnum objects which are both "ASSIGNED PI", which will be forbidden in the future if I understand well the new document.
What you do is, by definition of "ASSIGNED PI", already a violation of the policy (PI space is not supposed to be given to other institutions, by definition). It makes lots of sense to do it :-) but the policy doesn't take that into account. On the other hand, this is "old" PI stuff, which is likely to be assigned before there even was a set of RIPE rules, and thus the standard rules do not apply... [..]
Well, perhaps I misunderstood the draft document and there won't be any problems like the one I mentioned. Anyway, there should be some clarification about the objects the database won't allow to create in the future.
It's not the central purpose of this draft document to disallow things (to the contrary :-) ), this section is mainly intended to clarify the underlying rules - ASSIGNMENTs come from ALLOCATIONs or SUB-ALLOCATIONs, and nowhere else, and MUST NOT be nested. Reading your comment, I feel that it might be useful to change 3.2 to apply only to PA (the whole draft is only targeted at PA space) and reconsider what to do with "old" PI assignments. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55857 (55593) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hello Gert Doering! On Tue 2003-01-21 (14:58), Gert Doering wrote:
Hi,
On Mon, Jan 20, 2003 at 05:22:01PM +0100, Christoph Mohr wrote:
Referring to http://www.ripe.net/ripe/draft-documents/sub-allocations.html, I found a problem which maybe will arise after publishing the document.
In 3.2 Restriction on creation of inetnums with an "ASSIGNED" status I read:
The creation of an inetnum object with a status of "ASSIGNED PA" or "ASSIGNED PI" will not be allowed if there is either a less specific or more specific inetnum object with an "ASSIGNED" status. The assigned status inetnum is the most specific registration allowed.
Indeed there is a problem here - 3.1 doesn't specify the type of "status:" to be used in the a sub-allocation inetnum object.
I propose to use "SUB-ALLOCATED PA", but I'm not sure whether the NCC or community has some other ideas here.
Now the question I have is if this will apply to all inetnum objects which are already in the database.
This section might sound new, but it isn't - it was always a mistake to create "ASSIGNED" inetnum objects inside existing "ASSIGNED" inetnums.
The database doesn't enforce this restriction today (for IPv4), but if you run the "asused" check tool, it will complain about overlapping objects (and so will the RIPE hostmasters).
We, the Academic Network of the Federal State of Baden-Wuerttemberg (BELWUE), manage the internet not only for the universities in Baden-Wuerttemberg, but as well for many public schools. To provide public schools with internet addresses, we are allowed by the universities to use some of the addresses in their own class B network they don't need. (I think there won't be one university which currently uses all their IPv4 addresses in its B block.) So we are able to economise IPv4 resources by using IP addresses which wouldn't be used otherwise. That's why there are overlapping inetnum objects which are both "ASSIGNED PI", which will be forbidden in the future if I understand well the new document.
What you do is, by definition of "ASSIGNED PI", already a violation of the policy (PI space is not supposed to be given to other institutions, by definition). It makes lots of sense to do it :-) but the policy doesn't take that into account.
Please have a look at 141.6.0.0/16 (BASFAG-NET) which is the Class B network of BASF (ASSIGNED PI). Now there are to other ASSIGNED PI networks nested in, namely 141.6.207.0/24 (BASFAG-CH-NET) and 141.6.198.0/23 (BASFAG-DYN-NET-141-6-198), which obviously don't belong to other institutions. It seems to me very reasonable because there are other contacts in the smaller networks. On the other hand, it doesn't seem reasonable, to apply "ALLOCATED PI or PA" to the large B net 141.6/16. This is just an example of nested inetnum objects with the status ASSIGNED PI, there could be found many others. I think the RIPE database should reflect this difficult situation, otherwise the network managers/administrators won't put in inetnum objects for smaller networks with different contacts so that finally the database doesn't provide useful information.
On the other hand, this is "old" PI stuff, which is likely to be assigned before there even was a set of RIPE rules, and thus the standard rules do not apply...
[..]
Well, perhaps I misunderstood the draft document and there won't be any problems like the one I mentioned. Anyway, there should be some clarification about the objects the database won't allow to create in the future.
It's not the central purpose of this draft document to disallow things (to the contrary :-) ), this section is mainly intended to clarify the underlying rules - ASSIGNMENTs come from ALLOCATIONs or SUB-ALLOCATIONs, and nowhere else, and MUST NOT be nested.
Reading your comment, I feel that it might be useful to change 3.2 to apply only to PA (the whole draft is only targeted at PA space) and reconsider what to do with "old" PI assignments.
Maybe this could be a solution at the moment. Will there be an appropiate new draft document in the web? Best regards, Christoph Mohr -- -- Christoph Mohr, BelWue Coordination ---------- mailto:mohr@belwue.de ----- Computing Center University of Stuttgart (RUS) Phone: +49 711 685-2079 Allmandring 30, D-70550 Stuttgart Fax: +49 711 678-8363 ------------------------------------------------- http://www.belwue.de/ -----
I thought pre-RIPE NCC address space, such as the class Bs which have been mentioned, were meant to have ALLOCATED UNSPECIFIED or ASSIGNED UNSPECIFIED status and the registration rules for that space were different, recognising its pre-RIR status. Am I completely confused? Joao
Hi, On Wed, Jan 22, 2003 at 04:55:37PM +0100, Joao Damas wrote:
I thought pre-RIPE NCC address space, such as the class Bs which have been mentioned, were meant to have ALLOCATED UNSPECIFIED or ASSIGNED UNSPECIFIED status and the registration rules for that space were different, recognising its pre-RIR status.
As far as I understand, this is what the database put in when the status: field was made mandatory. When you update an entry, this status values are not permitted, though, and you have to decide upon PI/PA. Maybe it's time to introduce "ALLOCATED PRE-RIR"? Or reconsider the way the database (and asused tool) enforces "non-documentation" due to the current rules... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55857 (55593) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hello Joao! On Wed 2003-01-22 (16:55), Joao Damas wrote:
I thought pre-RIPE NCC address space, such as the class Bs which have been mentioned, were meant to have ALLOCATED UNSPECIFIED or ASSIGNED UNSPECIFIED status ...
That's not always so. As far as I know, pre-RIPE NCC address space is mostly ASSIGNED PI. Address space of providers and some universities has the status ALLOCATED UNSPECIFIED. The status "ASSIGNED UNSPECIFIED: doesn't exist.
... and the registration rules for that space were different, recognising its pre-RIR status.
That's what I thought as well, but I understood some phrases in the draft document that there will be implemented some new restrictions in the database robot which could eventually apply to pre-RIPE NCC address space as well. Best regards, Christoph Mohr -- -- Christoph Mohr, BelWue Coordination ---------- mailto:mohr@belwue.de ----- Computing Center University of Stuttgart (RUS) Phone: +49 711 685-2079 Allmandring 30, D-70550 Stuttgart Fax: +49 711 678-8363 ------------------------------------------------- http://www.belwue.de/ -----
Hi, I was just wondering, will this new policy mean that downstream network operators can control their own assignments, at least to some extent, without being a LIR themselves? -- Kristófer Sigurðsson Net- og kerfisdeild Nethönnun ehf.
Hi, On Thu, Jan 23, 2003 at 10:56:15AM +0000, Kristofer Sigurdsson wrote:
I was just wondering, will this new policy mean that downstream network operators can control their own assignments, at least to some extent, without being a LIR themselves?
Yes. That's the intention. I had hoped that this was pretty obvious from the draft... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55857 (55593) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
participants (4)
-
Christoph Mohr -
Gert Doering -
Joao Damas -
Kristofer Sigurdsson