We're now going to talk about receiving prefixes from the upstream or transit provider. An upstream or transit provider is an ISP who you would pay to give you transit to the whole internet. This means that receiving prefixes from them is not desirable, unless really necessary. This might sometimes be done for the purposes of traffic engineering, which will be discussed in BGP multihoming presentations. In general your upstream or transit provider will either originate a default route or announce one prefix you can use as default. An example of how a downstream router is configured to receive prefixes from the upstream or transit provider is shown on the screen. As you can see, only the default route is permitted from the upstream provider using the "prefix-list infilter", which is then applied as an inbound filter list. The "prefix-list outfilter" is used for configuring the prefix [that] the downstream router is announcing to the upstream, and this is applied as the outbound filter list. For the upstream router configuration the reverse is applied as you can see on the screen. Only the downstream provider prefixes is permitted under "prefix-list cust-in" and applied as the inbound filter list. The default route, on the other hand, is permitted on the "cust-out" prefix-list, and applied as the outbound filter list towards the downstream router. If it is necessary to receive prefixes from any provider, care is required. Don't accept default unless you need it. Don't accept your own prefixes. Special use prefixes for IPv4 and IPv6 are shown on the URL below for RFC6890. Remember, one should not accept prefixes longer than a /24 for IPv4, or accept prefixes longer than a /48 for IPv6, as there are a minimum prefixes delegated to any site. Tools that will help you with upstream or peering configurations are shown on the screen. You can check Team Cymru's list of "bogons", which provides a list of address blocks which should not appear on the Internet. The Bogon Route Server can also be found on the URL shown on the screen. You can also look at RFC6441 for /8 prefixes that should no longer be filtered. For IPv6 you can look at the URL on the screen, which gives you some recommendations as to what IPv6 filters you should be using. Examples of the various filters that can be used when using IPv4 is shown on the screen, with comments of what each one of them does. Pay special attention to the red line which indicates that you should not be receiving your prefix from your upstream provider. Examples for the IPv6 filters are also shown on your screen. The various filters generally aid in avoiding [serious] security risk. Examples for IPv6 filters are also shown on the screen, the various filters generally aid in avoiding [serious] security risk. In conclusion, paying special attention to prefixes received from customers, peers, and transit providers, generally assists with the integrity of the local network, as well as the internet. It is the responsibility of all ISPs to be good Internet citizens.

© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.

Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.