[db-wg] bug? accepting larger than 32 bit BGP Communities in RPSL

Intersting observation, thanks for bringing it up!

Q to the DB Team: is the software doing any checks against numeric values
as numbers or is the data treated/stored exclusively as text?

As a sort of more general sideline,
there may be other limits or boundary conditions, and I am wondering where
the proper place is to "enforce" those. I know about the 'be rigorous about
what you transmit and liberal (and careful) in what you accept'.
But I wonder whether that would not apply to tools just equally?

Wilfried

Job Snijders wrote:

> Dear RIPE DB group,
> 
> A small snippet from the current AS15562 object as stored in the RIPE DB. 
> 
> remarks: Larger than 32bit BGP Community test
> remarks: 64 bit
> export:  to AS199036 action community .= { 0000199036:0000199036 }; announce AS-SNIJDERS
> 
> The value "0000199036:0000199036" is a 64 bit integer:
> 	
> 	(199036<<32)+199036 = 854853110925692
> 
> 854853110925692 Is far larger than what RFC 2622 [1] allows in section 7.1:
> 
> typedef:      # a community value in RPSL is either
>               #  - a 4 byte integer (ok to use 3561:70 notation)
>               #  - internet, no_export, no_advertise (see RFC-1997 )
>               community_elm union
>               integer[1, 4294967295],
>               enum[internet, no_export, no_advertise], 
> 
> So my main question is, why is the RIPE DB allowing such values to be stored?
> 
> This is not conforming to any specification that I am aware of. Currently there
> is no consensus on what the future of BGP communities will look like within the
> IETF.
> 
> Kind regards,
> 
> Job 
> 
> [1] http://tools.ietf.org/html/rfc2622