Proposed change 2004.1: extended route creation rules
Dear colleagues, [apologies for duplicate mails] Some time ago, Frank brought an issue regarding route object aggregation to our attention in the DB-WG mailing list. Please see the short thread at: http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00474.html http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00475.html We have prepared a proposal to extend the route object creation rules to resolve this issue. However, the resulting proposal turns out to be quite complex as it builds on the current route object creation rules, which are already complex enough. Considering that the need for route object aggregation is encountered very rarely, it might not be worth implementing it. After the deployment of version 3 of our whois software, we have seen only a couple of such cases. In those cases, we have resolved the issue by applying the rules that we specify below manually. I would like to ask the working groups if they think this proposal is too complex. Implementing it would not be a problem technically, but I'm more concerned about explaining the complex rules properly to the users of the whois database. Best regards, and thanks for your time, -- Engin Gunduz RIPE NCC Software Engineering Department ============================================================= A PROPOSAL FOR EXTENDED ROUTE OBJECT CREATION RULES This document is about being able to create route objects that aggregate inetnums/route objects. This is needed where a user cannot merge two or more inetnum objects into one larger inetnum object, but still needs to create a route object that aggregates these inetnum objects. This is seen especially with assigned PI inetnum objects. A hypothetical example: Suppose there exist the following two inetnums in the whois database: inetnum: 12.0.0.0 - 12.0.0.255 netname: EXAMPLE-PI descr: Example Banking PLC admin-c: AA1-RIPE status: ASSIGNED PI inetnum: 12.0.1.0 - 12.0.1.255 netname: ANOTHER-EXAMPLE-PI descr: Anotherexample Printing Industries NV admin-c: ZZ1-RIPE status: ASSIGNED PI These are assigned to different end-users. Further suppose that they coincidentally take service from the same Internet Service Provider. The Internet Service Provider will want to aggregate these two assignments into a single 12.0.0.0/23 route to be announced, rather than announcing two separate prefixes, in order to keep the number of prefixes in routing tables to the minimum. However, the Internet Provider will not be able to create a single route object in the RIPE Routing Registry which implements RPSSec RFC (RFC2725). This is because the inetnum object that contains the 12.0.0.0/23 prefix will be inetnum: 12.0.0.0 - 12.9.255.255 netname: EU-ZZ-000000 descr: block for PI assignments descr: maintained by RIPE NCC country: EU remarks: These addresses are assigned to network operators. The RIPE NCC does not operate any networks using address space from this block. An explanation of how to find the correct contacts is available at <http://www.ripe.net/nicdb.html> admin-c: CREW-RIPE tech-c: CREW-RIPE tech-c: OPS4-RIPE status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT changed: hostmaster@ripe.net 20030731 source: RIPE Note the "mnt-lower:" attribute that has RIPE-NCC-HM-MNT. See http://www.ripe.net/ripencc/faq/database/qa4.html#5 for a graphical representation of the current route object creation rules. Proposal: To address this problem, we need to extend the route object creation rules so that it would be possible to create a route object that takes its authorisation from a collection of route and/or inetnum objects that are more specific than the route object to be created. As the situation is quite rare, the 'extended' behaviour can be activated by using the keyword 'EXTENDED-ROUTE-CREATION' in the subject line of the update message or with the syncupdates. The extended behaviour is not the default behaviour. The Algorithm: The proposed algorithm to authorise the route object creation is: Check if the keyword was used. If not, proceed with normal route creation rules as described in RFC2725 (http://www.ripe.net/ripencc/faq/database/qa4.html#5) Check if there is an exact match route object or an exact match inetnum object If there is one, then proceed with normal route creation rules even if the keyword was specified. Find the inetnums/routes that can be used for route creation: Get a list of all inetnums and route objects that are one level more specific than the route object to be created. (-r -Troute,inetnum -m <prefix>) From this list, eliminate the inetnums that have exact match or less specific route objects. (Note: During route object creation, the existing route objects take precedence over existing inetnum objects). Check if the resulting set of inetnums/routes cover the whole space of the route to be created. If not, authorisation fails, hence creation attempt fails. Collect the mntners to be used during the authorisation check. Follow these rules: For each object in the set, check if there are "mnt-routes:" attributes in the object. If there are, they will be used. If there are not, the mntners that are mentioned in "mnt-by:" attributes will be used. Check the authorisation: During the authorisation, the mntners in the same object will be ORed, while the mntners in separate objects will be ANDed. Example 1: Suppose we have these inetnums in the database: inetnum: 0.0.0.0 - 255.255.255.255 status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-NONE-MNT inetnum: 12.0.0.0 - 12.255.255.255 status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT inetnum: 12.0.0.0 - 12.0.0.255 netname: EXAMPLE-PI descr: Example Banking PLC admin-c: AA1-RIPE status: ASSIGNED PI mnt-by: MNT-EXAMPLE-PI inetnum: 12.0.1.0 - 12.0.1.255 netname: ANOTHER-EXAMPLE-PI descr: Anotherexample Printing Industries NV admin-c: ZZ1-RIPE status: ASSIGNED PI mnt-by: MNT-ANOTHEREXAMPLE-MNT-BY mnt-routes: MNT-ANOTHEREXAMPLE-MNT-ROUTES mnt-routes: MNT-ANOTHEREXAMPLE-MNT-ROUTES-2 There is also this aut-num object: aut-num: AS65534 mnt-by: MNT-AUT-NUM-MNT-BY mnt-routes: MNT-AUT-NUM-MNT-ROUTES There are no route objects that are in 12.0.0.0/23 space, or less specific of 12.0.0.0/23. The user wants to create the following route object: route: 12.0.0.0/23 origin: AS65534 mnt-by: MNT-ROUTE When the creation is attempted without the keyword 'EXTENDED-ROUTE-CREATION,' the whois software will try to get the IP space authentication from inetnums, as no related route object exists. The one level less specific inetnum is 12.0.0.0 - 12.255.255.255, which has the attribute "mnt-lower: RIPE-NCC-HM-MNT". As the user does not have access to the authorisation for RIPE-NCC-HM-MNT mntner, the creation attempt will fail. When the creation is attempted with the keyword 'EXTENDED-ROUTE-CREATION': - There are no exact match route or inetnum objects, so proceed with extended route creation rules. - to get the authorisation from IP space, the whois software will perform '-r -Troute,inetnum -m 12.0.0.0/23' query, which will return inetnum: 12.0.0.0 - 12.0.0.255 inetnum: 12.0.1.0 - 12.0.1.255 - there are no inetnums to be eliminated from the list. - the resulting set of inetnums/routes (it actually has two inetnums and no routes) covers the whole space of 12.0.0.0/23. - collect the mntners to be used in the authorisation process. from the aut-num: MNT-AUT-NUM-MNT-ROUTES from the route object itself that will be created: MNT-ROUTE from the IP space: (MNT-EXAMPLE-PI AND (MNT-ANOTHEREXAMPLE-MNT-ROUTES OR MNT-ANOTHEREXAMPLE-MNT-ROUTES-2)) 12.0.0.0 - 12.0.0.255 does not have "mnt-routes:", so "mnt-by:" must be used. 12.0.1.0 - 12.0.1.255 has two "mnt-routes:", so they both must be used, but they must be ORed. - the resulting mntner list: ( MNT-AUT-NUM-MNT-ROUTES AND MNT-ROUTE AND ( MNT-EXAMPLE-PI AND ( MNT-ANOTHEREXAMPLE-MNT-ROUTES OR MNT-ANOTHEREXAMPLE-MNT-ROUTES-2 ) ) ) Example 2: Suppose there are these inetnums in the database: inetnum: 0.0.0.0 - 255.255.255.255 mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-NONE-MNT inetnum: 12.0.0.0 - 12.255.255.255 mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT inetnum: 12.0.0.0 - 12.0.0.255 mnt-routes: MNT-INETNUM-1 inetnum: 12.0.1.0 - 12.0.1.255 mnt-routes: MNT-INETNUM-2 and the following route objects: route: 12.0.1.0/24 origin: AS65534 mnt-routes: MNT-ROUTE-1 route: 12.0.2.0/23 origin: AS6 mnt-routes: MNT-ROUTE-2 route: 12.0.2.0/23 origin: AS65534 mnt-routes: MNT-ROUTE-3 mnt-routes: MNT-ROUTE-4 and this aut-num: aut-num: AS65534 mnt-by: MNT-AUT-NUM-MNT-BY mnt-routes: MNT-AUT-NUM-MNT-ROUTES The user wants to create the following route object: route: 12.0.0.0/22 origin: AS65534 mnt-by: MNT-ROUTE When the creation is attempted without the keyword 'EXTENDED-ROUTE-CREATION,' the whois software will try to get the IP space authentication from inetnums, as no related route object exists. The one level less specific inetnum is 12.0.0.0 - 12.255.255.255, which has "mnt-lower: RIPE-NCC-HM-MNT" attribute. As the user does not have access to the authorisation for RIPE-NCC-HM-MNT mntner, the creation attempt will fail. When the creation is attempted with the keyword 'EXTENDED-ROUTE-CREATION': - There are no exact match route or inetnum objects, so proceed with extended route creation rules. - to get the authorisation from IP space, the whois software will perform '-r -Troute,inetnum -m 12.0.0.0/22' query, which will return inetnum: 12.0.0.0 - 12.0.0.255 inetnum: 12.0.1.0 - 12.0.1.255 route: 12.0.1.0/24 route: 12.0.2.0/23 (origin AS6) route: 12.0.2.0/23 (origin AS65534) - eliminate the inetnums with less specific or exact match route objects in the list. The resulting list will be: inetnum: 12.0.0.0 - 12.0.0.255 route: 12.0.1.0/24 route: 12.0.2.0/23 (origin AS6) route: 12.0.2.0/23 (origin AS65534) - the resulting list covers the whole 12.0.0.0/22 space. Continue. - Collect the mntners to be used during the authorisation check. from the aut-num: MNT-AUT-NUM-MNT-ROUTES from the route object itself that will be created: MNT-ROUTE from the IP space: (MNT-INETNUM-1 AND MNT-ROUTE-1 AND (MNT-ROUTE-2 AND (MNT-ROUTE-3 OR MNT-ROUTE-4))) - the resulting mntner list: ( MNT-AUT-NUM-MNT-ROUTES AND MNT-ROUTE AND ( ( MNT-INETNUM-1 AND MNT-ROUTE-1 AND ( MNT-ROUTE-2 AND ( MNT-ROUTE-3 OR MNT-ROUTE-4 ) ) ) ) )
Engin, if this is, as stated, a rare event, would it not be better to have this be dealt with via a request to ripe-dbm? You can implement a Perl snippet that does the checks you describe without polluting the general DB code with what feels like a kludge. Joao On 9 Feb, 2004, at 15:07, Engin Gunduz wrote:
Dear colleagues,
[apologies for duplicate mails]
Some time ago, Frank brought an issue regarding route object aggregation to our attention in the DB-WG mailing list. Please see the short thread at:
http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00474.html http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00475.html
We have prepared a proposal to extend the route object creation rules to resolve this issue. However, the resulting proposal turns out to be quite complex as it builds on the current route object creation rules, which are already complex enough.
Considering that the need for route object aggregation is encountered very rarely, it might not be worth implementing it. After the deployment of version 3 of our whois software, we have seen only a couple of such cases. In those cases, we have resolved the issue by applying the rules that we specify below manually.
I would like to ask the working groups if they think this proposal is too complex. Implementing it would not be a problem technically, but I'm more concerned about explaining the complex rules properly to the users of the whois database.
Best regards, and thanks for your time, -- Engin Gunduz RIPE NCC Software Engineering Department
============================================================= A PROPOSAL FOR EXTENDED ROUTE OBJECT CREATION RULES
This document is about being able to create route objects that aggregate inetnums/route objects. This is needed where a user cannot merge two or more inetnum objects into one larger inetnum object, but still needs to create a route object that aggregates these inetnum objects. This is seen especially with assigned PI inetnum objects. A hypothetical example: Suppose there exist the following two inetnums in the whois database:
inetnum: 12.0.0.0 - 12.0.0.255 netname: EXAMPLE-PI descr: Example Banking PLC admin-c: AA1-RIPE status: ASSIGNED PI
inetnum: 12.0.1.0 - 12.0.1.255 netname: ANOTHER-EXAMPLE-PI descr: Anotherexample Printing Industries NV admin-c: ZZ1-RIPE status: ASSIGNED PI
These are assigned to different end-users. Further suppose that they coincidentally take service from the same Internet Service Provider. The Internet Service Provider will want to aggregate these two assignments into a single 12.0.0.0/23 route to be announced, rather than announcing two separate prefixes, in order to keep the number of prefixes in routing tables to the minimum. However, the Internet Provider will not be able to create a single route object in the RIPE Routing Registry which implements RPSSec RFC (RFC2725). This is because the inetnum object that contains the 12.0.0.0/23 prefix will be
inetnum: 12.0.0.0 - 12.9.255.255 netname: EU-ZZ-000000 descr: block for PI assignments descr: maintained by RIPE NCC country: EU remarks: These addresses are assigned to network operators. The RIPE NCC does not operate any networks using address space from this block. An explanation of how to find the correct contacts is available at <http://www.ripe.net/nicdb.html> admin-c: CREW-RIPE tech-c: CREW-RIPE tech-c: OPS4-RIPE status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT changed: hostmaster@ripe.net 20030731 source: RIPE
Note the "mnt-lower:" attribute that has RIPE-NCC-HM-MNT. See http://www.ripe.net/ripencc/faq/database/qa4.html#5 for a graphical representation of the current route object creation rules.
Proposal: To address this problem, we need to extend the route object creation rules so that it would be possible to create a route object that takes its authorisation from a collection of route and/or inetnum objects that are more specific than the route object to be created. As the situation is quite rare, the 'extended' behaviour can be activated by using the keyword 'EXTENDED-ROUTE-CREATION' in the subject line of the update message or with the syncupdates. The extended behaviour is not the default behaviour.
The Algorithm: The proposed algorithm to authorise the route object creation is:
Check if the keyword was used. If not, proceed with normal route creation rules as described in RFC2725 (http://www.ripe.net/ripencc/faq/database/qa4.html#5) Check if there is an exact match route object or an exact match inetnum object If there is one, then proceed with normal route creation rules even if the keyword was specified. Find the inetnums/routes that can be used for route creation: Get a list of all inetnums and route objects that are one level more specific than the route object to be created. (-r -Troute,inetnum -m <prefix>) From this list, eliminate the inetnums that have exact match or less specific route objects. (Note: During route object creation, the existing route objects take precedence over existing inetnum objects). Check if the resulting set of inetnums/routes cover the whole space of the route to be created. If not, authorisation fails, hence creation attempt fails. Collect the mntners to be used during the authorisation check. Follow these rules: For each object in the set, check if there are "mnt-routes:" attributes in the object. If there are, they will be used. If there are not, the mntners that are mentioned in "mnt-by:" attributes will be used. Check the authorisation: During the authorisation, the mntners in the same object will be ORed, while the mntners in separate objects will be ANDed.
Example 1:
Suppose we have these inetnums in the database:
inetnum: 0.0.0.0 - 255.255.255.255 status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-NONE-MNT
inetnum: 12.0.0.0 - 12.255.255.255 status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT
inetnum: 12.0.0.0 - 12.0.0.255 netname: EXAMPLE-PI descr: Example Banking PLC admin-c: AA1-RIPE status: ASSIGNED PI mnt-by: MNT-EXAMPLE-PI
inetnum: 12.0.1.0 - 12.0.1.255 netname: ANOTHER-EXAMPLE-PI descr: Anotherexample Printing Industries NV admin-c: ZZ1-RIPE status: ASSIGNED PI mnt-by: MNT-ANOTHEREXAMPLE-MNT-BY mnt-routes: MNT-ANOTHEREXAMPLE-MNT-ROUTES mnt-routes: MNT-ANOTHEREXAMPLE-MNT-ROUTES-2
There is also this aut-num object:
aut-num: AS65534 mnt-by: MNT-AUT-NUM-MNT-BY mnt-routes: MNT-AUT-NUM-MNT-ROUTES
There are no route objects that are in 12.0.0.0/23 space, or less specific of 12.0.0.0/23.
The user wants to create the following route object:
route: 12.0.0.0/23 origin: AS65534 mnt-by: MNT-ROUTE
When the creation is attempted without the keyword 'EXTENDED-ROUTE-CREATION,' the whois software will try to get the IP space authentication from inetnums, as no related route object exists. The one level less specific inetnum is 12.0.0.0 - 12.255.255.255, which has the attribute "mnt-lower: RIPE-NCC-HM-MNT". As the user does not have access to the authorisation for RIPE-NCC-HM-MNT mntner, the creation attempt will fail.
When the creation is attempted with the keyword 'EXTENDED-ROUTE-CREATION': - There are no exact match route or inetnum objects, so proceed with extended route creation rules. - to get the authorisation from IP space, the whois software will perform '-r -Troute,inetnum -m 12.0.0.0/23' query, which will return
inetnum: 12.0.0.0 - 12.0.0.255 inetnum: 12.0.1.0 - 12.0.1.255
- there are no inetnums to be eliminated from the list. - the resulting set of inetnums/routes (it actually has two inetnums and no routes) covers the whole space of 12.0.0.0/23. - collect the mntners to be used in the authorisation process. from the aut-num: MNT-AUT-NUM-MNT-ROUTES from the route object itself that will be created: MNT-ROUTE from the IP space: (MNT-EXAMPLE-PI AND (MNT-ANOTHEREXAMPLE-MNT-ROUTES OR MNT-ANOTHEREXAMPLE-MNT-ROUTES-2)) 12.0.0.0 - 12.0.0.255 does not have "mnt-routes:", so "mnt-by:" must be used. 12.0.1.0 - 12.0.1.255 has two "mnt-routes:", so they both must be used, but they must be ORed. - the resulting mntner list: ( MNT-AUT-NUM-MNT-ROUTES AND MNT-ROUTE AND ( MNT-EXAMPLE-PI AND ( MNT-ANOTHEREXAMPLE-MNT-ROUTES OR MNT-ANOTHEREXAMPLE-MNT-ROUTES-2 ) ) )
Example 2:
Suppose there are these inetnums in the database:
inetnum: 0.0.0.0 - 255.255.255.255 mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-NONE-MNT
inetnum: 12.0.0.0 - 12.255.255.255 mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT
inetnum: 12.0.0.0 - 12.0.0.255 mnt-routes: MNT-INETNUM-1
inetnum: 12.0.1.0 - 12.0.1.255 mnt-routes: MNT-INETNUM-2
and the following route objects:
route: 12.0.1.0/24 origin: AS65534 mnt-routes: MNT-ROUTE-1
route: 12.0.2.0/23 origin: AS6 mnt-routes: MNT-ROUTE-2
route: 12.0.2.0/23 origin: AS65534 mnt-routes: MNT-ROUTE-3 mnt-routes: MNT-ROUTE-4
and this aut-num:
aut-num: AS65534 mnt-by: MNT-AUT-NUM-MNT-BY mnt-routes: MNT-AUT-NUM-MNT-ROUTES
The user wants to create the following route object:
route: 12.0.0.0/22 origin: AS65534 mnt-by: MNT-ROUTE
When the creation is attempted without the keyword 'EXTENDED-ROUTE-CREATION,' the whois software will try to get the IP space authentication from inetnums, as no related route object exists. The one level less specific inetnum is 12.0.0.0 - 12.255.255.255, which has "mnt-lower: RIPE-NCC-HM-MNT" attribute. As the user does not have access to the authorisation for RIPE-NCC-HM-MNT mntner, the creation attempt will fail.
When the creation is attempted with the keyword 'EXTENDED-ROUTE-CREATION': - There are no exact match route or inetnum objects, so proceed with extended route creation rules. - to get the authorisation from IP space, the whois software will perform '-r -Troute,inetnum -m 12.0.0.0/22' query, which will return
inetnum: 12.0.0.0 - 12.0.0.255 inetnum: 12.0.1.0 - 12.0.1.255 route: 12.0.1.0/24 route: 12.0.2.0/23 (origin AS6) route: 12.0.2.0/23 (origin AS65534)
- eliminate the inetnums with less specific or exact match route objects in the list. The resulting list will be:
inetnum: 12.0.0.0 - 12.0.0.255 route: 12.0.1.0/24 route: 12.0.2.0/23 (origin AS6) route: 12.0.2.0/23 (origin AS65534)
- the resulting list covers the whole 12.0.0.0/22 space. Continue. - Collect the mntners to be used during the authorisation check. from the aut-num: MNT-AUT-NUM-MNT-ROUTES from the route object itself that will be created: MNT-ROUTE from the IP space: (MNT-INETNUM-1 AND MNT-ROUTE-1 AND (MNT-ROUTE-2 AND (MNT-ROUTE-3 OR MNT-ROUTE-4)))
- the resulting mntner list: ( MNT-AUT-NUM-MNT-ROUTES AND MNT-ROUTE AND ( ( MNT-INETNUM-1 AND MNT-ROUTE-1 AND ( MNT-ROUTE-2 AND ( MNT-ROUTE-3 OR MNT-ROUTE-4 ) ) ) ) )
Hi,
-----Original Message----- From: routing-wg-admin@ripe.net [mailto:routing-wg-admin@ripe.net]On Behalf Of Joao Damas Sent: Monday, February 09, 2004 3:55 PM To: Engin Gunduz Cc: routing-wg@ripe.net; db-wg@ripe.net; Frank Bohnsack Subject: Re: Proposed change 2004.1: extended route creation rules ... if this is, as stated, a rare event, would it not be better to have this be dealt with via a request to ripe-dbm? You can implement a Perl snippet that does the checks you describe without polluting the general DB code with what feels like a kludge.
Thats probably right for the moment and as far as I can remember this came to pass maybe 10 or 15 times in the last 2 years (for AS702). I think this will be more and more important in the near future and we should be prepared for it. Further I believe it would increase the user acceptance of routing registries and push tools such as IRRToolSet. Frank
Joao
On 9 Feb, 2004, at 15:07, Engin Gunduz wrote:
Dear colleagues,
[apologies for duplicate mails]
Some time ago, Frank brought an issue regarding route object aggregation to our attention in the DB-WG mailing list. Please see the short thread at:
http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00474.html http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00475.html
We have prepared a proposal to extend the route object creation rules to resolve this issue. However, the resulting proposal turns out to be quite complex as it builds on the current route object creation rules, which are already complex enough.
Considering that the need for route object aggregation is encountered very rarely, it might not be worth implementing it. After the deployment of version 3 of our whois software, we have seen only a couple of such cases. In those cases, we have resolved the issue by applying the rules that we specify below manually.
I would like to ask the working groups if they think this proposal is too complex. Implementing it would not be a problem technically, but I'm more concerned about explaining the complex rules properly to the users of the whois database.
Best regards, and thanks for your time, -- Engin Gunduz RIPE NCC Software Engineering Department
============================================================= A PROPOSAL FOR EXTENDED ROUTE OBJECT CREATION RULES
This document is about being able to create route objects that aggregate inetnums/route objects. This is needed where a user cannot merge two or more inetnum objects into one larger inetnum object, but still needs to create a route object that aggregates these inetnum objects. This is seen especially with assigned PI inetnum objects. A hypothetical example: Suppose there exist the following two inetnums in the whois database:
inetnum: 12.0.0.0 - 12.0.0.255 netname: EXAMPLE-PI descr: Example Banking PLC admin-c: AA1-RIPE status: ASSIGNED PI
inetnum: 12.0.1.0 - 12.0.1.255 netname: ANOTHER-EXAMPLE-PI descr: Anotherexample Printing Industries NV admin-c: ZZ1-RIPE status: ASSIGNED PI
These are assigned to different end-users. Further suppose that they coincidentally take service from the same Internet Service Provider. The Internet Service Provider will want to aggregate these two assignments into a single 12.0.0.0/23 route to be announced, rather than announcing two separate prefixes, in order to keep the number of prefixes in routing tables to the minimum. However, the Internet Provider will not be able to create a single route object in the RIPE Routing Registry which implements RPSSec RFC (RFC2725). This is because the inetnum object that contains the 12.0.0.0/23 prefix will be
inetnum: 12.0.0.0 - 12.9.255.255 netname: EU-ZZ-000000 descr: block for PI assignments descr: maintained by RIPE NCC country: EU remarks: These addresses are assigned to network operators. The RIPE NCC does not operate any networks using address space from this block. An explanation of how to find the correct contacts is available at <http://www.ripe.net/nicdb.html> admin-c: CREW-RIPE tech-c: CREW-RIPE tech-c: OPS4-RIPE status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT changed: hostmaster@ripe.net 20030731 source: RIPE
Note the "mnt-lower:" attribute that has RIPE-NCC-HM-MNT. See http://www.ripe.net/ripencc/faq/database/qa4.html#5 for a graphical representation of the current route object creation rules.
Proposal: To address this problem, we need to extend the route object creation rules so that it would be possible to create a route object that takes its authorisation from a collection of route and/or inetnum objects that are more specific than the route object to be created. As the situation is quite rare, the 'extended' behaviour can be activated by using the keyword 'EXTENDED-ROUTE-CREATION' in the subject line of the update message or with the syncupdates. The extended behaviour is not the default behaviour.
The Algorithm: The proposed algorithm to authorise the route object creation is:
Check if the keyword was used. If not, proceed with normal route creation rules as described in RFC2725 (http://www.ripe.net/ripencc/faq/database/qa4.html#5) Check if there is an exact match route object or an exact match inetnum object If there is one, then proceed with normal route creation rules even if the keyword was specified. Find the inetnums/routes that can be used for route creation: Get a list of all inetnums and route objects that are one level more specific than the route object to be created. (-r -Troute,inetnum -m <prefix>) From this list, eliminate the inetnums that have exact match or less specific route objects. (Note: During route object creation, the existing route objects take precedence over existing inetnum objects). Check if the resulting set of inetnums/routes cover the whole space of the route to be created. If not, authorisation fails, hence creation attempt fails. Collect the mntners to be used during the authorisation check. Follow these rules: For each object in the set, check if there are "mnt-routes:" attributes in the object. If there are, they will be used. If there are not, the mntners that are mentioned in "mnt-by:" attributes will be used. Check the authorisation: During the authorisation, the mntners in the same object will be ORed, while the mntners in separate objects will be ANDed.
Example 1:
Suppose we have these inetnums in the database:
inetnum: 0.0.0.0 - 255.255.255.255 status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-NONE-MNT
inetnum: 12.0.0.0 - 12.255.255.255 status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT
inetnum: 12.0.0.0 - 12.0.0.255 netname: EXAMPLE-PI descr: Example Banking PLC admin-c: AA1-RIPE status: ASSIGNED PI mnt-by: MNT-EXAMPLE-PI
inetnum: 12.0.1.0 - 12.0.1.255 netname: ANOTHER-EXAMPLE-PI descr: Anotherexample Printing Industries NV admin-c: ZZ1-RIPE status: ASSIGNED PI mnt-by: MNT-ANOTHEREXAMPLE-MNT-BY mnt-routes: MNT-ANOTHEREXAMPLE-MNT-ROUTES mnt-routes: MNT-ANOTHEREXAMPLE-MNT-ROUTES-2
There is also this aut-num object:
aut-num: AS65534 mnt-by: MNT-AUT-NUM-MNT-BY mnt-routes: MNT-AUT-NUM-MNT-ROUTES
There are no route objects that are in 12.0.0.0/23 space, or less specific of 12.0.0.0/23.
The user wants to create the following route object:
route: 12.0.0.0/23 origin: AS65534 mnt-by: MNT-ROUTE
When the creation is attempted without the keyword 'EXTENDED-ROUTE-CREATION,' the whois software will try to get the IP space authentication from inetnums, as no related route object exists. The one level less specific inetnum is 12.0.0.0 - 12.255.255.255, which has the attribute "mnt-lower: RIPE-NCC-HM-MNT". As the user does not have access to the authorisation for RIPE-NCC-HM-MNT mntner, the creation attempt will fail.
When the creation is attempted with the keyword 'EXTENDED-ROUTE-CREATION': - There are no exact match route or inetnum objects, so proceed with extended route creation rules. - to get the authorisation from IP space, the whois software will perform '-r -Troute,inetnum -m 12.0.0.0/23' query, which will return
inetnum: 12.0.0.0 - 12.0.0.255 inetnum: 12.0.1.0 - 12.0.1.255
- there are no inetnums to be eliminated from the list. - the resulting set of inetnums/routes (it actually has two inetnums and no routes) covers the whole space of 12.0.0.0/23. - collect the mntners to be used in the authorisation process. from the aut-num: MNT-AUT-NUM-MNT-ROUTES from the route object itself that will be created: MNT-ROUTE from the IP space: (MNT-EXAMPLE-PI AND (MNT-ANOTHEREXAMPLE-MNT-ROUTES OR MNT-ANOTHEREXAMPLE-MNT-ROUTES-2)) 12.0.0.0 - 12.0.0.255 does not have "mnt-routes:", so "mnt-by:" must be used. 12.0.1.0 - 12.0.1.255 has two "mnt-routes:", so they both must be used, but they must be ORed. - the resulting mntner list: ( MNT-AUT-NUM-MNT-ROUTES AND MNT-ROUTE AND ( MNT-EXAMPLE-PI AND ( MNT-ANOTHEREXAMPLE-MNT-ROUTES OR MNT-ANOTHEREXAMPLE-MNT-ROUTES-2 ) ) )
Example 2:
Suppose there are these inetnums in the database:
inetnum: 0.0.0.0 - 255.255.255.255 mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-NONE-MNT
inetnum: 12.0.0.0 - 12.255.255.255 mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT
inetnum: 12.0.0.0 - 12.0.0.255 mnt-routes: MNT-INETNUM-1
inetnum: 12.0.1.0 - 12.0.1.255 mnt-routes: MNT-INETNUM-2
and the following route objects:
route: 12.0.1.0/24 origin: AS65534 mnt-routes: MNT-ROUTE-1
route: 12.0.2.0/23 origin: AS6 mnt-routes: MNT-ROUTE-2
route: 12.0.2.0/23 origin: AS65534 mnt-routes: MNT-ROUTE-3 mnt-routes: MNT-ROUTE-4
and this aut-num:
aut-num: AS65534 mnt-by: MNT-AUT-NUM-MNT-BY mnt-routes: MNT-AUT-NUM-MNT-ROUTES
The user wants to create the following route object:
route: 12.0.0.0/22 origin: AS65534 mnt-by: MNT-ROUTE
When the creation is attempted without the keyword 'EXTENDED-ROUTE-CREATION,' the whois software will try to get the IP space authentication from inetnums, as no related route object exists. The one level less specific inetnum is 12.0.0.0 - 12.255.255.255, which has "mnt-lower: RIPE-NCC-HM-MNT" attribute. As the user does not have access to the authorisation for RIPE-NCC-HM-MNT mntner, the creation attempt will fail.
When the creation is attempted with the keyword 'EXTENDED-ROUTE-CREATION': - There are no exact match route or inetnum objects, so proceed with extended route creation rules. - to get the authorisation from IP space, the whois software will perform '-r -Troute,inetnum -m 12.0.0.0/22' query, which will return
inetnum: 12.0.0.0 - 12.0.0.255 inetnum: 12.0.1.0 - 12.0.1.255 route: 12.0.1.0/24 route: 12.0.2.0/23 (origin AS6) route: 12.0.2.0/23 (origin AS65534)
- eliminate the inetnums with less specific or exact match route objects in the list. The resulting list will be:
inetnum: 12.0.0.0 - 12.0.0.255 route: 12.0.1.0/24 route: 12.0.2.0/23 (origin AS6) route: 12.0.2.0/23 (origin AS65534)
- the resulting list covers the whole 12.0.0.0/22 space. Continue. - Collect the mntners to be used during the authorisation check. from the aut-num: MNT-AUT-NUM-MNT-ROUTES from the route object itself that will be created: MNT-ROUTE from the IP space: (MNT-INETNUM-1 AND MNT-ROUTE-1 AND (MNT-ROUTE-2 AND (MNT-ROUTE-3 OR MNT-ROUTE-4)))
- the resulting mntner list: ( MNT-AUT-NUM-MNT-ROUTES AND MNT-ROUTE AND ( ( MNT-INETNUM-1 AND MNT-ROUTE-1 AND ( MNT-ROUTE-2 AND ( MNT-ROUTE-3 OR MNT-ROUTE-4 ) ) ) ) )
Hi, On 2004-02-09 22:29:37 +0100, Frank Bohnsack wrote:
Hi,
-----Original Message----- From: routing-wg-admin@ripe.net [mailto:routing-wg-admin@ripe.net]On Behalf Of Joao Damas Sent: Monday, February 09, 2004 3:55 PM To: Engin Gunduz Cc: routing-wg@ripe.net; db-wg@ripe.net; Frank Bohnsack Subject: Re: Proposed change 2004.1: extended route creation rules ... if this is, as stated, a rare event, would it not be better to have this be dealt with via a request to ripe-dbm? You can implement a Perl snippet that does the checks you describe without polluting the general DB code with what feels like a kludge.
Thats probably right for the moment and as far as I can remember this came to pass maybe 10 or 15 times in the last 2 years (for AS702).
Hm, this is more than I expected in fact (10-15 cases for a single ASN) even if this is a quite big autonomous system. I remember dealing with one of these, but have you sent the others to ripe-dbm@ripe.net as well, or just gave up trying to create them (as it would take ripe-dbm some time to figure out what's going on;)). Is there anybody else in the mailing lists who encountered similar cases? Regards, -engin Engin Gunduz RIPE NCC Software Engineering Department
I think this will be more and more important in the near future and we should be prepared for it. Further I believe it would increase the user acceptance of routing registries and push tools such as IRRToolSet.
Frank
Joao
On 9 Feb, 2004, at 15:07, Engin Gunduz wrote:
Dear colleagues,
[apologies for duplicate mails]
Some time ago, Frank brought an issue regarding route object aggregation to our attention in the DB-WG mailing list. Please see the short thread at:
http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00474.html http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00475.html
We have prepared a proposal to extend the route object creation rules to resolve this issue. However, the resulting proposal turns out to be quite complex as it builds on the current route object creation rules, which are already complex enough.
Considering that the need for route object aggregation is encountered very rarely, it might not be worth implementing it. After the deployment of version 3 of our whois software, we have seen only a couple of such cases. In those cases, we have resolved the issue by applying the rules that we specify below manually.
I would like to ask the working groups if they think this proposal is too complex. Implementing it would not be a problem technically, but I'm more concerned about explaining the complex rules properly to the users of the whois database.
Best regards, and thanks for your time, -- Engin Gunduz RIPE NCC Software Engineering Department
============================================================= A PROPOSAL FOR EXTENDED ROUTE OBJECT CREATION RULES
This document is about being able to create route objects that aggregate inetnums/route objects. This is needed where a user cannot merge two or more inetnum objects into one larger inetnum object, but still needs to create a route object that aggregates these inetnum objects. This is seen especially with assigned PI inetnum objects. A hypothetical example: Suppose there exist the following two inetnums in the whois database:
inetnum: 12.0.0.0 - 12.0.0.255 netname: EXAMPLE-PI descr: Example Banking PLC admin-c: AA1-RIPE status: ASSIGNED PI
inetnum: 12.0.1.0 - 12.0.1.255 netname: ANOTHER-EXAMPLE-PI descr: Anotherexample Printing Industries NV admin-c: ZZ1-RIPE status: ASSIGNED PI
These are assigned to different end-users. Further suppose that they coincidentally take service from the same Internet Service Provider. The Internet Service Provider will want to aggregate these two assignments into a single 12.0.0.0/23 route to be announced, rather than announcing two separate prefixes, in order to keep the number of prefixes in routing tables to the minimum. However, the Internet Provider will not be able to create a single route object in the RIPE Routing Registry which implements RPSSec RFC (RFC2725). This is because the inetnum object that contains the 12.0.0.0/23 prefix will be
inetnum: 12.0.0.0 - 12.9.255.255 netname: EU-ZZ-000000 descr: block for PI assignments descr: maintained by RIPE NCC country: EU remarks: These addresses are assigned to network operators. The RIPE NCC does not operate any networks using address space from this block. An explanation of how to find the correct contacts is available at <http://www.ripe.net/nicdb.html> admin-c: CREW-RIPE tech-c: CREW-RIPE tech-c: OPS4-RIPE status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT changed: hostmaster@ripe.net 20030731 source: RIPE
Note the "mnt-lower:" attribute that has RIPE-NCC-HM-MNT. See http://www.ripe.net/ripencc/faq/database/qa4.html#5 for a graphical representation of the current route object creation rules.
Proposal: To address this problem, we need to extend the route object creation rules so that it would be possible to create a route object that takes its authorisation from a collection of route and/or inetnum objects that are more specific than the route object to be created. As the situation is quite rare, the 'extended' behaviour can be activated by using the keyword 'EXTENDED-ROUTE-CREATION' in the subject line of the update message or with the syncupdates. The extended behaviour is not the default behaviour.
The Algorithm: The proposed algorithm to authorise the route object creation is:
Check if the keyword was used. If not, proceed with normal route creation rules as described in RFC2725 (http://www.ripe.net/ripencc/faq/database/qa4.html#5) Check if there is an exact match route object or an exact match inetnum object If there is one, then proceed with normal route creation rules even if the keyword was specified. Find the inetnums/routes that can be used for route creation: Get a list of all inetnums and route objects that are one level more specific than the route object to be created. (-r -Troute,inetnum -m <prefix>) From this list, eliminate the inetnums that have exact match or less specific route objects. (Note: During route object creation, the existing route objects take precedence over existing inetnum objects). Check if the resulting set of inetnums/routes cover the whole space of the route to be created. If not, authorisation fails, hence creation attempt fails. Collect the mntners to be used during the authorisation check. Follow these rules: For each object in the set, check if there are "mnt-routes:" attributes in the object. If there are, they will be used. If there are not, the mntners that are mentioned in "mnt-by:" attributes will be used. Check the authorisation: During the authorisation, the mntners in the same object will be ORed, while the mntners in separate objects will be ANDed.
Example 1:
Suppose we have these inetnums in the database:
inetnum: 0.0.0.0 - 255.255.255.255 status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-NONE-MNT
inetnum: 12.0.0.0 - 12.255.255.255 status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT
inetnum: 12.0.0.0 - 12.0.0.255 netname: EXAMPLE-PI descr: Example Banking PLC admin-c: AA1-RIPE status: ASSIGNED PI mnt-by: MNT-EXAMPLE-PI
inetnum: 12.0.1.0 - 12.0.1.255 netname: ANOTHER-EXAMPLE-PI descr: Anotherexample Printing Industries NV admin-c: ZZ1-RIPE status: ASSIGNED PI mnt-by: MNT-ANOTHEREXAMPLE-MNT-BY mnt-routes: MNT-ANOTHEREXAMPLE-MNT-ROUTES mnt-routes: MNT-ANOTHEREXAMPLE-MNT-ROUTES-2
There is also this aut-num object:
aut-num: AS65534 mnt-by: MNT-AUT-NUM-MNT-BY mnt-routes: MNT-AUT-NUM-MNT-ROUTES
There are no route objects that are in 12.0.0.0/23 space, or less specific of 12.0.0.0/23.
The user wants to create the following route object:
route: 12.0.0.0/23 origin: AS65534 mnt-by: MNT-ROUTE
When the creation is attempted without the keyword 'EXTENDED-ROUTE-CREATION,' the whois software will try to get the IP space authentication from inetnums, as no related route object exists. The one level less specific inetnum is 12.0.0.0 - 12.255.255.255, which has the attribute "mnt-lower: RIPE-NCC-HM-MNT". As the user does not have access to the authorisation for RIPE-NCC-HM-MNT mntner, the creation attempt will fail.
When the creation is attempted with the keyword 'EXTENDED-ROUTE-CREATION': - There are no exact match route or inetnum objects, so proceed with extended route creation rules. - to get the authorisation from IP space, the whois software will perform '-r -Troute,inetnum -m 12.0.0.0/23' query, which will return
inetnum: 12.0.0.0 - 12.0.0.255 inetnum: 12.0.1.0 - 12.0.1.255
- there are no inetnums to be eliminated from the list. - the resulting set of inetnums/routes (it actually has two inetnums and no routes) covers the whole space of 12.0.0.0/23. - collect the mntners to be used in the authorisation process. from the aut-num: MNT-AUT-NUM-MNT-ROUTES from the route object itself that will be created: MNT-ROUTE from the IP space: (MNT-EXAMPLE-PI AND (MNT-ANOTHEREXAMPLE-MNT-ROUTES OR MNT-ANOTHEREXAMPLE-MNT-ROUTES-2)) 12.0.0.0 - 12.0.0.255 does not have "mnt-routes:", so "mnt-by:" must be used. 12.0.1.0 - 12.0.1.255 has two "mnt-routes:", so they both must be used, but they must be ORed. - the resulting mntner list: ( MNT-AUT-NUM-MNT-ROUTES AND MNT-ROUTE AND ( MNT-EXAMPLE-PI AND ( MNT-ANOTHEREXAMPLE-MNT-ROUTES OR MNT-ANOTHEREXAMPLE-MNT-ROUTES-2 ) ) )
Example 2:
Suppose there are these inetnums in the database:
inetnum: 0.0.0.0 - 255.255.255.255 mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-NONE-MNT
inetnum: 12.0.0.0 - 12.255.255.255 mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT
inetnum: 12.0.0.0 - 12.0.0.255 mnt-routes: MNT-INETNUM-1
inetnum: 12.0.1.0 - 12.0.1.255 mnt-routes: MNT-INETNUM-2
and the following route objects:
route: 12.0.1.0/24 origin: AS65534 mnt-routes: MNT-ROUTE-1
route: 12.0.2.0/23 origin: AS6 mnt-routes: MNT-ROUTE-2
route: 12.0.2.0/23 origin: AS65534 mnt-routes: MNT-ROUTE-3 mnt-routes: MNT-ROUTE-4
and this aut-num:
aut-num: AS65534 mnt-by: MNT-AUT-NUM-MNT-BY mnt-routes: MNT-AUT-NUM-MNT-ROUTES
The user wants to create the following route object:
route: 12.0.0.0/22 origin: AS65534 mnt-by: MNT-ROUTE
When the creation is attempted without the keyword 'EXTENDED-ROUTE-CREATION,' the whois software will try to get the IP space authentication from inetnums, as no related route object exists. The one level less specific inetnum is 12.0.0.0 - 12.255.255.255, which has "mnt-lower: RIPE-NCC-HM-MNT" attribute. As the user does not have access to the authorisation for RIPE-NCC-HM-MNT mntner, the creation attempt will fail.
When the creation is attempted with the keyword 'EXTENDED-ROUTE-CREATION': - There are no exact match route or inetnum objects, so proceed with extended route creation rules. - to get the authorisation from IP space, the whois software will perform '-r -Troute,inetnum -m 12.0.0.0/22' query, which will return
inetnum: 12.0.0.0 - 12.0.0.255 inetnum: 12.0.1.0 - 12.0.1.255 route: 12.0.1.0/24 route: 12.0.2.0/23 (origin AS6) route: 12.0.2.0/23 (origin AS65534)
- eliminate the inetnums with less specific or exact match route objects in the list. The resulting list will be:
inetnum: 12.0.0.0 - 12.0.0.255 route: 12.0.1.0/24 route: 12.0.2.0/23 (origin AS6) route: 12.0.2.0/23 (origin AS65534)
- the resulting list covers the whole 12.0.0.0/22 space. Continue. - Collect the mntners to be used during the authorisation check. from the aut-num: MNT-AUT-NUM-MNT-ROUTES from the route object itself that will be created: MNT-ROUTE from the IP space: (MNT-INETNUM-1 AND MNT-ROUTE-1 AND (MNT-ROUTE-2 AND (MNT-ROUTE-3 OR MNT-ROUTE-4)))
- the resulting mntner list: ( MNT-AUT-NUM-MNT-ROUTES AND MNT-ROUTE AND ( ( MNT-INETNUM-1 AND MNT-ROUTE-1 AND ( MNT-ROUTE-2 AND ( MNT-ROUTE-3 OR MNT-ROUTE-4 ) ) ) ) )
-----Original Message----- From: routing-wg-admin@ripe.net [mailto:routing-wg-admin@ripe.net]On Behalf Of Engin Gunduz Sent: Monday, February 16, 2004 4:53 PM To: Frank Bohnsack Cc: Joao Damas; routing-wg@ripe.net; db-wg@ripe.net Subject: Re: Proposed change 2004.1: extended route creation rules
Hi,
On 2004-02-09 22:29:37 +0100, Frank Bohnsack wrote:
Hi,
-----Original Message----- From: routing-wg-admin@ripe.net [mailto:routing-wg-admin@ripe.net]On Behalf Of Joao Damas Sent: Monday, February 09, 2004 3:55 PM To: Engin Gunduz Cc: routing-wg@ripe.net; db-wg@ripe.net; Frank Bohnsack Subject: Re: Proposed change 2004.1: extended route creation rules ... if this is, as stated, a rare event, would it not be better to have this be dealt with via a request to ripe-dbm? You can implement a Perl snippet that does the checks you describe without polluting the general DB code with what feels like a kludge.
Thats probably right for the moment and as far as I can remember this came to pass maybe 10 or 15 times in the last 2 years (for AS702).
Hm, this is more than I expected in fact (10-15 cases for a single ASN) even if this is a quite big autonomous system. I remember dealing with one of these, but have you sent the others to ripe-dbm@ripe.net as well, or just gave up trying to create them (as it would take ripe-dbm some time to figure out what's going on;)).
The 10-15 means, we have 10-15 routes of aggregated customer ("PI") space (different customer owned blocks which could be aggregated) which are mostly not documented any where and therefore dont break security issues in the RIPE DB. Frank
Is there anybody else in the mailing lists who encountered similar cases?
Regards, -engin
Engin Gunduz RIPE NCC Software Engineering Department
I think this will be more and more important in the near future and we should be prepared for it. Further I believe it would increase the user acceptance of routing registries and push tools such as IRRToolSet.
Frank
Joao
On 9 Feb, 2004, at 15:07, Engin Gunduz wrote:
Dear colleagues,
[apologies for duplicate mails]
Some time ago, Frank brought an issue regarding route object aggregation to our attention in the DB-WG mailing list. Please see the short thread at:
http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00474.html http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00475.html
We have prepared a proposal to extend the route object creation rules to resolve this issue. However, the resulting proposal turns out to be quite complex as it builds on the current route object creation rules, which are already complex enough.
Considering that the need for route object aggregation is encountered very rarely, it might not be worth implementing it. After the deployment of version 3 of our whois software, we have seen only a couple of such cases. In those cases, we have resolved the issue by applying the rules that we specify below manually.
I would like to ask the working groups if they think this proposal is too complex. Implementing it would not be a problem technically, but I'm more concerned about explaining the complex rules properly to the users of the whois database.
Best regards, and thanks for your time, -- Engin Gunduz RIPE NCC Software Engineering Department
============================================================= A PROPOSAL FOR EXTENDED ROUTE OBJECT CREATION RULES
This document is about being able to create route objects that aggregate inetnums/route objects. This is needed where a user cannot merge two or more inetnum objects into one larger inetnum object, but still needs to create a route object that aggregates these inetnum objects. This is seen especially with assigned PI inetnum objects. A hypothetical example: Suppose there exist the following two inetnums in the whois database:
inetnum: 12.0.0.0 - 12.0.0.255 netname: EXAMPLE-PI descr: Example Banking PLC admin-c: AA1-RIPE status: ASSIGNED PI
inetnum: 12.0.1.0 - 12.0.1.255 netname: ANOTHER-EXAMPLE-PI descr: Anotherexample Printing Industries NV admin-c: ZZ1-RIPE status: ASSIGNED PI
These are assigned to different end-users. Further suppose that they coincidentally take service from the same Internet Service Provider. The Internet Service Provider will want to aggregate these two assignments into a single 12.0.0.0/23 route to be announced, rather than announcing two separate prefixes, in order to keep the number of prefixes in routing tables to the minimum. However, the Internet Provider will not be able to create a single route object in the RIPE Routing Registry which implements RPSSec RFC (RFC2725). This is because the inetnum object that contains the 12.0.0.0/23 prefix will be
inetnum: 12.0.0.0 - 12.9.255.255 netname: EU-ZZ-000000 descr: block for PI assignments descr: maintained by RIPE NCC country: EU remarks: These addresses are assigned to network operators. The RIPE NCC does not operate any networks using address space from this block. An explanation of how to find the correct contacts is available at <http://www.ripe.net/nicdb.html> admin-c: CREW-RIPE tech-c: CREW-RIPE tech-c: OPS4-RIPE status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT changed: hostmaster@ripe.net 20030731 source: RIPE
Note the "mnt-lower:" attribute that has RIPE-NCC-HM-MNT. See http://www.ripe.net/ripencc/faq/database/qa4.html#5 for a graphical representation of the current route object creation rules.
Proposal: To address this problem, we need to extend the route object creation rules so that it would be possible to create a route object that takes its authorisation from a collection of route and/or inetnum objects that are more specific than the route object to be created. As the situation is quite rare, the 'extended' behaviour can be activated by using the keyword 'EXTENDED-ROUTE-CREATION' in the subject line of the update message or with the syncupdates. The extended behaviour is not the default behaviour.
The Algorithm: The proposed algorithm to authorise the route object creation is:
Check if the keyword was used. If not, proceed with normal route creation rules as described in RFC2725 (http://www.ripe.net/ripencc/faq/database/qa4.html#5) Check if there is an exact match route object or an exact match inetnum object If there is one, then proceed with normal route creation rules even if the keyword was specified. Find the inetnums/routes that can be used for route creation: Get a list of all inetnums and route objects that are one level more specific than the route object to be created. (-r -Troute,inetnum -m <prefix>) From this list, eliminate the inetnums that have exact match or less specific route objects. (Note: During route object creation, the existing route objects take precedence over existing inetnum objects). Check if the resulting set of inetnums/routes cover the whole space of the route to be created. If not, authorisation fails, hence creation attempt fails. Collect the mntners to be used during the authorisation check. Follow these rules: For each object in the set, check if there are "mnt-routes:" attributes in the object. If there are, they will be used. If there are not, the mntners that are mentioned in "mnt-by:" attributes will be used. Check the authorisation: During the authorisation, the mntners in the same object will be ORed, while the mntners in separate objects will be ANDed.
Example 1:
Suppose we have these inetnums in the database:
inetnum: 0.0.0.0 - 255.255.255.255 status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-NONE-MNT
inetnum: 12.0.0.0 - 12.255.255.255 status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT
inetnum: 12.0.0.0 - 12.0.0.255 netname: EXAMPLE-PI descr: Example Banking PLC admin-c: AA1-RIPE status: ASSIGNED PI mnt-by: MNT-EXAMPLE-PI
inetnum: 12.0.1.0 - 12.0.1.255 netname: ANOTHER-EXAMPLE-PI descr: Anotherexample Printing Industries NV admin-c: ZZ1-RIPE status: ASSIGNED PI mnt-by: MNT-ANOTHEREXAMPLE-MNT-BY mnt-routes: MNT-ANOTHEREXAMPLE-MNT-ROUTES mnt-routes: MNT-ANOTHEREXAMPLE-MNT-ROUTES-2
There is also this aut-num object:
aut-num: AS65534 mnt-by: MNT-AUT-NUM-MNT-BY mnt-routes: MNT-AUT-NUM-MNT-ROUTES
There are no route objects that are in 12.0.0.0/23 space, or less specific of 12.0.0.0/23.
The user wants to create the following route object:
route: 12.0.0.0/23 origin: AS65534 mnt-by: MNT-ROUTE
When the creation is attempted without the keyword 'EXTENDED-ROUTE-CREATION,' the whois software will try to get the IP space authentication from inetnums, as no related route object exists. The one level less specific inetnum is 12.0.0.0 - 12.255.255.255, which has the attribute "mnt-lower: RIPE-NCC-HM-MNT". As the user does not have access to the authorisation for RIPE-NCC-HM-MNT mntner, the creation attempt will fail.
When the creation is attempted with the keyword 'EXTENDED-ROUTE-CREATION': - There are no exact match route or inetnum objects, so proceed with extended route creation rules. - to get the authorisation from IP space, the whois software will perform '-r -Troute,inetnum -m 12.0.0.0/23' query, which will return
inetnum: 12.0.0.0 - 12.0.0.255 inetnum: 12.0.1.0 - 12.0.1.255
- there are no inetnums to be eliminated from the list. - the resulting set of inetnums/routes (it actually has two inetnums and no routes) covers the whole space of 12.0.0.0/23. - collect the mntners to be used in the authorisation process. from the aut-num: MNT-AUT-NUM-MNT-ROUTES from the route object itself that will be created: MNT-ROUTE from the IP space: (MNT-EXAMPLE-PI AND (MNT-ANOTHEREXAMPLE-MNT-ROUTES OR MNT-ANOTHEREXAMPLE-MNT-ROUTES-2)) 12.0.0.0 - 12.0.0.255 does not have "mnt-routes:", so "mnt-by:" must be used. 12.0.1.0 - 12.0.1.255 has two "mnt-routes:", so they both must be used, but they must be ORed. - the resulting mntner list: ( MNT-AUT-NUM-MNT-ROUTES AND MNT-ROUTE AND ( MNT-EXAMPLE-PI AND ( MNT-ANOTHEREXAMPLE-MNT-ROUTES OR MNT-ANOTHEREXAMPLE-MNT-ROUTES-2 ) ) )
Example 2:
Suppose there are these inetnums in the database:
inetnum: 0.0.0.0 - 255.255.255.255 mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-NONE-MNT
inetnum: 12.0.0.0 - 12.255.255.255 mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT
inetnum: 12.0.0.0 - 12.0.0.255 mnt-routes: MNT-INETNUM-1
inetnum: 12.0.1.0 - 12.0.1.255 mnt-routes: MNT-INETNUM-2
and the following route objects:
route: 12.0.1.0/24 origin: AS65534 mnt-routes: MNT-ROUTE-1
route: 12.0.2.0/23 origin: AS6 mnt-routes: MNT-ROUTE-2
route: 12.0.2.0/23 origin: AS65534 mnt-routes: MNT-ROUTE-3 mnt-routes: MNT-ROUTE-4
and this aut-num:
aut-num: AS65534 mnt-by: MNT-AUT-NUM-MNT-BY mnt-routes: MNT-AUT-NUM-MNT-ROUTES
The user wants to create the following route object:
route: 12.0.0.0/22 origin: AS65534 mnt-by: MNT-ROUTE
When the creation is attempted without the keyword 'EXTENDED-ROUTE-CREATION,' the whois software will try to get the IP space authentication from inetnums, as no related route object exists. The one level less specific inetnum is 12.0.0.0 - 12.255.255.255, which has "mnt-lower: RIPE-NCC-HM-MNT" attribute. As the user does not have access to the authorisation for RIPE-NCC-HM-MNT mntner, the creation attempt will fail.
When the creation is attempted with the keyword 'EXTENDED-ROUTE-CREATION': - There are no exact match route or inetnum objects, so proceed with extended route creation rules. - to get the authorisation from IP space, the whois software will perform '-r -Troute,inetnum -m 12.0.0.0/22' query, which will return
inetnum: 12.0.0.0 - 12.0.0.255 inetnum: 12.0.1.0 - 12.0.1.255 route: 12.0.1.0/24 route: 12.0.2.0/23 (origin AS6) route: 12.0.2.0/23 (origin AS65534)
- eliminate the inetnums with less specific or exact match route objects in the list. The resulting list will be:
inetnum: 12.0.0.0 - 12.0.0.255 route: 12.0.1.0/24 route: 12.0.2.0/23 (origin AS6) route: 12.0.2.0/23 (origin AS65534)
- the resulting list covers the whole 12.0.0.0/22 space. Continue. - Collect the mntners to be used during the authorisation check. from the aut-num: MNT-AUT-NUM-MNT-ROUTES from the route object itself that will be created: MNT-ROUTE from the IP space: (MNT-INETNUM-1 AND MNT-ROUTE-1 AND (MNT-ROUTE-2 AND (MNT-ROUTE-3 OR MNT-ROUTE-4)))
- the resulting mntner list: ( MNT-AUT-NUM-MNT-ROUTES AND MNT-ROUTE AND ( ( MNT-INETNUM-1 AND MNT-ROUTE-1 AND ( MNT-ROUTE-2 AND ( MNT-ROUTE-3 OR MNT-ROUTE-4 ) ) ) ) )
Hi,
-----Original Message----- From: routing-wg-admin@ripe.net [mailto:routing-wg-admin@ripe.net]On Behalf Of Joao Damas Sent: Monday, February 09, 2004 3:55 PM To: Engin Gunduz Cc: routing-wg@ripe.net; db-wg@ripe.net; Frank Bohnsack Subject: Re: Proposed change 2004.1: extended route creation rules ... if this is, as stated, a rare event, would it not be better to have this be dealt with via a request to ripe-dbm? You can implement a Perl snippet that does the checks you describe without polluting the general DB code with what feels like a kludge.
Thats probably right for the moment and as far as I can remember this came to pass maybe 10 or 15 times in the last 2 years (for AS702). I think this will be more and more important in the near future and we should be prepared for it. Further I believe it would increase the user acceptance of routing registries and push tools such as IRRToolSet. Frank
Joao
On 9 Feb, 2004, at 15:07, Engin Gunduz wrote:
Dear colleagues,
[apologies for duplicate mails]
Some time ago, Frank brought an issue regarding route object aggregation to our attention in the DB-WG mailing list. Please see the short thread at:
http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00474.html http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00475.html
We have prepared a proposal to extend the route object creation rules to resolve this issue. However, the resulting proposal turns out to be quite complex as it builds on the current route object creation rules, which are already complex enough.
Considering that the need for route object aggregation is encountered very rarely, it might not be worth implementing it. After the deployment of version 3 of our whois software, we have seen only a couple of such cases. In those cases, we have resolved the issue by applying the rules that we specify below manually.
I would like to ask the working groups if they think this proposal is too complex. Implementing it would not be a problem technically, but I'm more concerned about explaining the complex rules properly to the users of the whois database.
Best regards, and thanks for your time, -- Engin Gunduz RIPE NCC Software Engineering Department
============================================================= A PROPOSAL FOR EXTENDED ROUTE OBJECT CREATION RULES
This document is about being able to create route objects that aggregate inetnums/route objects. This is needed where a user cannot merge two or more inetnum objects into one larger inetnum object, but still needs to create a route object that aggregates these inetnum objects. This is seen especially with assigned PI inetnum objects. A hypothetical example: Suppose there exist the following two inetnums in the whois database:
inetnum: 12.0.0.0 - 12.0.0.255 netname: EXAMPLE-PI descr: Example Banking PLC admin-c: AA1-RIPE status: ASSIGNED PI
inetnum: 12.0.1.0 - 12.0.1.255 netname: ANOTHER-EXAMPLE-PI descr: Anotherexample Printing Industries NV admin-c: ZZ1-RIPE status: ASSIGNED PI
These are assigned to different end-users. Further suppose that they coincidentally take service from the same Internet Service Provider. The Internet Service Provider will want to aggregate these two assignments into a single 12.0.0.0/23 route to be announced, rather than announcing two separate prefixes, in order to keep the number of prefixes in routing tables to the minimum. However, the Internet Provider will not be able to create a single route object in the RIPE Routing Registry which implements RPSSec RFC (RFC2725). This is because the inetnum object that contains the 12.0.0.0/23 prefix will be
inetnum: 12.0.0.0 - 12.9.255.255 netname: EU-ZZ-000000 descr: block for PI assignments descr: maintained by RIPE NCC country: EU remarks: These addresses are assigned to network operators. The RIPE NCC does not operate any networks using address space from this block. An explanation of how to find the correct contacts is available at <http://www.ripe.net/nicdb.html> admin-c: CREW-RIPE tech-c: CREW-RIPE tech-c: OPS4-RIPE status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT changed: hostmaster@ripe.net 20030731 source: RIPE
Note the "mnt-lower:" attribute that has RIPE-NCC-HM-MNT. See http://www.ripe.net/ripencc/faq/database/qa4.html#5 for a graphical representation of the current route object creation rules.
Proposal: To address this problem, we need to extend the route object creation rules so that it would be possible to create a route object that takes its authorisation from a collection of route and/or inetnum objects that are more specific than the route object to be created. As the situation is quite rare, the 'extended' behaviour can be activated by using the keyword 'EXTENDED-ROUTE-CREATION' in the subject line of the update message or with the syncupdates. The extended behaviour is not the default behaviour.
The Algorithm: The proposed algorithm to authorise the route object creation is:
Check if the keyword was used. If not, proceed with normal route creation rules as described in RFC2725 (http://www.ripe.net/ripencc/faq/database/qa4.html#5) Check if there is an exact match route object or an exact match inetnum object If there is one, then proceed with normal route creation rules even if the keyword was specified. Find the inetnums/routes that can be used for route creation: Get a list of all inetnums and route objects that are one level more specific than the route object to be created. (-r -Troute,inetnum -m <prefix>) From this list, eliminate the inetnums that have exact match or less specific route objects. (Note: During route object creation, the existing route objects take precedence over existing inetnum objects). Check if the resulting set of inetnums/routes cover the whole space of the route to be created. If not, authorisation fails, hence creation attempt fails. Collect the mntners to be used during the authorisation check. Follow these rules: For each object in the set, check if there are "mnt-routes:" attributes in the object. If there are, they will be used. If there are not, the mntners that are mentioned in "mnt-by:" attributes will be used. Check the authorisation: During the authorisation, the mntners in the same object will be ORed, while the mntners in separate objects will be ANDed.
Example 1:
Suppose we have these inetnums in the database:
inetnum: 0.0.0.0 - 255.255.255.255 status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-NONE-MNT
inetnum: 12.0.0.0 - 12.255.255.255 status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT
inetnum: 12.0.0.0 - 12.0.0.255 netname: EXAMPLE-PI descr: Example Banking PLC admin-c: AA1-RIPE status: ASSIGNED PI mnt-by: MNT-EXAMPLE-PI
inetnum: 12.0.1.0 - 12.0.1.255 netname: ANOTHER-EXAMPLE-PI descr: Anotherexample Printing Industries NV admin-c: ZZ1-RIPE status: ASSIGNED PI mnt-by: MNT-ANOTHEREXAMPLE-MNT-BY mnt-routes: MNT-ANOTHEREXAMPLE-MNT-ROUTES mnt-routes: MNT-ANOTHEREXAMPLE-MNT-ROUTES-2
There is also this aut-num object:
aut-num: AS65534 mnt-by: MNT-AUT-NUM-MNT-BY mnt-routes: MNT-AUT-NUM-MNT-ROUTES
There are no route objects that are in 12.0.0.0/23 space, or less specific of 12.0.0.0/23.
The user wants to create the following route object:
route: 12.0.0.0/23 origin: AS65534 mnt-by: MNT-ROUTE
When the creation is attempted without the keyword 'EXTENDED-ROUTE-CREATION,' the whois software will try to get the IP space authentication from inetnums, as no related route object exists. The one level less specific inetnum is 12.0.0.0 - 12.255.255.255, which has the attribute "mnt-lower: RIPE-NCC-HM-MNT". As the user does not have access to the authorisation for RIPE-NCC-HM-MNT mntner, the creation attempt will fail.
When the creation is attempted with the keyword 'EXTENDED-ROUTE-CREATION': - There are no exact match route or inetnum objects, so proceed with extended route creation rules. - to get the authorisation from IP space, the whois software will perform '-r -Troute,inetnum -m 12.0.0.0/23' query, which will return
inetnum: 12.0.0.0 - 12.0.0.255 inetnum: 12.0.1.0 - 12.0.1.255
- there are no inetnums to be eliminated from the list. - the resulting set of inetnums/routes (it actually has two inetnums and no routes) covers the whole space of 12.0.0.0/23. - collect the mntners to be used in the authorisation process. from the aut-num: MNT-AUT-NUM-MNT-ROUTES from the route object itself that will be created: MNT-ROUTE from the IP space: (MNT-EXAMPLE-PI AND (MNT-ANOTHEREXAMPLE-MNT-ROUTES OR MNT-ANOTHEREXAMPLE-MNT-ROUTES-2)) 12.0.0.0 - 12.0.0.255 does not have "mnt-routes:", so "mnt-by:" must be used. 12.0.1.0 - 12.0.1.255 has two "mnt-routes:", so they both must be used, but they must be ORed. - the resulting mntner list: ( MNT-AUT-NUM-MNT-ROUTES AND MNT-ROUTE AND ( MNT-EXAMPLE-PI AND ( MNT-ANOTHEREXAMPLE-MNT-ROUTES OR MNT-ANOTHEREXAMPLE-MNT-ROUTES-2 ) ) )
Example 2:
Suppose there are these inetnums in the database:
inetnum: 0.0.0.0 - 255.255.255.255 mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-NONE-MNT
inetnum: 12.0.0.0 - 12.255.255.255 mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT
inetnum: 12.0.0.0 - 12.0.0.255 mnt-routes: MNT-INETNUM-1
inetnum: 12.0.1.0 - 12.0.1.255 mnt-routes: MNT-INETNUM-2
and the following route objects:
route: 12.0.1.0/24 origin: AS65534 mnt-routes: MNT-ROUTE-1
route: 12.0.2.0/23 origin: AS6 mnt-routes: MNT-ROUTE-2
route: 12.0.2.0/23 origin: AS65534 mnt-routes: MNT-ROUTE-3 mnt-routes: MNT-ROUTE-4
and this aut-num:
aut-num: AS65534 mnt-by: MNT-AUT-NUM-MNT-BY mnt-routes: MNT-AUT-NUM-MNT-ROUTES
The user wants to create the following route object:
route: 12.0.0.0/22 origin: AS65534 mnt-by: MNT-ROUTE
When the creation is attempted without the keyword 'EXTENDED-ROUTE-CREATION,' the whois software will try to get the IP space authentication from inetnums, as no related route object exists. The one level less specific inetnum is 12.0.0.0 - 12.255.255.255, which has "mnt-lower: RIPE-NCC-HM-MNT" attribute. As the user does not have access to the authorisation for RIPE-NCC-HM-MNT mntner, the creation attempt will fail.
When the creation is attempted with the keyword 'EXTENDED-ROUTE-CREATION': - There are no exact match route or inetnum objects, so proceed with extended route creation rules. - to get the authorisation from IP space, the whois software will perform '-r -Troute,inetnum -m 12.0.0.0/22' query, which will return
inetnum: 12.0.0.0 - 12.0.0.255 inetnum: 12.0.1.0 - 12.0.1.255 route: 12.0.1.0/24 route: 12.0.2.0/23 (origin AS6) route: 12.0.2.0/23 (origin AS65534)
- eliminate the inetnums with less specific or exact match route objects in the list. The resulting list will be:
inetnum: 12.0.0.0 - 12.0.0.255 route: 12.0.1.0/24 route: 12.0.2.0/23 (origin AS6) route: 12.0.2.0/23 (origin AS65534)
- the resulting list covers the whole 12.0.0.0/22 space. Continue. - Collect the mntners to be used during the authorisation check. from the aut-num: MNT-AUT-NUM-MNT-ROUTES from the route object itself that will be created: MNT-ROUTE from the IP space: (MNT-INETNUM-1 AND MNT-ROUTE-1 AND (MNT-ROUTE-2 AND (MNT-ROUTE-3 OR MNT-ROUTE-4)))
- the resulting mntner list: ( MNT-AUT-NUM-MNT-ROUTES AND MNT-ROUTE AND ( ( MNT-INETNUM-1 AND MNT-ROUTE-1 AND ( MNT-ROUTE-2 AND ( MNT-ROUTE-3 OR MNT-ROUTE-4 ) ) ) ) )
participants (3)
-
Engin Gunduz -
Frank Bohnsack -
Joao Damas