route aggregation and RFC2725
Dear colleagues, we have three side by side "assigned PI" inetnum blocks 193.17.60.0/24, 193.17.61.0/24 and 193.17.62.0/23. To reduce routing table space we want to create only one aggegated route for these blocks instead of three seperated. But the authentication process of RFC2725 does checks exact or less specific routes or inetnums only and will go wrong in this case. My question: Is this a known/proposed "feature" or should we think about a modification of the authentication process of RFC2725 to support this case? Thanks Frank fb@OC3 20> whoisRIP -r -M 193.17.60.0/22 % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 193.17.62.0 - 193.17.63.255 netname: HOFMANN-LAN descr: Enno Hofmann descr: D-58089 Hagen country: DE admin-c: EHO-RIPE tech-c: EHO-RIPE tech-c: EHO-RIPE rev-srv: auth04.ns.de.uu.net rev-srv: auth54.ns.de.uu.net status: ASSIGNED PI notify: eho@de.uu.net mnt-by: UUNETDE-I mnt-by: HOFMANN-MNT mnt-lower: HOFMANN-MNT changed: cp@deins.Informatik.Uni-Dortmund.DE 19921216 changed: eho@de.uu.net 19991008 changed: eho@de.uu.net 20020621 source: RIPE inetnum: 193.17.61.0 - 193.17.61.255 netname: GSD-HH descr: GSD Berlin descr: - Geschaeftsstelle Hamburg - descr: D-W-2000 Hamburg 53 country: DE admin-c: JA1966-RIPE tech-c: RG2666-RIPE tech-c: MF3386-RIPE mnt-by: UUNETDE-I status: ASSIGNED PI changed: cp@deins.Informatik.Uni-Dortmund.DE 19921015 changed: hostmaster@de.uu.net 20020205 changed: eho@de.uu.net 20020807 source: RIPE inetnum: 193.17.60.0 - 193.17.60.255 netname: GSD-BLN descr: GSD descr: D-10785 Berlin country: DE admin-c: JL15-RIPE tech-c: TM2554-RIPE status: ASSIGNED PI mnt-by: UUNETDE-I changed: cp@deins.Informatik.Uni-Dortmund.DE 19921015 changed: eho@de.uu.net 20020807 source: RIPE route: 193.17.62.0/23 descr: HOFMANN-LAN origin: AS702 member-of: RS-UUNETEUDE mnt-by: UUNET-MNT changed: eho@de.uu.net 20020611 source: RIPE fb@OC3 21> whoisRIP -r -l 193.17.60.0/22 % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 193.16.0.0 - 193.31.255.255 netname: EU-ZZ-930921 descr: block for PI assignments maintained by RIPE NCC former address space of de.zz country: EU admin-c: CREW-RIPE tech-c: CREW-RIPE status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT changed: marten@ripe.net 19930921 changed: hostmaster@ripe.net 20020621 source: RIPE
Dear Frank, On 2003-02-18 16:20:58 +0100, Frank Bohnsack wrote:
Dear colleagues,
we have three side by side "assigned PI" inetnum blocks 193.17.60.0/24, 193.17.61.0/24 and 193.17.62.0/23. To reduce routing table space we want to create only one aggegated route for these blocks instead of three seperated. But the authentication process of RFC2725 does checks exact or less specific routes or inetnums only and will go wrong in this case.
My question: Is this a known/proposed "feature" or should we think about a modification
I do not think this was done deliberately. My guess is that this simply escaped the attention of the authors and reviwers of the RFC. This makes sense as this situation occurs quite rarely. In any case, this is a known problem with RFC2725 and perhaps needs to be addressed. Best regards, -engin
of the authentication process of RFC2725 to support this case?
Thanks Frank
[...] -- Engin Gunduz RIPE NCC Database Group
participants (2)
-
Engin Gunduz
-
Frank Bohnsack