1.6 hangs generating IPv6 lists

[supine]

Nothing interesting in debug, seems to be parsing and then hangs:

bgpq4 -F "%n/%l\n" -6 -d AS-TPG RS-TPGTELECOMS
<SNIP>
DEBUG: sx_prefix.c:353 sx_prefix_range_parse parsed prefix-range 2001:4479:f00::/40^40-48 as 40-48 (maxlen: 128)
DEBUG: sx_prefix.c:353 sx_prefix_range_parse parsed prefix-range 2001:c60::/32^32-48 as 32-48 (maxlen: 128)
DEBUG: sx_prefix.c:353 sx_prefix_range_parse parsed prefix-range 2001:dc0::/32^32-48 as 32-48 (maxlen: 128)
DEBUG: sx_prefix.c:353 sx_prefix_range_parse parsed prefix-range 2001:dc::/35^35-48 as 35-48 (maxlen: 128)
DEBUG: sx_prefix.c:353 sx_prefix_range_parse parsed prefix-range 2001:df2:3c00::/45^45-48 as 45-48 (maxlen: 128)
DEBUG: sx_prefix.c:353 sx_prefix_range_parse parsed prefix-range 2001:df2:ee00::/47^47-48 as 47-48 (maxlen: 128)
DEBUG: sx_prefix.c:353 sx_prefix_range_parse parsed prefix-range 2001:df9::/32^32-48 as 32-48 (maxlen: 128)
DEBUG: sx_prefix.c:353 sx_prefix_range_parse parsed prefix-range 2002::/16^16-48 as 16-48 (maxlen: 128)

[job]

The problem is not per se in the program, or the protocol, but rather with 'garbage in garbage out'. It exposes a fundamental problem with route-set objects, there is no server-sided sanity checking of the contents. See below:

...
DEBUG: sx_prefix.c:353 sx_prefix_range_parse parsed prefix-range 2001:df2:3c00::/45^45-48 as 45-48 (maxlen: 128)
DEBUG: sx_prefix.c:353 sx_prefix_range_parse parsed prefix-range 2001:df2:ee00::/47^47-48 as 47-48 (maxlen: 128)
DEBUG: sx_prefix.c:353 sx_prefix_range_parse parsed prefix-range 2001:df9::/32^32-48 as 32-48 (maxlen: 128)
DEBUG: sx_prefix.c:353 sx_prefix_range_parse parsed prefix-range 2002::/16^16-48 as 16-48 (maxlen: 128)
bgpq4: Cannot allocate memory
$

The program tries to allocate memory to print all /48 prefixes contained within 2002::/16; most modern computers won't have sufficient memory complete this task...

I could try to add some arbitrary limits to the program to avoid expanding 2002::/16 into each individual subnet up to the /48 boundary, but I'm not entirely sure what good limits would be.

From the perspective of generating an IPv6 prefix list according to the RPSL specification, the RS-TPGTELECOMS simply expands to something too big :-(

[floatingstatic]

FWIW its actually a child object in that set which causes this: AS7545:RS-ROUTES:AS24130

@job I wonder if we could have something similar to -r here that lets us specify the minimum mask length we are willing to expand from. That would at least allow users of this tool to decide what they are willing to or can accept and filter out anything not matching the criteria.

[job]

@floatingstatic A feature like “will de-aggregate up to XX bits”, and perhaps a default value of 8?

I’ll look into that!

[lukastribus]

I was thinking about something else too, what about specifying what we all know as "max-prefix". This is a value that is often available anyway and could be used to restrict memory allocation.

If exceeded, bgpq4 could return a partial or empty result, with a non-zero exit code.

I'm assuming RPSL "garbage in garbage out" will continue to remain true for the foreseeable future, so setting expectations about the amount of prefixes to return could help, not only because of garbage input but also because destination limits.

And this situation, max-pref would probably also be configured on the BGP session, so this would not really cause surprises.

A big disparity between RPSL and actually expected prefixes on the other hand would trigger this.