RIPE Whois Server-style queries broken?

[job]

There seems to be some code in bgpq3 to deal with RIPE queries, but I have trouble following the logic and design behind it. In any regard bgpq3 currently does not handle RIPE queries correctly.

Vurt:bgpq3 job$ bgpq3 -d -h whois.ripe.net AS15562
DEBUG: bgpq_expander.c:378 bgpq_pipeline expander: sending '!gas15562
'
ERROR:Wrong reply: % Note: this output has been filtered.
 to !gas15562

no ip prefix-list NN
! generated prefix-list NN is empty
ip prefix-list NN deny 0.0.0.0/0

Vurt:bgpq3 job$ bgpq3 -6 -d -h whois.ripe.net AS15562
DEBUG: bgpq_expander.c:378 bgpq_pipeline expander: sending '-T route6 -i origin as15562
'
no ipv6 prefix-list NN
! generated prefix-list NN is empty
ipv6 prefix-list NN deny ::/0
Vurt:bgpq3 job$

[snar]

On Fri, Jun 26, 2015 at 03:02:37AM -0700, Job Snijders wrote:

There seems to be some code in bgpq3 to deal with RIPE queries, but I have trouble following the logic and design behind it. In any regard bgpq3 currently does not handle RIPE queries correctly.

It's not bgpq3 does not handle RIPE queries correctly, but it's RIPE does not understand IRRd queries at all...

bgpq3 is built around IRRd query protocol[1], which is not compatible with RIPE (albeit using some RIPE-style queries inside). This is why -h host option exactly stating that server MUST run IRRD, not plain whois server:

-h host : host running IRRD software (whois.radb.net by default)

[1]: see irrd-user.pdf at https://github.com/irrdnet/irrd appendix B for protocol description. Major difference with plain whois is that it much better suited for inter-program communications (no need to parse whois records), and killer feature is that with IRRD it takes one query to resolve AS-NTT into list of AS'es. With plain whois I have to query for AS-NTT then for each member of AS-NTT, then for each member of member and so on..

Vurt:bgpq3 job$ bgpq3 -d -h whois.ripe.net AS15562 DEBUG: bgpq_expander.c:378 bgpq_pipeline expander: sending '!gas15562 ' ERROR:Wrong reply: % Note: this output has been filtered. to !gas15562

no ip prefix-list NN ! generated prefix-list NN is empty ip prefix-list NN deny 0.0.0.0/0

Vurt:bgpq3 job$ bgpq3 -6 -d -h whois.ripe.net AS15562 DEBUG: bgpq_expander.c:378 bgpq_pipeline expander: sending '-T route6 -i origin as15562 ' no ipv6 prefix-list NN ! generated prefix-list NN is empty ipv6 prefix-list NN deny ::/0 Vurt:bgpq3 job$

— Reply to this email directly or view it on GitHub.*

[job]

Ahh, so the only purpose functions such as bgpq_expand_ripe() and bgpq_pipeline_dequeue_ripe() is to support RIPE-style queries as supported by RADB?

Why is -T route6 -i origin AS15562 used instead of !6as15562? Is an artifact from times where RADB supported RIPE-style queries (and thus offering access to route6 information) but did not have the !6 query flag?

[snar]

On Fri, Jun 26, 2015 at 05:16:33AM -0700, Job Snijders wrote:

Ahh, so the only purpose functions such as bgpq_expand_ripe() and bgpq_pipeline_dequeue_ripe() is to support RIPE-style queries as supported by RADB?

Exactly.

Why is -T route6 -i origin AS15562 used instead of !6a15562? Is an artifact from times where RADB supported RIPE-style queries (and thus offering access to route6 information) but did not have the !6 query flag?

These days radb had !6 in documenation but it was not actually working :( Looks like now it does, so someday I will rewrite all ipv6 logic toward this query.

[job]

Closing this one.