De-Bogonising New Address Blocks

Daniel Karrenberg
RIPE NCC

Document ID: ripe-351
Date: October 2005

Abstract

This document describes an improvement to the notification process for new blocks of address space being distributed by the Regional Internet Registries (RIRs). It is a draft at this stage and your comments are solicited. However to gain experience before finalising the procedures, the RIPE NCC will shortly start announcing the routes from 84/8 described in the document under "The 84/8 Pilot" section.

Contents

1.0 Problem Statement
2.0 Proposed Action
3.0 Formal Issues
4.0 84/8 Pilot
5.0 Short-Term Open Issues
6.0 Long-Term Open Issues

1.0 Problem Statement

Filtering of unallocated address space (a.k.a. bogon filtering) is becoming more prolific. This is a good thing. However when those filters are not kept up-to-date they can quickly become too much of a good thing. Recently users of first allocations out of new blocks have experienced problems and aired them on lists like NANOG and in the press. Also, prominent resources like some root name servers were not reachable from a recently assigned address block because of out-of-date bogon packet filters.

The Regional Internet Registries (RIRs) just distribute the address space and can make no claims whatsoever about route-ability because this is clearly in the domain of ISPs and other network operators. RIRs notify the community and thus the ISPs whenever they start allocating from a new block including information about minimum allocation sizes.

While all this is formally clear, a number of problems are increasing:

• ISPs and their customers get frustrated about reachability problems.
• RIRs get some of the blame and in the long run there will be reluctance to accept addresses from new blocks and pressure to announce usage of blocks much earlier before actual allocations.
  

2.0 Proposed Action

RIRs should improve their notification to the community. To do this we propose to actively announce some "pilot" prefixes from new blocks before making allocations from those blocks. The "reach" of these announcements can then be determined by analysing routing data observed on the Internet: the distribution of routes to the pilot prefixes can be compared with the distribution of regular production prefixes; significant differences can be analysed to determine ISPs that are still filtering routing announcements from the new block. The RIRs can then try to notify these ISPs specifically.

Also the reachability of some prominent resources, like root name servers from the pilot prefixes, can be tested and operators of these resources can be notified if problems are detected.

Announcement of pilot prefixes will be stopped as soon as real production prefixes get announced from the new block. Routing data about these production prefixes can then be used to pinpoint any remaining issues. The address space of the pilot prefixes can later be allocated for production as usual.

This has met with general approval from the RIPE NCC services WG at the RIPE 47 meeting (See agenda point I).

We also solicit feedback from ISPs and other network operators on the period of advance notification they need before new (/8) blocks of address space are being used in production.

3.0 Formal Issues

RIRs have to be careful that this is not regarded as a "guarantee of route-ability". It is rather a continuation of the ISP notification programme using different means. In other words: RIRs now try to individually notify ISPs who have not reacted to the general notification. The decision whether to accept or relay routing information about specific prefixes or whether to block specific traffic remains fully with the network operators.

4.0 84/8 Pilot

The RIPE NCC has assets in place to start this very quickly for 84/8 which is already declared as being legitimately allocated, non-bogon address space.

We already operate routing beacons. One of these can easily be modified to announce parts of a new address block as soon as it is received from IANA. This requires notification and consent of beacon peers. We will use the AMS-IX location because co-ordination with our beacon peers can be achieved most quickly and easily.

http://www.ripe.net/ris/docs/beacon.html

The Routing Information Service (RIS) has excellent coverage of routing information and can be used to collect routing info for analysis. Reachability of prominent services can be tested from the beacon hosts themselves. This information can be used to notify the ISPs and/or service operators in question.

http://www.ripe.net/ris/index.html

We will announce 84.192/16 and 84.255.248/21 as pilot prefixes and add them into the routing registry as being announced by our beacon AS12654.

5.0 Short-Term Open Issues

• We would like to involve others, such as Team CYMRU, in the effort. How?
• What added benefits do other groups have to offer?
• How can we ensure a wide publication of the effort?
  

6.0 Long-Term Open Issues

This may require longer lead time in requesting address blocks from IANA. How long do we have these days before we make the first allocation?