- Test - lists.nanog.org

Re: 206.82.160.0/22
by David R Conrad 23 Sep '95

23 Sep '95

>The Internic is the sole and ultimate assigning entity of IP space, Ummm, no. RIPE-NCC and APNIC also assign address space as regional registries, CANET, JPNIC, KRNIC, and AUNIC/Telstra assign space as national registries. One might claim the IANA has the ultimate responsibility regarding address space, but this is somewhat irrelevant to this discussion. >and >Sprint specifically rejected any support for me or my provider in obtaining >at least a /20 assignment from the Internic, Why didn't you obtain the /20 from Sprint? >I was given this /22 assignment >(while continuous usage of the link ensures this space will be used >up in about 3-4 weeks, with /26 assignments going to BelCom's leased line >customers) even though the Internic knew better about necessary route >aggregation. I'm confused. You were given a /22 by InterNIC which is (presumably) provider independent, and which included a statement from InterNIC that says that routing is not guaranteed (which should, of course, be obvious) and you seem to be claiming they didn't understand about route aggregation. I would assume InterNIC encouraged you to obtain your address space from your service provider (Sprint) so your routes could be aggregated in your service provider's block. Are you saying that Sprint refused to allocate the space you required? >I consider it extremely hostile from Sean Doran and hence Sprint to suddenly Sean has been talking about this for at least 9 months. >come and announce filtering of just those networks they are announcing on >their own, ENCOURAGING OTHER NSPs TO DO LIKEWISE, bypass the ultimate >arbitrator (Internic) , No. InterNIC is only the ultimate arbitrator of who a particular address is delegated to within the blocks that InterNIC has authority. This has absolutely nothing to do with routability of those addresses. There is no ultimate arbitrator for routability -- it is a cooperative effort by all service providers. Due to routers falling over, some service providers are not interested in being as cooperative as they once were. >I can only >strongly discourage the implementation of the prefix filtering for prefixes >longer than /18 in 206.* through 239.* What is your suggestion to reduce the routing overload? Regards, -drc

3 3

RE: Sprint violations
by lodge＠houston.omnes.net 22 Sep '95

22 Sep '95

At 9:10 9/22/95, Noel Chiappa wrote: >On the other hand, if Sean et al are willing to take the arrows (arrows -> >pioneers, right? :-), good for them; it will provide cover for providers to >tell their own customers "sorry, there's no use sending out your /28; Sprint >will just filter it". It's always easier to tell a paying customer "no" when >you're just relaying someone else's decision, not your own, no? Well, no, actually. Customers don't care who's fault it is -- as far as they're concerned, it's broken. I had a similar situation impressed on me today: one of our customers wants to send e-mail with MIME attachments to one of his customers who has a CompuServe account. The attachments never make it through the CompuServe e-mail gateway. Now, we know that this is not a problem with our TCP/IP network and SMTP implementation -- it's a problem at the CompuServe end. The customer knows nothing about e-mail gateways, and nor does he care. As far as he's concered, it doesn't work. And Omnes, as his solutions provider, had better fix it. I still haven't worked out how to appease this particular individual: but my point is that customers dislike "finger pointing" when it comes to resolving a problem. It won't wash. Regards, Mathew | Mathew Lodge: lodge(a)houston.omnes.net |5599 San Felipe, 4th Floor | | Internet Specialist, Omnes -- A |Houston, Texas 77056, USA | | Schlumberger/Cable & Wireless company |Phone: +1 713 513 3237 | | "Bibunt omnes sine lege" |Fax: +1 713 513 3126 |

2 1

Re: filtering long prefixes
by jnc＠ginger.lcs.mit.edu 22 Sep '95

22 Sep '95

From: Mark Kent <mark(a)mainstreet.net> The Internet is no longer an experiment. Well, yes and no. I take very well your point that it's a very large public utility (in the sense of something that people depend on), but at the same time we (i.e. humans) haven't ever built a system like this before, so it's inevitably "an experiment". Like it or not, we're going to be taking some wrong turns. (Long argument as to why this is inevitable left out in the interest of brevity.) So, there are going to be periods of pain while we back and fill. Ladies and gentlemen, please fasten your seat-belts, the ride is going to be a little choppy... Move on higher up the chain and try again. Cutting off companies retroactively is not the answer. You need to put filters in that cut no one off today, but protect against growth tomorrow. Err, umm. If we are to achieve the same *overall* degree of aggregation, accepting less/no aggregation in the numbers allocated in the past means we have to achieve a lot more aggregation (perhaps unachievable levels) in the numbers allocated in the future. Perhaps the right answer, considered as a overall optimization problem, is not quite this far to one end of the spectrum reaching from "old-none, new-total" at one end to "everyone the same" at the other. Noel

2 1

Re: filtering long prefixes
by Sean Doran 22 Sep '95

22 Sep '95

Mark - I agree with you 100% that the Internic had adopted a policy of handing out longer prefixes than I had initially warned everyone Sprint would be refusing to accept from external neighbours. I also note that the Internic also had wording which pointed out the dangers of accepting this sort of prefix from them, right on its application form, which I reproduce below. I think that the InterNIC did its job of warning people of upcoming realities, and therefore its policies were not, in fact, in conflict with ours. 206/8 was specifically chosen, in fact, because no allocations had been made from it at the time. Now, I note that I have pointed out that we are willing to be flexible when it comes to /19s, but for the moment, the filter will reject anything longer than /18s in 206/8 to 239/8. In part this is because it gives me the opportunity to study who has gotten disconnected and how difficult it will be to reconnect them without doubling the number of prefixes we will see in 206/8, not to mention 207/8 to 239/8. You may call it direct engineering terrorism if you like. I call it a sound, planned, well-announced step to keep the maximum growth of the routing tables confined to the level at which technology exists to support them. My only (large) regret is that any long prefixes in 206/8 ever worked at all, principally due to an oversight in a reconfiguration of ICM AS 1800. I hate breaking things that were already working... To translate that sentence: "Maybe. Let's see how bad the mess is first." Sean. - -- from ftp://rs.internic.net/templates/internet-number-template.txt Due to technical and implementation constraints on the Internet routing system and the possibility of routing overload, certain policies may need to be enforced by the major transit providers in order to reduce the number of globally advertised routes. These potential policies may include setting limits on the size of CIDR prefixes added to the routing tables, filtering of non-aggregated routes, etc. Therefore, addresses obtained directly from the InterNIC (non-provider-based, also known as portable) are not guaranteed to be routable on the Internet. ^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

3 2

Re: Sprint violations
by jnc＠ginger.lcs.mit.edu 22 Sep '95

22 Sep '95

From: Per Gregers Bilse <bilse(a)eu.net> One problem we see is European offices/branches of US companies who want to use parts of their "company B" for a European connection As long as people see IPv4 addresses (as currently used, as routing-names - darn I wish we had a better piece of jargon there) as a purely administrative thing, some number you get assigned randomly, this makes sense. We have to make people think of IPv4 addresses as things which say where you are in the net, things which are higly ordered. I think Sprint's approach is rather heavy-handed and probably a toad counter-productive in the long run. I would consider it reasonable for Sprint to filter their own funny stuff .. for a considerable length of time before filtering other people's funny stuff ... Plus stones and glasshouses, etc. Well, I see your point. Also, if everyone filter out subnets outbound, we wouldn't need inbound filters, anyway, right? On the other hand, if Sean et al are willing to take the arrows (arrows -> pioneers, right? :-), good for them; it will provide cover for providers to tell their own customers "sorry, there's no use sending out your /28; Sprint will just filter it". It's always easier to tell a paying customer "no" when you're just relaying someone else's decision, not your own, no? Noel

1 0

206.82.160.0/22
by Kai 22 Sep '95

22 Sep '95

To the fellow members of the NANOG, In a follow-up to the previous message I mailed from kai(a)netcom.com: 206.82.160.0/22 was assigned to me from the Internic not even 10 days ago. This network is routed from NY via Moscow to Almaty,Kazakhstan to give the NATO Internetworking conference (Sept. 25-29th) IP connectivity. The Internic is the sole and ultimate assigning entity of IP space, and Sprint specifically rejected any support for me or my provider in obtaining at least a /20 assignment from the Internic, I was given this /22 assignment (while continuous usage of the link ensures this space will be used up in about 3-4 weeks, with /26 assignments going to BelCom's leased line customers) even though the Internic knew better about necessary route aggregation. I consider it extremely hostile from Sean Doran and hence Sprint to suddenly come and announce filtering of just those networks they are announcing on their own, ENCOURAGING OTHER NSPs TO DO LIKEWISE, bypass the ultimate arbitrator (Internic) , and hence instantly endanger an event that has cost BelCom, Digital Equipment Corporation and the Government of Kazakhstan in excess of 250 man hours and approximately US$50,000 so far. I can only strongly discourage the implementation of the prefix filtering for prefixes longer than /18 in 206.* through 239.* , as the failure of this event will result in lawsuits with damages sought that will positively exceed Sean's yearly salary. Not to mention, that I will ensure that the entire conference with 600 attendees and the Government of Kazakhstan will know about all of this from a press release I am preparing this minute, and I guess Arna-Sprint/Almaty can kiss some of their data licenses they have obtained from the government good-bye, too, shall this engineering terrorism against Sprint's own customers and customers thereof not cease and have the intended effect. Did I forget to mention that Arna-Sprint and SprintNet's X.25 service is hanging of a physical BelCom leased link, over there ? At least until tomorrow. Welcome to Kazakhstan. --- Kai Schlichting Internet Project Manager, BelCom, Inc. 515 Madison Ave Suite 2100 NY,NY 10022 212-705-9500 (voice) 212-755-0864 (fax) kai(a)belcom.net Ask us about Internet service in the CIS! Bringing Internet, where there is none (DUE to office move, phone numbers do not lead anywhere until Oct.1st, email is read 24h/7d)

1 0

Re: filtering long prefixes
by kai＠netcom.com 22 Sep '95

22 Sep '95

As my company (belcom.net) as gotten the 206.82.160.0/22 network assignment as recently as _10_ days ago (from the Internic, after endless fights against the small brains that wouldn't want to see the usefulness of route aggregation; and yes: it's routed by Sprint), isn't the Internic committing some terrible crime against the public , err: network , here ? Now, would someone please explain in no more than 5-10 lines why the old class-A and class-B space is NOT hacked into smaller than /8 and /16 assignments, or at least shouldn't ? bye,Kai --- Kai Schlichting Internet Project Manager, BelCom, Inc. 515 Madison Ave Suite 2100 NY,NY 10022 212-705-9500 (voice) 212-755-0864 (fax) kai(a)belcom.net

1 0

Re: Sprint violations
by Per Gregers Bilse 21 Sep '95

21 Sep '95

We have been filtering subnets of As (except 39) Bs and Cs for 5 months -- but outbound, not inbound (ie nobody behind us can announce these things except by special arrangement; we still hear other people's funny stuff). One problem we see is European offices/branches of US companies who want to use parts of their "company B" for a European connection, instead of using local provider space; filtering subnets is a good incentive for them to overcome that desire. It's clear that the Net needs fewer announcements and this is one way to go; and by filtering essentially "rogue" networks inbound (towards presumably interesting things), one likewise provides an incentive for better aggregation. However, I think Sprint's approach is rather heavy-handed and probably a toad counter-productive in the long run. I would consider it reasonable for Sprint to filter their own funny stuff (like we have done) for a considerable length of time before filtering other people's funny stuff; if for no other reason than proof of concept on home ground. Plus stones and glasshouses, etc. -- ====== ___ === Per G. Bilse, Mgr Network Operations Ctr ===== / / / __ ___ _/_ ==== EUnet Communications Services B.V. ==== /--- / / / / /__/ / ===== Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / ====== tel: +31 20 6233803, fax: +31 20 6224657 === ======= 24hr emergency number: +31 20 421 0865 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse(a)EU.net

1 0

filtering long prefixes
by Sean Doran 21 Sep '95

21 Sep '95

I was talking to a set of customers of ours today, some of whom were dealing with some long prefixes which were being heard originating within SprintLink and propagating to MCI. This caused me to audit how well our edge filtering was working, and to spend some time reworking the filters that match long prefixes. I shall post the text of the filter here tomorrowishly so that everyone can look at how gross it is, comments-and-all. Meanwhile, however, it seems correctly to implement this policy, which is now many months old: reject BGP announcements which: -- are an old-style classful A network with a mask longer than 8 bits except for exp39, 39.0.0.0/8, where we allow prefixes to be up to 24 bits long and the two operational IBM prefixes: 9.20.0.0/18 and 9.2.0.0/16. -- are an old-style classful B network with a mask longer than 16 bits -- are in the range of 206.0.0.0/8 to 239.0.0.0/8 with a mask longer than 18 bits -- has a mask longer than 24 bits [RSN we will also reject RFC1597 prefixes in this list; currently another mechanism is used to avoid hearing RFC1597 prefixes.] Note that we accept prefixes in the range of 192.0.0.0/8 - 205.0.0.0/8 (known cordially as The Swamp) as long as the prefix is at least 24 bits long. Also, this is not cast in concrete; there was some discussion of possibly allowing /19s at some point, and also some discussion about attacking the top several octets of The Swamp, by allowing only /23s or shorter. There has also been some talk about relaxing the maximum mask length on 1.0.0.0/8 - 126.0.0.0/8 to something a bit longer. I suspect all of this will be revisited at intervals, however, I believe that the consensus at the NANOG in Pittsburgh was that it'd be a good idea to post things like this here. Also, I note that we currently are not applying this list *outbound* or against customer BGP sessions. The reason for this is quite simple -- call it a (very) small incentive for other folks we peer with to apply the same kind of inbound filter against very long prefixes. I will admit that this is more a case of oversight than direct engineering terrorism, however, at some point we certainly will begin stopping the announcement of this type of long prefix to our external peers, and in the mean time it's useful to know that there really are people out there who notice /32s and the like floating around, and who complain about them. That's a good thing. Personally, I'd be grateful if people *did* toss long prefixes gotten from SprintLink (and elsewhere), so long as they tell people about it. Penultimately, this filter is currently deployed at all of SprintLink's edges, but not within ICM AS 1800. This is principally to allow for differential comparisons between what long prefixes the two networks see over the next short while. That makes it easier to see what we're filtering out on the SprintLink side, in hopes of catching botches and spending a couple of days firing off email to people responsible for announcing long prefixes, explaining why they should stop. Finally, the list of the prefixes affected by the filter, obtained by differential comparison between SL and ICM, is below. The classful subnets were noted in CIDRD; the stuff in 206/8 is of some interest to the very-newly-connected (connected, in fact, by people who probably didn't warn their customers of the very very very old announcements I made here and on CIDRD about precisely this filtering on 206/8, on 13 April, 23 June, 24 August, and other dates, and at NANOGs and IETFs galore) are interesting: many (more than 120) are covered by idempotent less-specific aggregates anyway, and others seem to be easily aggregatable, or just don't seem to go anywhere yet. Sean. - -- Sean Doran <smd(a)sprint.net> - -- cut here ---- [subnets of classful A space, classful B space, and all >/24s] [ prefix as-path ] 129.40.43.0/24 690 2685 129.40.202.0/24 690 2685 129.159.147.0/24 1755 2874 129.159.148.0/24 1755 2874 131.115.186.0/24 1755 3300 131.115.187.0/24 1755 3300 131.115.188.0/24 1755 3300 131.116.136.0/26 1755 3300 131.116.136.64/26 1755 3300 131.116.136.128/26 1755 3300 131.116.153.64/26 1755 3300 132.174.100.0/24 690 1325 4373 139.92.1.0/24 1804 1128 1275 145.17.100.0/24 1801 786 1849 147.186.219.64/26 1755 2874 148.185.45.0/24 1801 786 1849 148.252.1.0/24 1801 786 1849 149.212.64.0/23 1755 1759 544 151.185.100.0/22 3561 151.185.104.0/22 3561 151.185.108.0/23 3561 151.185.110.0/24 3561 152.129.186.0/24 3561 4478 155.140.123.0/24 1801 786 1849 159.24.7.64/26 3561 4286 159.189.128.0/19 3561 279 2048 {33035} 160.8.106.0/24 1755 2874 160.8.110.0/23 1755 2874 161.52.192.0/19 1653 2843 2845 164.9.190.0/31 1755 3300 164.9.194.0/31 1755 3300 164.9.196.0/24 1755 3300 166.38.40.0/24 3561 166.147.0.0/18 3561 166.147.192.0/18 3561 166.150.0.0/18 3561 166.150.64.0/18 3561 166.150.128.0/18 3561 166.150.192.0/18 3561 166.151.0.0/18 3561 166.151.64.0/18 3561 166.151.128.0/18 3561 166.151.192.0/18 3561 167.170.7.0/24 1755 3300 3302 3313 170.194.51.0/24 1801 786 1849 171.25.128.0/20 1755 3300 171.25.144.0/21 1755 3300 192.108.149.128/26 1804 1128 2605 1902 1922 193.172.1.192/27 1804 1128 2043 194.45.40.161/32 1755 517 194.45.120.0/26 1755 517 194.45.120.64/26 1755 517 194.45.120.128/26 1755 517 194.45.121.0/28 1755 517 194.45.121.128/28 1755 517 194.45.121.192/28 1755 517 194.45.236.64/28 1755 517 194.45.236.80/28 1755 517 198.226.1.80/28 3561 - -- [206/8 more-specifics] [ prefix as-path ] 206.12.1.0 3561 577 271 206.12.2.0 3561 577 271 206.12.8.0 3561 577 271 206.12.10.0 3561 577 271 206.12.11.0 3561 577 271 206.12.15.0 3561 577 271 206.12.16.0 3561 577 271 206.12.17.0 3561 577 271 206.12.18.0 3561 577 271 206.12.19.0 3561 577 271 206.12.20.0 3561 577 271 206.12.21.0 3561 577 271 206.12.22.0 3561 577 271 206.12.23.0 3561 577 271 206.12.24.0 3561 577 271 206.12.25.0 3561 577 271 206.12.26.0 3561 577 271 206.12.32.0 3561 577 271 206.12.33.0 3561 577 271 206.12.34.0 3561 577 271 206.12.35.0 3561 577 271 206.12.36.0 3561 577 271 206.12.37.0 3561 577 271 206.12.38.0 3561 577 271 206.12.39.0 3561 577 271 206.12.40.0 3561 577 271 206.12.41.0 3561 577 271 206.12.42.0 3561 577 271 206.12.43.0 3561 577 271 206.12.44.0 3561 577 271 206.12.45.0 3561 577 271 206.12.46.0 3561 577 271 206.12.47.0 3561 577 271 206.12.59.0 3561 577 271 206.12.96.0 690 1331 1691 206.12.101.0 3830 4064 3609 206.12.108.0 3830 4064 3609 206.12.111.0 690 1331 1691 206.12.112.0 3830 4064 3609 206.12.113.0 3830 4064 3609 206.12.114.0 3830 4064 3609 206.12.115.0 3830 4064 3609 206.12.117.0 690 1331 1691 206.12.118.0 3830 4064 3609 206.12.119.0 3830 4064 3609 206.12.126.0 3830 4064 3609 206.12.134.0 690 1331 1691 206.12.151.0 690 1331 1691 206.12.153.0 3830 4064 3609 206.12.154.0 3561 2493 206.12.156.0 3830 4064 3609 206.12.158.0 3830 4064 3609 206.12.159.0 3830 4064 3609 206.12.168.0 3830 4064 3609 206.12.169.0 3830 4064 3609 206.12.170.0 3830 4064 3609 206.12.171.0 3830 4064 3609 206.12.172.0 3830 4064 3609 206.12.173.0 3830 4064 3609 206.12.174.0 3830 4064 3609 206.12.175.0 690 1331 1691 206.12.176.0 690 1331 1691 206.12.177.0 690 1331 1691 206.12.178.0 690 1331 1691 206.12.179.0 690 1331 1691 206.12.180.0 690 1331 1691 206.12.181.0 690 1331 1691 206.12.186.0 3830 4064 3609 206.12.187.0 3561 2493 206.12.188.0 690 1331 1691 206.12.202.0/23 3561 5071 206.12.206.0 3561 5071 206.12.208.0 3561 5071 206.12.226.0 690 1331 1691 206.12.227.0 690 1331 1691 206.12.229.0 690 1331 1691 206.12.230.0 690 1331 1691 206.12.237.0 3561 5071 206.12.238.0/23 3561 5071 206.12.241.0 690 1331 1691 206.12.247.0 690 1331 1691 206.13.0.0/19 3830 4200 5671 206.13.32.0/19 3830 4200 5672 206.13.64.0/19 3830 4200 5672 206.13.96.0/20 3830 4200 5672 206.15.32.0/19 3561 1746 206.15.64.0/19 3830 4200 4540 206.15.96.0/19 3561 560 206.15.128.0/19 3561 560 206.16.206.0 1740 206.16.208.0 1740 206.16.209.0 1740 206.16.210.0 1740 206.16.211.0 1740 206.16.212.0 1740 206.16.213.0 1740 206.16.214.0 1740 206.16.215.0 1740 206.16.219.0 1740 206.16.221.0 1740 206.16.222.0 1740 206.17.4.0 1740 206.17.18.0 1740 206.24.0.0/19 3561 206.24.8.0/23 3561 206.24.28.0/23 3561 206.24.32.0/19 3561 206.24.44.0 3561 206.24.64.0/19 3561 206.24.96.0/19 3561 206.24.128.0/21 3561 206.24.136.0/21 3561 206.24.152.0/21 3561 206.24.160.0/21 3561 206.24.168.0/21 3561 206.24.172.0/22 3561 206.24.176.0/21 3561 206.24.192.0/21 3561 206.24.200.0/21 3561 206.24.216.0/21 3561 206.24.224.0/21 3561 206.25.0.0/19 3561 206.25.32.0/19 3561 206.25.36.0/23 3561 206.25.64.0/20 3561 206.25.64.0/19 3561 206.25.86.0/23 3561 206.25.88.0/22 3561 206.25.92.0/23 3561 206.25.94.0 3561 206.25.96.0/19 3561 206.25.128.0/19 3561 206.25.160.0/19 3561 206.25.168.0/23 3561 206.25.182.0 3561 206.25.184.0/23 3561 206.25.192.0/19 3561 206.25.224.0/19 3561 206.25.226.0/23 3561 206.26.0.0/19 3561 206.26.10.0/23 3561 206.26.32.0/19 3561 206.26.50.0/23 3561 206.26.64.0/19 3561 206.26.96.0/23 3561 5650 206.26.96.0/19 3561 206.26.98.0/23 3561 206.26.128.0/19 3561 206.26.142.0/23 3561 206.26.160.0/19 3561 206.26.192.0/19 3561 206.26.224.0/19 3561 206.27.64.0/19 3561 206.27.96.0/19 3561 206.27.128.0/19 3561 206.27.138.0/23 3561 206.27.160.0/19 3561 4947 206.27.192.0/19 3561 206.27.206.0 3830 4991 4959 206.27.207.0 3830 4991 4959 206.27.224.0/19 3561 206.27.236.0/23 3561 206.28.0.0/19 3561 206.28.16.0/22 3561 206.28.32.0/19 3561 206.28.64.0/19 3561 206.28.96.0/19 3561 206.28.110.0/23 3561 206.28.120.0/23 3561 206.28.122.0/23 3561 206.28.128.0/19 3561 206.28.158.0 3561 206.28.160.0/19 3561 206.28.172.0/23 3561 206.28.192.0/19 3561 206.28.224.0/19 3561 206.29.0.0/23 3561 206.29.0.0/19 3561 206.29.8.0/23 3561 206.29.14.0/23 3561 206.29.24.0/23 3561 206.29.29.0 3561 206.29.32.0/23 3561 206.29.32.0/19 3561 206.29.34.0/23 3561 206.29.36.0/23 3561 206.29.39.0 3561 206.29.64.0/20 3561 206.29.64.0/19 3561 206.29.88.0/21 3561 206.29.96.0/19 3561 206.29.108.0 3561 206.29.108.0/23 3561 206.29.114.0/23 3561 206.29.128.0/19 3561 206.29.160.0/19 3561 206.29.192.0/19 3561 5650 206.29.224.0/19 3561 206.30.0.0/19 3561 206.30.32.0/21 3561 206.30.32.0/19 3561 206.30.64.0/19 3561 206.30.96.0/19 3561 206.30.128.0/20 3561 206.30.128.0/19 3561 206.30.160.0/19 3561 206.30.180.0/23 3561 206.30.192.0/19 3561 206.30.208.0/23 3561 206.30.224.0/19 3561 206.30.228.0/23 3561 206.31.0.0/19 3561 206.31.32.0/19 3561 206.31.64.0/19 3561 206.31.96.0/19 3561 206.31.110.0/23 3561 206.31.116.0/23 3561 206.31.128.0/19 3561 206.31.130.0/23 3561 206.31.160.0/19 3561 206.31.192.0/19 3561 206.31.224.0/19 3561 206.31.226.0/23 3561 206.37.1.0 568 206.37.2.0 568 206.37.13.0 568 206.40.32.0/19 3830 4200 3720 206.40.64.0/19 701 3967 206.40.160.0/20 3561 114 206.40.192.0 3830 3491 4565 206.40.192.0/19 3830 3491 4565 206.40.221.0 3830 3491 4565 206.41.0.0/19 3561 206.41.32.0/21 3561 5109 206.41.64.0/21 3830 4388 4920 206.41.96.0/21 3561 206.41.160.0/22 3830 4200 206.41.164.0 3830 4200 206.41.165.0 3830 4200 206.41.166.0 3830 4200 206.41.167.0 3830 4200 206.41.168.0/23 3830 4200 206.41.170.0 3830 4200 206.41.171.0 3830 4200 206.41.172.0 3830 4200 206.41.173.0 3830 4200 206.41.177.0 3830 4200 206.41.178.0 3830 4200 206.41.214.0/23 3561 206.41.216.0/21 3561 206.43.0.0/19 3830 4388 206.43.36.0/22 3830 4388 206.43.64.0/19 701 3838 3838 3838 3838 3838 3838 3838 206.43.96.0 3830 4388 206.43.98.0/23 3830 4388 206.43.100.0 3830 4388 206.43.104.0 3830 4388 206.43.104.0/21 3830 4388 206.43.105.0 3830 4388 206.43.106.0 3830 4388 206.43.111.0 3830 4388 206.43.112.0/20 3830 4388 206.43.176.0/21 3830 4388 206.43.182.0 3830 4388 206.43.224.0/22 3830 4388 206.53.64.0/22 3830 4200 206.53.128.0 3561 206.53.224.0/19 3561 206.54.160.0/19 3561 206.54.192.0/22 3561 2150 226 206.55.1.0 3561 6618 206.55.2.0 3561 6618 206.55.3.0 3561 6618 206.55.4.0 3561 6618 206.55.5.0 3561 6618 206.55.6.0 3561 6618 206.55.10.0 3561 6618 206.55.12.0 3561 6618 206.55.13.0 3561 6618 206.55.14.0 3561 6618 206.55.15.0 3561 6618 206.55.16.0 3561 6618 206.55.17.0 3561 6618 206.55.18.0 3561 6618 206.55.19.0 3561 6618 206.55.20.0 3561 6618 206.55.21.0 3561 6618 206.55.23.0 3561 6618 206.55.24.0 3561 6618 206.55.25.0 3561 6618 206.55.26.0 3561 6618 206.55.30.0 3561 6618 206.55.55.0 3561 6618 206.55.56.0 3561 6618 206.55.57.0 3561 6618 206.55.58.0 3561 6618 206.55.59.0 3561 6618 206.55.60.0 3561 6618 206.55.61.0 3561 6618 206.55.62.0 3561 6618 206.55.63.0 3561 6618 206.55.128.0/19 3561 2150 226 206.62.4.0/22 3830 4200 206.64.48.0 701 3791 206.64.49.0 701 3791 206.64.50.0 701 3791 206.64.52.0 701 3791 206.64.53.0 701 3791 206.64.58.0 701 3791 206.64.59.0 701 3791 206.64.60.0 701 3791 206.64.62.0 701 3791 206.64.63.0 701 3791 206.64.123.0 701 5706 206.64.128.0 701 3397 206.64.130.0 701 3397 206.64.131.0 701 3397 206.64.132.0 701 3397 206.64.134.0 701 3397 206.64.147.0 3561 114 206.64.159.0 3830 4992 3803 206.66.1.0 701 4278 206.66.2.0 701 4278 206.66.3.0 701 4278 206.66.176.0 701 4206 206.66.177.0 701 4206 206.66.192.0 701 4438 206.71.128.0/21 701 206.71.160.0/21 3561 206.71.224.0/19 3561 3674 206.72.128.0/19 701 206.72.224.0/22 3561 279 206.73.70.0 3561 2150 226 1220 206.73.71.0 3561 2150 226 1220 206.73.72.0/22 3561 2150 226 1220 206.73.76.0/23 3561 2150 226 1220 206.73.78.0 3561 2150 226 1220 206.75.4.0 3561 577 542 206.75.6.0 3561 577 542 206.75.7.0 3561 577 542 206.75.19.0 690 1331 1684 206.75.224.0 3561 577 542 206.75.225.0 3561 577 542 206.75.250.0 690 1331 1684 206.80.0.0/19 3830 4447 206.80.64.0 1740 206.80.65.0 1740 206.80.66.0 1740 206.80.67.0 1740 206.80.68.0 1740 206.80.69.0 1740 206.80.70.0 1740 206.80.71.0 1740 206.80.224.0/21 701 206.81.224.0/19 701 4232 206.96.0.0/19 3561 206.96.32.0/19 3561 206.96.64.0/19 3561 206.96.96.0/23 3561 206.96.96.0/19 3561 206.96.104.0/22 3561 206.96.128.0/19 3561 206.96.160.0/21 3561 206.96.160.0/19 3561 206.96.192.0/19 3561 206.96.224.0/19 3561 206.97.0.0/19 3561 206.97.32.0/19 3561 206.97.64.0/20 3561 206.97.64.0/19 3561 206.97.96.0/19 3561 206.97.128.0/19 3561 206.97.160.0/19 3561 206.97.192.0/19 3561 206.97.224.0/19 3561 206.98.0.0/19 3561 206.98.32.0/23 3561 206.98.32.0/19 3561 206.98.64.0/19 3561 206.98.96.0/19 3561 206.98.128.0/19 3561 206.98.160.0/19 3561 206.98.192.0/19 3561 206.98.224.0/19 3561 206.99.0.0/19 3561 206.99.32.0/19 3561 206.99.64.0/19 3561 206.99.90.0 3561 206.99.96.0/19 3561 206.99.128.0/19 3561 206.99.160.0/19 3561 206.99.192.0/19 3561 206.99.224.0/19 3561 206.100.0.0/19 3561 206.100.32.0/19 3561 206.112.32.0/19 701 5053 206.116.1.0 3561 2493 206.116.4.0 3561 2493 206.116.5.0 3561 2493 206.116.6.0 3561 2493 206.116.10.0 3561 2493 206.116.11.0 3561 2493 206.128.23.0 701 3791 206.139.72.0/23 3561 206.195.64.0/19 3561 3909 206.196.0.0/20 3561 206.196.32.0/20 3830 4991 206.196.64.0/20 3561 206.196.96.0/20 3561 4205 206.196.160.0/19 690 2548 206.197.2.0 701 206.197.19.0 3561 206.197.51.0 701 206.197.68.0 690 1332 206.197.95.0 3830 3491 3739 206.197.101.0 86 225 206.197.103.0 3830 4992 206.197.133.0 3830 4992 206.197.138.0 1740 206.197.143.0 3561 206.197.184.0 3830 4994 206.197.204.0 701 2927 206.201.192.0/20 701 206.209.176.0/21 3561 206.209.183.0 3561 206.209.184.0/22 3561 206.209.188.0/23 3561

6 5

FYI: EuropaNET migration
by M.H.Behringer＠dante.org.uk 21 Sep '95

21 Sep '95

EuropaNET Migration Starts Tomorrow You may have heard about the migration of EuropaNET to a new backbone. Basically, todays core, EMPB (AS 2043) will be replaced by a new core network, IBDNS (AS 5400). The transition will start tomorrow and hopefully finish mid next week. The final switch-off of the EMPB is on the 2nd Oct 95, 9:00 CET (GMT+1). Obviously we try to handle things such that the migration should be smooth. However, if you are filtering based on AS paths to some of the destinations below, you might have to change your filters. Generally, if you experience routing problems during this period to the ASes mentioned below, and in particular if the core ASes 1128, 2043, 5400 are involved, contact nmc(a)dante.org.uk. For non-European networks these changes should be invisible, except that some ASes will gradually not use the 1800 1804 1128 connection any more, but 690 1128 5400 *. This path is in use already today, so there should be no problems. Note also that a number of ASes mentioned below is not affected, because they have other arrangements for intercontinental capacity. The following ASes are involved in the migration: (This macro as-dante will be available on whois -h whois.ripe.net tomorrow.) *am: AS-DANTE *de: DANTE customers. *al: AS137 AS513 AS559 AS766 AS786 AS789 AS1103 AS1104 AS1125 *al: AS1128 AS1135 AS1213 AS1274 AS1275 AS1754 AS1888 AS1902 AS1922 *al: AS1930 AS1955 AS2012 AS2038 AS2060 AS2107 AS2111 AS2546 AS2547 *al: AS2592 AS2598 AS2602 AS2605 AS2607 AS2611 AS2614 AS2875 AS2879 *al: AS3208 AS3219 AS3230 AS3314 AS3323 AS3333 AS3346 AS5400 *al: AS-NORDUNET For more information please refer to the (very) detailed EuropaNET routing plan and other information (topology, ...) on: ftp://ftp.dante.net/pub/europanet/transition/* For more information, problems, questions, etc... contact: nmc(a)dante.org.uk (+44.1223.302992, fax: +44.1223.303005) Michael Behringer DANTE NMC

1 0