April 1993 - lir-wg - mailman.ripe.net

RIPE DRAFT
by Anne Lord 23 Apr '93

23 Apr '93

Dear All, Below is a first draft of the "Hints" supporting documentation. The production of this document is a minuted action item from the last RIPE meeting. The content of the document and the questions below will be discussed at the RIPE meeting next week. Please bring your comments to the meeting. 1. Class D procedure - is the assignment of these within the scope of this procedure? 2. The issue of non-contigous subnets (eg multihomed orgs using a subnetted Class B) and the potential difficulties thereof? do we wish to give advice on this 2. Is there a need for a short Appendix describing how to find a NOC of Last resort (cf App 2 on service providers)? ----------------------cut here---------------------- DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT HINTS FOR ORGANISATIONS REQUESTING IP NETWORK NUMBERS Bob Day, Anne Lord ripe-draft This document is intended to complement and support the information described in the "European IP network number application form and template" (see RIPE document ID: ripe- 83). The aim of the document is to guide you in your choice of class of IP network number so that you choose that which is best suited to your organisations needs. The document is motivated by the large number of applications that are received for Class B address that are not in fact allocated. This accounts for approximately 90% of all class B applications. It is a time consuming and often lengthy process explaining to organisations why their application has been rejected, or why it is taking longer to process, which we hope can be lessened with the publication of this document. - 2 - Contents 1 Background ................................................ 2 IP network number scarcity ................................ 3 IP addressing ............................................. 3.1 Subnetting ................................................ 4 Choosing the Class of Network Number ...................... 4.1 Using a Single Class C Network Number ..................... 4.2 Using a Block of Class C Network Numbers .................. 4.3 Applying for a Class B Network Number ..................... Appendix 1: Supernetting ........................................ Appendix 2: What to do if you need a Service Provider ........... - 3 - Copyright c 1993 Whilst every effort has been taken to ensure accuracy, the RIPE NCC does not accept any responsibility for loss or damage arising from the use of information found within this document. Material from this document may be incorporated in other technical documentation, subject to prior agreement from, and acknowledgement of, the RIPE NCC. 1 Background The arrangements for the allocation of Internet (IP) network numbers have recently been revised. Previously these numbers were assigned only by the Network Information Centre (NIC) of the Defense Data Net- work (DDN) in the US. This was done by consensus on behalf of the whole Internet community. Following the change of arrangements, the DDN NIC still has overall responsibility for the allocation of network numbers but it has delegated the actual assignment process on a regional basis. In Europe the delegated authority is the Network Coordination Centre (NCC) run by RIPE under the auspices of RARE. The NCC has further delegated a number of IP ``service providers'' to assign numbers for networks connecting to their respective service networks. The <local example> is one of these service providers (it provides the <local cc: IP Service) and consequently now handles the assignment of "C" network numbers to networks connecting to the <network>. 2 IP network number global scarcity The Internet authorities are increasingly concerned about the possi- bility of exhaustion of the IP address space as a result of the recent explosive growth of the Internet. They have decided upon certain measures to attempt to conserve address space, and other solutions are currently under debate in the community. This is now a matter of some concern. Further detail on the measures decided upon so far is given in Appendix 1 of this document. One of the measures currently practised by the Internet community is to carefully review each and every application for network numbers with respect to its merit on technical grounds. Strict criteria are applied to all organisations, regardless of type, to ensure that the remaining address space is distributed as effectively as possible. - 4 - 3 IP Addressing The IP address of an end system attached to an IP network is composed of two elements: - the network number identifying to which network the end system is attached (uniquely amongst all the IP networks that constitute the Internet); - the host number identifying the end system on that network. The entire address is a 32 bit quantity. The usual means of represent- ing an address is to write it as a series of four decimal numbers, each representing 8 bits of the entire address, and separated by periods. Thus, for example, the address: 192.100.100.27 would represent the end system numbered ``27'' on the IP network with number ``192.100.100''. It is the requirement for global uniqueness of the network number that leads to the need for co-ordination in the assignment of these numbers. IP network numbers are divided into a number of ``classes'', each of which allows a different maximum number of end systems to be attached to the network it represents (ie gives a different maximum number of possible host addresses). Of these there are two classes that will be relevant to an organisation applying for a network number through the <local sp/nic>. A ``Class C'' network number will allow the attachment of up to 256 end systems, a ``Class B'' network will allow up to 65,636 end systems. (In each case two of the end system numbers are reserved for conventional uses, meaning that the number of host numbers available in practice is 254 or 65,634 respectively.) These figures come about because a Class C network number always occupies the first 24 bits of the full IP address, leaving 8 bits for the host number. This gives the possibility of 256 different host numbers, of which one is reserved as a conventional ``broadcast'' address. A Class B network number only occupies the first 16 bits of the full IP address, leaving 16 bits for the host number. An IP implementation can determine the class of a network number by examining the first two bits. If only the first of these is set - ie the top byte is in the range 128 - 191 - it is a Class B number. If both bits are set (and the next bit is unset) - ie the top byte is in the range 192 - 223 - it is a Class C number. - 5 - Recently there has been growing interest in the use of Class D numbers as well. These are used to create IP multicast addresses - ie if a system transmits a datagram to an address within a Class D network it will be delivered simulataneously to a group of hosts, rather than to a single host. IP multicasting has applications in the area of coperative working and conferencing, as well as (potentially) in the support of routing protocols. A Class D network number has the top three bits set - ie the top byte has the value 224 or greater. 3.1 Subnetting Associated with each IP address is an ``address mask''. This is a 32 bit quantity that marks, in a bitwise fashion, which bits of the address are to be treated as the network number component and which are to be treated as the host number component. Where a bit is set in the address mask, the corresponding bit of the address is considered to be part of the network number field. Where the bit is unset in the address mask, the corresponding bit is considered to be part of the host number field. For a Class C address the default address mask is 255.255.255.0 (ie the top 24 bits contain the network number). For a Class B address the default address mask is 255.255.0.0. By use of a non-default address mask, it is possible for the administrator of a Class B network number to break it down into a number of Class C ``subnets''. These could then, for example, be assigned one per department in a University, and routers could be used to connect these together. This would allow a site network to be broken down into a set of autonomous networks, whilst the network as a whole appears to the outside world to have a single (Class B) number. As an illustration, assume that an institution has the Class B number 128.100 assigned to it. The administrator could create 256 Class C subnets by specifying a non-default address mask of 255.255.255.0. This would allocate the top 8 bits of the host number field to be an extension of the network number field. Hence the set of Class C numbers 128.100.0 - 128.100.255 would become available. Of these, the first and last in the range should not be used, as they have conventional meanings. This would leave up to 254 Class C numbers for use. In principle subnetting need not be done on an 8-bit boundary eg an address mask of 255.255.240.0 could be used to produce 16 subnets (14 of them useable), each with a 12- bit host field. In practice, however, subnetting is usually confined to an 8-bit boundary. - 6 - Subnetting is thus a technique of moving the boundary between the host and network number parts of an address. For it to be useful, the IP implementations of all end systems on the network involved must support it. All must also use the same, centrally defined address mask. 4 Choosing the Class of Network Number An organisation that requires more address space than would be provided by a single Class C network number will by default receive a group of Class C numbers instead. This implies that it will need to structure its site network into separate, interconnected Class C networks. The rest of this section goes into detail as to how the decision as to which class of address to apply for should be approached. The aspects to be considered when making this decision are as follows: - the current requirement in terms of the the number of end systems to be connected; - the likely expansion over the next one or two years; - the feasibility or otherwise of routing between networks on site, if multiple Class C networks are to be used. 4.1 Using a Single Class C Network Number If the requirement in terms of end systems to be connected are modest - perhaps a few tens of systems to be connected (max 255 hosts) - a single Class C network number will be sufficient. This is the simplest and most trouble-free, situation. 4.2 Using a Block of Class C Network Numbers If it is likely that there will be a few hundred end systems connected over the next year or two the default choice will be to ask for an assignment of a block of Class C network numbers. These will need to be organised internally as a set of interconnected networks, using an IP router (or routers) as the means of interconnection. A common organisation is for the site's network operator to assign one Class C network per department, and to connect these together via a site ``backbone''. For example, assume that the site has been allocated four Class C network numbers: 192.100.100 - 192.100.103. These could be assigned to three different departments and a backbone, and a sin- gle router used to interconnect them, as shown in Figure 1. - 7 - 192.100.100 (backbone) ===o==============o===============o============o=== | | | | +---+ +---+ +---+ +---+ Connection | r | | r | | r | | r | --> to service +---+ +---+ +---+ +---+ provider or | | | other ===o======== ===o========= ===o======== 192.100.101 192.100.102 192.100.103 (Dept A) (Dept B) (Dept C) Figure 1: Interconnection of Class C Networks via a Backbone Network Alternatively, the four networks might be connected via a single router, as shown in Figure 2. The choice of interconnection method will be dictated by the conditions on site, but in all cases some form of IP routing equipment will be needed. 192.100.100 (Dept A) +---+ ============================| | | | 192.100.101 (Dept B) | r | ============================| o | | u | Connection 192.100.102 (Dept C) | t |--> to service ============================| e | provider or | r | other 192.100.103 (Dept D) | | ============================| | +---+ Figure 2: Interconnection of Class C Networks via Single Router A consequence of the recent rapid growth of the Internet is that the number of network numbers that have to be configured into regional and international routers has also grown rapidly. This means that these routers' routing tables have also grown to the point where there is concern as to whether they will continue to operate efficiently. To combat this problem the concept of ``supernetting'' is being intro- duced. This is outlined in Appendix 1 (although it is not necessary to understand the concept to apply for a network number). A practical consequence of this move is that a request for multiple Class C net- work numbers will always result in a contiguous block of numbers - 8 - being assigned, and that the size of the block will always be a power of two (ie 2, 4, 8, 16 or 32 network numbers etc). 4.3 Applying for a Class B Network Number There may be some circumstances where the use of a single Class B network number, rather than a block of Class C numbers is justified. This may be because the number of end systems to be connected is so large that it becomes cumbersome to use a block of Class C numbers. The guideline given by the Internet NIC (in RFC 1366) is that a site network should utilise a Class B number if, based on a 24 month projection, it requires: - more than 32 network numbers (or subnets), AND - it has more than 4096 end systems to connect. The Class B network number could then be subnetted if necessary, according to the site requirements. Site networks that anticipate requiring less than this amount of address space should, under normal circumstances, apply for a block of Class C network numbers. Another potential reason for the use of a Class B network number is that it may be infeasible for the institution to do the IP routing required on its site network if a block of Class C numbers is used. As shown in Figures 1 and 2 above, this will require the installation of routing equipment - either purpose-built routers or end systems equipped with multiple LAN interfaces and IP routing software. This might be impractical in some cases, on the grounds of existing investment in equipment. It might also be impractical in a situation where the site network is multi-protocol and the routers cannot handle all the protocols involved. MAC level bridging might then be required, along with a single network number across the entire network. In making the decision as to whether a Class B number is necessary, note that many purpose-built routers can bridge as well as route (so-called ``brouters''), so it may be possible to route IP whilst bridging other protocols. Note also that the ``supernetting'' development described in Appendix 1 means in theory that the use of IP routers on site can be avoided in the case where a suitable block of Class C network numbers has been assigned. To help the NICs involved determine whether there is a sufficient case for a Class B network number, the organisation is asked on the ``European IP network number - 9 - application form'' to supply information relating to the number of hosts and the number of subnets, in use now and predicted for one and for two years' time. Besides there being a sufficient number of hosts to address, the NICs must determine that the network cannot be engineered using a number of contiguous class C networks. If the network consists of a large number of physical networks with relatively small numbers of hosts on each, it will be necessary to consider subnetting class C networks. A large number of subnetworks alone is not sufficient justification for allocation of a class B address. The guideline in RFC 1366 will be applied rigorously. The procedure for deciding whether a Class B number can be allocated is first that the <nic/sp> will assess the case and, if it agrees, will recommend to the RIPE NCC that a Class B network number is allocated to the organisation concerned. The RIPE NCC will also review the case briefly and make a decision in consultation with the <nic/sp> and the organisation concerned. Because of this two stage consultation process the application will most likely take longer than normal to be dealt with. - 10 - Appendix 1 Supernetting One of the perceived problems arising from the rapid growth of the Internet is the consequent growth in the size of the routing tables held in the various regional and international routers. The increased pressure to use multiple Class C network numbers, rather than a single Class B number, in order to economise on the use of the latter class will add to the size of these routing tables. As a way of mitigating this problem it has been decided to use a route aggregation scheme colloquially known as ``supernetting''. (It is also known as CIDR - Classless Inter Domain Routing, and is described in detail in RFC 1338.) The key to the scheme is that where a block of Class C network numbers is assigned to an organisation's network it is done so as a contiguous block of a size that is a power of two. This means that for routing purposes it will then be possible to treat the entire block as a sin- gle network, albeit with a special address mask. (The address mask associated with an IP address is a 32 bit quantity that marks, in a bitwise fashion, which bits of the address are to be treated as the network number component and which are to be treated as the host number component. For a Class C address the default address mask is 255.255.255.0 - ie the top 24 bits contain the network number. For a Class B address the default address mask is 255.255.0.0.) To illustrate this, take as an example the block of four Class C net- work numbers 192.100.100 - 192.100.103. This can be treated as a sin- gle network number 192.100.100 by using an address mask that specifies the network number component to be only 22 bits rather than 24 bits. This is shown in Figure 3. <--------network-------><---host--> +--------+--------+--------+--------+ | 192 | 100 | 100 | | +--------+--------+--------+--------+ address 11111111.11111111.11111100.00000000 mask (ie. 255.255.252.0) Figure 3: Illustration of a Supernetting Address Mask - 11 - Because the block of network numbers is of size four, and has been assigned to start with a value divisible by four, it is certain that the bottom two bits of the normal 24 bits used for a Class C network number will be zero. Therefore the address mask can be set to make it appear that these two bits are part of the host number component of the address, and consequently that the networks numbered 192.100.101 - 192.100.103 are subnets of the network numbered 192.100.100. Because the block of network numbers is of size four, and has been assigned to start with a value divisible by four, it is certain that the bottom two bits of the normal 24 bits used for a Class C network number will be zero. Therefore the address mask can be set to make it appear that these two bits are part of the host number component of the address, and consequently that the networks numbered 192.100.101 - 192.100.103 are subnets of the network numbered 192.100.100. The technique is called ``supernetting'' because it employs a similar principle to the established technique of ``subnetting''. In the latter case bits from the host number component of an address are made part of the network number component, in effect creating a range of subnets from a single network number. It will work in theory for any size block of network numbers, provided the block is contiguous and the ``power of two'' criterion is satisfied. Supernetting can work in practice only if the IP implementations of all equipment handling it have been modified to understand it. Other- wise the special address mask involved will appear invalid, and the implementation will treat each network number in the block as representing an individual network. Hence if all the routers in a regional network to which the organisation is attached do implement supernetting they will treat the entire block as representing a single network. Consequently, in this example, there would be only one entry in the regional routers' tables rather than four, but IP traffic for any network contained in this block would still be routed correctly to the organisation concerned. Depending on implementation of supernetting by the major router ven- dors, it is expected that regional and international routers will adopt this scheme in near future. Follow the recommendations of the provider involved. If all end systems on the network of a connecting organisation, and the router used to connect to the outside world implement supernet- ting it will be possible to construct the network using a block of Class C numbers and without the need for router(s) internal to the - 12 - network. However, it seems very unlikely that this will be the case in the immediate future, and it is best to assume that traditional routing techniques will be required within the site. - 13 - Appendix 2 What to do if you need a Service Provider If your organisation is planning to connect to the Internet in the near future, then it is recommended that you do this via an IP Service Provider. If you are unsure who your service provider would naturally be, then you can fax or telephone the RIPE NCC who will send details of your connectivity requirements to a mailing list maintained for this purpose. Please supply your contact information which individual IP providers who have subscribed to the list can use to contact you. If you are sending a fax, please mark it: For the attention of : ip-provs(a)ripe.net We will then transcribe your details to our electronic mailing list. Note that this is the extent of the NCC involvement - it is a matter for individual service providers to decide whether to follow up such a request. RIPE Network Coordination Centre tel: +31 20 592 5065 Kruislaan 409 fax: +31 20 592 5090 1098 SJ Amsterdam email: hostmaster(a)ripe.net

2 1

193.in-addr.arpa procedures v1.4
by Marten Terpstra 19 Apr '93

19 Apr '93

Here's version 1.4 of the 193.in-addr.arpa delegation procedures. I have included Piet's recommended timer values, and the comment on reachability of servers for zones for individual nets. Please note that the second part of these procdures (single net delegations done by the NCC) is NOT yet in operation. Single net delegations in 193.x.y still have to be requested from hostmaster(a)ripe.net. After next weeks RIPE meeting we hope to implement the automatic procedure as soon as possible. The code is there, the operational environment isn't yet ;-) -Marten Guidelines for the delegation of zones in the 193.in-addr.arpa domain Marten Terpstra April 1993 V1.4 Introduction This document describes the procedures for the delegation of authority of zones in the 193.in-addr.arpa domain. As of March 16th 1993 the RIPE NCC has been delegated the authority for the 193.in-addr.arpa domain from the root. Due to the fact that in the 193.x.y address space blocks of 256 class C network numbers are further delegated to local registries , the possibility exists to also delegate the zone for these blocks in the 193.in-addr.arpa domain. This document describes some guidelines and procedures for this type of delegation and the delegation of reverse zones for individual class C networks in 193.x.y. A bit more explained With the assignment of class C network numbers following the CIDR (RFC 1338) model, in which large chunks of the address space are delegated to one region, and within that region blocks of class C network numbers are delegated to service providers and non-provider registries, some hierarchy in the address space is created, similar to the hierarchy in the domain name space. Due to this hierarchy the reverse Domain Name System mapping can also be delegated in a similar model as used for the normal Domain Name System. For instance, the RIPE NCC has been assigned the complete class C address space starting with 193. It is therefore possible to delegate the 193.in-addr.arpa domain completely to the RIPE NCC, instead of each and every reverse mapping in the 193.in-addr.arpa domain to be registered with the INTERNIC. This implies that all 193.in-addr.arpa resistrations will be done by the RIPE NCC. Even better, since service providers receive complete class C network blocks from the RIPE NCC, the RIPE NCC can delegate the reverse registrations for such complete blocks to these local registries. This implies that customers of these service providers no longer have to register their reverse domain mapping with the root, but the service provider have authority over that part of the reverse mapping. This decreases the workload on the INTERNIC and the RIPE NCC, and at the same time increase the service a provider can offer its customers by improve response times for reverse mapping changes . However there are some things that need to be examined a bit more closely to avoid confusion and inconsistencies. These issues are covered in the next section. Procedures for the delegation of direct subdomains of 193.in-addr.arpa 1. A secondary nameserver at ns.ripe.net is mandatory for all blocks of class C network numbers delegated in the 193.in-addr.arpa domain. 2. Because of the increasing importance of correct reverse address mapping, for all delegated blocks a good set of secondaries must be defined. There should be at least 2 nameservers for all blocks delegated, excluding the RIPE NCC secondary. 3. The delegation of a class C block in the 193.in-addr.arpa domain can be requested by sending in a domain object for the RIPE database to <hostmaster(a)ripe.net> with all necessary contact and nameserver information. The RIPE NCC will then forward all current reverse zones inside this block to the registry, and after addition of these by the registry, the NCC will check the working of the reverse server. Once everything is setup properly, the NCC will delegate the block, and submit the database object for inclusion in the database. An example domain object can be found at the end of this document. 4. All reverse servers for blocks must be reachable from the whole of the Internet. In short, all servers must meet similar connectivity requirements as top-level domain servers. 5. Running the reverse server for class C blocks does not imply that one controls that part of the reverse domain, it only implies that one administers that part of the reverse domain. 6. Before adding individual nets, the administrator of a reverse domain must check wether all servers to be added for these nets are indeed setup properly. 7. There are some serious implications when a customer of a service provider that uses address space out of the service provider class C blocks, moves to another service provider. The previous service provider cannot force its ex-customer to change network addresses, and will have to continue to provide the appropriate delegation records for reverse mapping of these addresses, even though it they are no longer belonging to a customer. 8. The registration of the reverse zones for individual class C networks will usually be done by the registry administering the class C block this network has been assigned from. The registry will make the necessary changes to the zone, and update the network objects in the RIPE database for these networks, to reflect the correct "rev-srv" fields. In case the RIPE NCC receives a request for the reverse zone of an individual class C network out of a block that has been delegated, the request will be forwarded to the zone contact for this reverse block. 9. The NCC advises the following timers and counters for direct subdomains of 193.in-addr.arpa: 8 hours refresh (28800 seconds), 2 hours retry (7200 seconds), 7 days expire (604800 seconds) and 1 day Time To Live (86400 seconds). The retry counter should be lowered where connectivity is unstable. Above procedures are defined to ensure the necessary high availability for the 193 reverse domains, and to minimize confusion. The NCC will ensure fast repsonse times for addition requests, and will in principle update the 193.in-addr.arpa domain at least once per working day. Example domain object to request a block delegation domain: 202.193.in-addr.arpa descr: Pan European Organisations class C block admin-c: Daniel Karrenberg tech-c: Marten Terpstra zone-c: Marten Terpstra nserver: ns.eu.net nserver: sunic.sunet.se nserver: ns.ripe.net changed: marten(a)ripe.net 930319 source: RIPE Procedures for the delegation of individual network zones by the RIPE NCC. The registration of the reverse zones for individual class C networks will usually be done by the registry administering the class C block this network has been assigned from. In case the zone corresponding to the class C block has not been delegated, the RIPE NCC will automatically add the reverse nameserver as specified in the "rev-srv" attribute of the RIPE database object for this network, using the following procedures: 1. Because of the increasing importance of correct reverse address mapping, for all delegated networks a good set of secondaries must be defined. There should be at least two nameservers for all networks delegated. 2. The "rev-srv" field should ONLY contain one fully qualified domain name of a nameserver which is authoritative for the reverse zone for this network. 3. If a network has or is going to have any external connectivity, it is strongly recommended that it has at least one reverse nameserver that can be reached from all of the Internet. 4. The checking and addition of the reverse zones for single networks is completely automated at the RIPE NCC. Although we do our best to check the setup of the nameservers, these does not receive the same level of scrutiny as nameservers for blocks of class C network numbers. It is the responsibility of the network contacts to ensure proper operation. 5. Any problems regarding the reverse zones in 193.in-addr.arpa should be directed to <hostmaster(a)ripe.net>. The NCC also suggests that similar procedures are set up for the delegation of reverse zones for individual class C networks from the registries to individual organisations.

1 0

Re: RFC1400 on Transition of Registration Services
by Dave Morton 14 Apr '93

14 Apr '93

> >Folks, > >What we need to do is to write a memo on the entire delegation >function, including the IANA, IR, DDN NIC, RIPE NCC, InterNICs, >the APNIC, etc...PLUS any other delegations we need to include. > >Joyce > Joyce, sounds good - and perhaps one might also have some guidelines for TLDs - if people see what I'm getting at. There was so very useful input from the community to the recent problem here which may now be resolving itself - however slowly. Dave

1 0

An update on the ripe-81 work
by Tony Bates 14 Apr '93

14 Apr '93

Just a quick note to say that I made some slight cosmetic modifications to the ripe-81 document, "Representation of IP Routing Policies in the RIPE Database" and to ripe-82 document "INTERNET ROUTING IN A MULTI PROVIDER, MULTI PATH OPEN ENVIRONMENT". Neither of these chages warrented a new number and were purely typographical errors. These documents can be retreived from the ripe document store ftp.ripe.net in the directory ripe/docs/ripe-docs as:- ripe-81.[txt,ps] ripe-82.[txt,ps] Also, a short note on the progress of ripe-81 database entries. Currently, we have received qite a few routing policies for the databse and more and still need to fully test our tools. I encourage everyone to send in there aut-num templates. The "guardian" update procedure should be ready to go fairly soon now. I also draw your attention again to the directory "as" in the ripe document store which is keeping a daily track of the registration of networks with an AS nymbers against what is seen in the routing database. Here is the latest sample of the conficts directory. I plan to start mailing out weekly reports of this information plus a general status of the database information growth. --Tony Conflicts between database and routing tables. --------------------------------------------- 129.132.0.0 in AS559 (database) and anounced by AS1836 (BGP) 132.146.0.0 in AS1752 (database) and anounced by AS1290 (BGP) 132.165.0.0 in AS590 (database) and anounced by AS777 (BGP) 132.166.0.0 in AS590 (database) and anounced by AS777 (BGP) 132.167.0.0 in AS590 (database) and anounced by AS777 (BGP) 132.168.0.0 in AS590 (database) and anounced by AS777 (BGP) 134.214.0.0 in AS590 (database) and anounced by AS789 (BGP) 138.70.0.0 in AS137 (database) and anounced by AS1717 (BGP) 138.132.0.0 in AS1267 (database) and anounced by AS1717 (BGP) 139.191.0.0 in AS1267 (database) and anounced by AS559 (BGP) 140.77.0.0 in AS590 (database) and anounced by AS789 (BGP) 141.137.0.0 in AS137 (database) and anounced by AS1717 (BGP) 143.169.0.0 in AS590 (database) and anounced by AS1717 (BGP) 143.205.0.0 in AS760 (database) and anounced by AS1111 (BGP) 143.224.0.0 in AS760 (database) and anounced by AS2036 (BGP) 146.110.0.0 in AS760 (database) and anounced by AS2012 (BGP) 147.196.0.0 in AS1899 (database) and anounced by AS1717 (BGP) 151.89.0.0 in AS1267 (database) and anounced by AS1717 (BGP) 151.90.0.0 in AS1267 (database) and anounced by AS1717 (BGP) 153.5.0.0 in AS2107 (database) and anounced by AS1104 (BGP) 156.18.0.0 in AS590 (database) and anounced by AS789 (BGP) 157.24.0.0 in AS1714 (database) and anounced by AS1741 (BGP) 157.159.0.0 in AS1899 (database) and anounced by AS1717 (BGP) 158.152.0.0 in AS1849 (database) and anounced by AS1290 (BGP) 159.84.0.0 in AS1717 (database) and anounced by AS789 (BGP) 160.103.0.0 in AS1717 (database) and anounced by AS789 (BGP) 161.3.0.0 in AS590 (database) and anounced by AS789 (BGP) 161.41.0.0 in AS1923 (database) and anounced by AS719 (BGP) 192.12.193.0 in AS137 (database) and anounced by AS513 (BGP) 192.35.150.0 in AS1274 (database) and anounced by AS1275 (BGP) 192.54.104.0 in AS174 (database) and anounced by AS517 (BGP) 192.54.197.0 in AS590 (database) and anounced by AS789 (BGP) 192.58.53.0 in AS1741 (database) and anounced by AS544 (BGP) 192.65.184.0 in AS513 (database) and anounced by AS1755 (BGP) 192.65.185.0 in AS513 (database) and anounced by AS1755 (BGP) 192.70.69.0 in AS789 (database) and anounced by AS513 (BGP) 192.70.89.0 in AS1899 (database) and anounced by AS1717 (BGP) 192.70.90.0 in AS1899 (database) and anounced by AS1717 (BGP) 192.70.110.0 in AS1899 (database) and anounced by AS1717 (BGP) 192.76.246.0 in AS1274 (database) and anounced by AS1755 (BGP) 192.82.157.0 in AS760 (database) and anounced by AS1112 (BGP) 192.84.220.0 in AS1324 (database) and anounced by AS517 (BGP) 192.93.155.0 in AS590 (database) and anounced by AS789 (BGP) 192.93.254.0 in AS1899 (database) and anounced by AS1717 (BGP) 192.94.163.0 in AS590 (database) and anounced by AS1717 (BGP) 192.106.1.0 in AS1267 (database) and anounced by AS1717 (BGP) 192.106.207.0 in AS1267 (database) and anounced by AS1717 (BGP) 192.106.210.0 in AS1267 (database) and anounced by AS1717 (BGP) 192.106.223.0 in AS1267 (database) and anounced by AS1717 (BGP) 192.106.235.0 in AS1267 (database) and anounced by AS1717 (BGP) 192.106.239.0 in AS1267 (database) and anounced by AS1717 (BGP) 192.106.240.0 in AS1267 (database) and anounced by AS1717 (BGP) 192.106.244.0 in AS1267 (database) and anounced by AS1717 (BGP) 192.106.249.0 in AS1267 (database) and anounced by AS1717 (BGP) 192.106.250.0 in AS1267 (database) and anounced by AS1717 (BGP) 192.107.233.0 in AS760 (database) and anounced by AS1901 (BGP) 192.108.114.0 in AS1241 (database) and anounced by AS2546 (BGP) 192.129.38.0 in AS1324 (database) and anounced by AS517 (BGP) 192.129.42.0 in AS1324 (database) and anounced by AS517 (BGP) 192.134.29.0 in AS590 (database) and anounced by AS789 (BGP) 192.134.91.0 in AS1899 (database) and anounced by AS1717 (BGP) 192.153.173.0 in AS1853 (database) and anounced by AS1755 (BGP) 193.0.5.0 in AS2122 (database) and anounced by AS2121 (BGP) 193.48.8.0 in AS590 (database) and anounced by AS777 (BGP) 193.48.137.0 in AS1717 (database) and anounced by AS789 (BGP) 193.48.140.0 in AS1717 (database) and anounced by AS789 (BGP) 193.48.145.0 in AS1717 (database) and anounced by AS789 (BGP) 193.52.136.0 in AS1=1800 (database) and anounced by AS1717 (BGP) 193.60.208.0 in AS786 (database) and anounced by AS1849 (BGP) 193.104.88.0 in AS1899 (database) and anounced by AS1717 (BGP) 193.128.2.0 in AS1849 (database) and anounced by AS1290 (BGP) 193.128.7.0 in AS1849 (database) and anounced by AS1290 (BGP) Nets flagged as LOCAL in the database and being routed. 141.22.0.0 is flagged LOCAL (database) and anounced by AS1275 (BGP) 145.41.0.0 is flagged LOCAL (database) and anounced by AS1103 (BGP) 163.156.0.0 is flagged LOCAL (database) and anounced by AS1849 (BGP) 164.15.0.0 is flagged LOCAL (database) and anounced by AS2111 (BGP) 192.12.54.0 is flagged LOCAL (database) and anounced by AS1103 (BGP) 192.16.183.0 is flagged LOCAL (database) and anounced by AS1104 (BGP) 192.16.183.0 is flagged LOCAL (database) and anounced by AS1890 (BGP) 192.26.121.0 is flagged LOCAL (database) and anounced by AS790 (BGP) 192.36.33.0 is flagged LOCAL (database) and anounced by AS1653 (BGP) 192.36.34.0 is flagged LOCAL (database) and anounced by AS1653 (BGP) 192.36.84.0 is flagged LOCAL (database) and anounced by AS1729 (BGP) 192.36.149.0 is flagged LOCAL (database) and anounced by AS1257 (BGP) 192.71.15.0 is flagged LOCAL (database) and anounced by AS1257 (BGP) 192.71.28.0 is flagged LOCAL (database) and anounced by AS1729 (BGP) 192.71.39.0 is flagged LOCAL (database) and anounced by AS1257 (BGP) 192.71.85.0 is flagged LOCAL (database) and anounced by AS1729 (BGP) 192.71.168.0 is flagged LOCAL (database) and anounced by AS1257 (BGP) 192.71.194.0 is flagged LOCAL (database) and anounced by AS1257 (BGP) 192.83.13.0 is flagged LOCAL (database) and anounced by AS544 (BGP) 192.108.72.0 is flagged LOCAL (database) and anounced by AS786 (BGP) 192.121.25.0 is flagged LOCAL (database) and anounced by AS1257 (BGP) 192.121.70.0 is flagged LOCAL (database) and anounced by AS1257 (BGP) 192.121.163.0 is flagged LOCAL (database) and anounced by AS1257 (BGP) 192.129.8.0 is flagged LOCAL (database) and anounced by AS786 (BGP) 192.165.173.0 is flagged LOCAL (database) and anounced by AS1257 (BGP) 192.165.191.0 is flagged LOCAL (database) and anounced by AS1257 (BGP) 192.173.66.0 is flagged LOCAL (database) and anounced by AS760 (BGP) 192.194.176.0 is flagged LOCAL (database) and anounced by AS1759 (BGP) 193.4.218.0 is flagged LOCAL (database) and anounced by AS1654 (BGP) 193.4.234.0 is flagged LOCAL (database) and anounced by AS1654 (BGP) 193.59.1.0 is flagged LOCAL (database) and anounced by AS1887 (BGP) 193.63.91.0 is flagged LOCAL (database) and anounced by AS786 (BGP) 193.78.1.0 is flagged LOCAL (database) and anounced by AS1890 (BGP) 193.84.4.0 is flagged LOCAL (database) and anounced by AS1902 (BGP) 193.87.96.0 is flagged LOCAL (database) and anounced by AS1922 (BGP) 193.87.97.0 is flagged LOCAL (database) and anounced by AS1922 (BGP) 193.87.98.0 is flagged LOCAL (database) and anounced by AS1922 (BGP) 193.87.99.0 is flagged LOCAL (database) and anounced by AS1922 (BGP) 193.96.9.0 is flagged LOCAL (database) and anounced by AS1270 (BGP) 193.96.10.0 is flagged LOCAL (database) and anounced by AS1270 (BGP) 193.96.11.0 is flagged LOCAL (database) and anounced by AS1270 (BGP) 193.96.108.0 is flagged LOCAL (database) and anounced by AS1270 (BGP) 193.96.109.0 is flagged LOCAL (database) and anounced by AS1270 (BGP) 193.96.234.0 is flagged LOCAL (database) and anounced by AS1270 (BGP) 193.140.2.0 is flagged LOCAL (database) and anounced by AS1104 (BGP) 193.140.3.0 is flagged LOCAL (database) and anounced by AS1104 (BGP) 193.166.24.0 is flagged LOCAL (database) and anounced by AS1739 (BGP) 193.166.25.0 is flagged LOCAL (database) and anounced by AS1739 (BGP) 193.166.26.0 is flagged LOCAL (database) and anounced by AS1739 (BGP) 193.166.28.0 is flagged LOCAL (database) and anounced by AS1739 (BGP) 193.166.31.0 is flagged LOCAL (database) and anounced by AS1741 (BGP) 193 nets not in the database and being routed. 193.64.50.0 not in database 193.68.160.0 not in database 193.120.242.0 not in database 193.128.85.0 not in database 193.128.142.0 not in database 193.166.64.0 not in database 193.166.66.0 not in database Networks being announced as being in more than one AS *** conflict 129.132.0.0 in AS1836 *** conflict 129.132.0.0 in AS559 *** conflict 130.168.0.0 in AS1270 *** conflict 130.168.0.0 in AS543 *** conflict 132.176.0.0 in AS1270 *** conflict 132.176.0.0 in AS2125 *** conflict 132.180.0.0 in AS1270 *** conflict 132.180.0.0 in AS2125 *** conflict 134.93.0.0 in AS1270 *** conflict 134.93.0.0 in AS2125 *** conflict 134.99.0.0 in AS1270 *** conflict 134.99.0.0 in AS2125 *** conflict 134.104.0.0 in AS1270 *** conflict 134.104.0.0 in AS2125 *** conflict 134.106.0.0 in AS1270 *** conflict 134.106.0.0 in AS2125 *** conflict 134.107.0.0 in AS1270 *** conflict 134.107.0.0 in AS2125 *** conflict 138.199.0.0 in AS1104 *** conflict 138.199.0.0 in AS1270 *** conflict 139.11.0.0 in AS1270 *** conflict 139.11.0.0 in AS2125 *** conflict 141.100.0.0 in AS1270 *** conflict 141.100.0.0 in AS2125 *** conflict 143.93.0.0 in AS1270 *** conflict 143.93.0.0 in AS2125 *** conflict 143.233.0.0 in AS1104 *** conflict 143.233.0.0 in AS2546 *** conflict 143.233.0.0 in AS786 *** conflict 144.145.0.0 in AS1270 *** conflict 144.145.0.0 in AS2125 *** conflict 146.107.0.0 in AS1270 *** conflict 146.107.0.0 in AS2125 *** conflict 147.172.0.0 in AS1270 *** conflict 147.172.0.0 in AS2125 *** conflict 147.196.0.0 in AS1717 *** conflict 147.196.0.0 in AS1899 *** conflict 148.6.0.0 in AS1955 *** conflict 148.6.0.0 in AS513 *** conflict 157.25.0.0 in AS1729 *** conflict 157.25.0.0 in AS1887 *** conflict 157.159.0.0 in AS1717 *** conflict 157.159.0.0 in AS1899 *** conflict 192.16.183.0 in AS1104 *** conflict 192.16.183.0 in AS1890 *** conflict 192.16.189.0 in AS1103 *** conflict 192.16.189.0 in AS1104 *** conflict 192.16.192.0 in AS1104 *** conflict 192.16.192.0 in AS786 *** conflict 192.42.129.0 in AS1103 *** conflict 192.42.129.0 in AS1104 *** conflict 192.70.89.0 in AS1717 *** conflict 192.70.89.0 in AS1899 *** conflict 192.70.90.0 in AS1717 *** conflict 192.70.90.0 in AS1899 *** conflict 192.70.110.0 in AS1717 *** conflict 192.70.110.0 in AS1899 *** conflict 192.87.4.0 in AS1104 *** conflict 192.87.4.0 in AS1755 *** conflict 192.88.15.0 in AS1270 *** conflict 192.88.15.0 in AS2125 *** conflict 192.93.254.0 in AS1717 *** conflict 192.93.254.0 in AS1899 *** conflict 192.108.31.0 in AS1270 *** conflict 192.108.31.0 in AS2125 *** conflict 192.109.2.0 in AS1270 *** conflict 192.109.2.0 in AS2125 *** conflict 192.109.3.0 in AS1270 *** conflict 192.109.3.0 in AS2125 *** conflict 192.109.4.0 in AS1270 *** conflict 192.109.4.0 in AS2125 *** conflict 192.109.5.0 in AS1270 *** conflict 192.109.5.0 in AS2125 *** conflict 192.109.6.0 in AS1270 *** conflict 192.109.6.0 in AS2125 *** conflict 192.134.91.0 in AS1717 *** conflict 192.134.91.0 in AS1899 *** conflict 192.195.187.0 in AS2018 *** conflict 192.195.187.0 in AS701 *** conflict 193.104.88.0 in AS1717 *** conflict 193.104.88.0 in AS1899 Possible bogus networks being announced. *** Bogus 200.6.18.0 from AS2277

1 0