The speaker explained that he defined "bogon" as a BGP advertisement of an address or AS number that was not registered as being allocated or assigned. The presenter noted that there were inconsistencies in IANA data which complicated decisions about whether advertisements were authorised or not. Terms such as "reserved", "reserved subject to allocation", and "reserved for future use" make it difficult to understand whether space can be used or not. Early registrations (part of the ERX project) are listed in the ARIN database, but are not included in the ARIN statistics files. Therefore, parsing whois data does not always result in a clean picture of allocated space.
The speaker explained that he defined space not included in statistics files or IANA allocation data as being bogon. He clarified that he was not referring to hijacked ranges as part of the bogon ranges, as hijacked space was a separate issue.

The speaker examined bogon announcements between May and July 2003 and noted that there had been a reduction in the number of bogons announced. The speaker suggested that any networks with resources listed as bogons should check their records to see if they have documented proof of their resources, or contact the RIRs.

The speaker listed address blocks from the current CIDR report that appear to be bogons. He suggested that attendees go to the CIDR report to check that none of their resources are included.

Questions and discussion

A network that has appeared on the list noted that often its customers will have a legitimate claim to the space. What occurs is that a customer with no legitimate claim to space will return the space to an RIR, which accepts the return, even though the network has no right to return it. This can cause problems if the legitimate network then continues to route the "returned" space.

The speaker explained that the IPv6 CIDR report has the same aims as the IPv4 report and tracks the aggregation behaviour of IPv6 blocks. The speaker noted that the IPv6 routing table currently has around 500 entries. The speaker explained that aggregation can be achieved via a few different methods and that the IPv6 CIDR report maintains statistics for possible aggregation using each of these methods. The speaker noted that there is currently very little fragmentation shown for IPv6 prefixes.

The speaker noted that because the statistics for the report were taken from within AS1221, it appeared that the prefixes announced by 1221 could be reduced from twenty-three to three; however, as this was an internal view, this did not reflect the fact that externally, only three routes were being announced.

The speaker stated that he was open to suggestions for further improvements and expansions to the IPv6 CIDR report data.

The speaker outlined benefits of using an IRR, such as contact information and router configuration. The speaker explained that the goal of the survey detailed in the presentation was to understand the divergence between IRRs and BGP prefixes, to identify the differences between IRRs, and to explore whether IRRs were a practical way to develop router configuration.

The speaker noted that the differences between IRRs included the fact that RADB contained many un-maintained objects, whereas the RIPE Routing Registry contained more maintained objects.

The speaker noted that the accuracy of the RIPE IRR is high and therefore it was a practical way to configure routers using the data.

The speaker explained that the background of the project was to deal with one of the major problems in interdomain routing: hijacking. One approach to counter this would be to authenticate prefixes in BGP updates. However, this would take a long time to deploy. Another approach would be to check the prefix by using an IRR database. The speaker suggested that IRRs need to inspect more than just the routing policy's syntax; IRRs also need to check the policy's semantics so that inconsistencies can be identified. For example, an import statement may include AS1, AS2, AS3, but the export statement may only include AS1 and AS3. A semantic check could catch such an error.

Future work in the project included the deployment of a policy checker on JPIRR and the implementation of a notification function to alert networks of inconsistent data in the JPIRR.

Questions and discussion

It was questioned whether the idea was to load the entire IRR on every router or to only include prefix/origin-as pairs. It was commented that neither approach seemed practical or would scale well. It was noted that the approach of SBGP seemed preferable as it injected trustworthy information and the transportation within the routing system is done in such a way that it cannot be corrupted. It was suggested that the presentation did not seem to address those security issues.

It was noted that the reason a lot of the IRR database information is invalid was because networks did not maintain it because it was not used by others. It was explained that this was a chicken and egg situation; there is a need to make it worth people's time to maintain data in IRRs and a need to find a strong motivation to use the data. Currently, the only possible reason to have valid data is to justify a request for resources to an RIR. Other than that, it was noted that a network often lets the data stagnate until time for the next request.

This presentation examined at the ideal view most people have of BGP and contrasted it with the reality. The speaker explained the research project where BGP beacons were used to announce and withdraw prefixes on a fixed schedule. This known data was then compared to BGP tables at different distances from the beacon network. Within twenty-six seconds, there were thirty-nine announcements and two withdrawals noted at the one collection point. The speaker noted that part of this was due to different implementations such as MinRouteAdvertTimers by router vendors. The speaker explained that it had been shown in lab situations that there can be reasonable configurations that would never settle. The speaker emphasised the difference between the ideal BGP concept and observed reality.

Questions and discussion

It was noted that that the MinRouteAdvertTimer implements different times for each router interface. This was a trade off. If timing is fast, the network converges more quickly but with a lot of noise. As the delay is increased, the convergence time becomes longer, but there are far fewer announcements. However, if the time is increased further, the convergence gets slower, but the announcements do not decrease either.

It was commented that in RIP hold-down timer model, the hold-down timer was expressed for all neighbours, and when it expired, it would be released at the same time on all interfaces. However, it was countered that nothing really happens at the same time, however close those times appear to be.

It was noted that routing complexity has more to do with mapping policy over topology and scaling factors and less to do with the actual amount of prefix load carried.