This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
[db-wg] route aggregation and RFC2725
- Previous message (by thread): [db-wg] route aggregation and RFC2725
- Next message (by thread): [db-wg] RIPE NCC network affected by the DDoS attack
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Engin Gunduz
engin at ripe.net
Tue Feb 18 16:54:25 CET 2003
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
- Previous message (by thread): [db-wg] route aggregation and RFC2725
- Next message (by thread): [db-wg] RIPE NCC network affected by the DDoS attack
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]