- Test - lists.nanog.org

RE: Operational Issues with 69.0.0.0/8...
by Todd A. Blank 07 Dec '02

07 Dec '02

This will never work - because it all makes way too much sense... -----Original Message----- From: Leo Bicknell [mailto:bicknell@ufp.org] Sent: Friday, December 06, 2002 5:18 PM To: 'Adam Tauvix Debus'; nanog(a)merit.edu Subject: Re: Operational Issues with 69.0.0.0/8... In a message written on Fri, Dec 06, 2002 at 01:44:15PM -0700, Alec H. Peterson wrote: > ARIN announced the fact that it received the 69/8 delegation on August 8th. > ARIN received the delegation on August 6th. ARIN made its first > allocation/assignment (I don't know which it was, but that isn't important) > out of that block on September 19th. [snip] > Do people have any suggestions for ARIN (and other RIRs) on how they can > better dissemenate this information so that people will update their > filters? * One month from filtered to first use is too short. Should be 6 months, with multiple notices. To back this up I can point to a number of places that stopped all global changes from before thanksgiving to after christmas. (Not that I support such things.) * Mailing nanog is nice, but ARIN probably should mail all the ARIN members, or particularly people with ASN's. Far too many people view the nanog mailing list as entertainment, rather than operational necessity. * Space that goes from "reserved" to "in use" should be test routed first. Perhaps more of a job for ISI before they turn it over than ARIN. This allows people to make sure their changes actually worked. * Maintain an RADB object of reserved space, so those with automated tools can easily query it. * Perhaps offer a BGP feed (multi-hop, a-la RBL) of reserved space to ARIN members. If I were in charge it would be: 1) Notify all ARIN members 6 months in advance of the block being used. At the same time, announce the block from somewhere so people can check that they do in fact hear it as they open up their filters. 2) Notify people 3 months, 1 month, and 1 week before making the first allocation. 3) Drop the supernet test on the same day of the first allocation. 4) Listen to feedback from the first few people allocated space and if it still is not properly routed send out another notice to people and possibly delay additional allocations from the block for another month. -- Leo Bicknell - bicknell(a)ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request(a)tmbg.org, www.tmbg.org

3 2

Re: Operational Issues with 69.0.0.0/8...
by Michael.Dillon＠radianz.com 07 Dec '02

07 Dec '02

> My question is as follows - We are losing customers because of this > problem. It is costing us reputation and money. It is out of our > control. If you were us, what would you do? We have already asked ARIN > to reassign us to a "friendlier" CIDR, and they refuse. This is no longer a technical operational issue so it is out of scope for this mailing list. But if you think that ARIN could do something to solve your problem then you should raise the issue on the ARIN public policy mailing list. You can find subscription information for that list here http://www.arin.net/mailing_lists/index.html -- Michael Dillon

18 23

Juniper fxp0
by Manouchehr Mehrabi 07 Dec '02

07 Dec '02

Does anyone know how to enable Juniper fxp0 port for routing purposes? I am told there is a way. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

2 1

RE: Operational Issues with 69.0.0.0/8...
by James Smith 06 Dec '02

06 Dec '02

One would think that operators not updating filters to permit properly allocated space IS an operational issue. True, there are some non-operational facets to the issue, but that is not sufficient to call this off-topic... I can think of no better place than NANOG to say "Hey, some of you still have not updated your filters, I still do not have the reachability I should have.". His problem is indicative of future problems to come as we expand the use of previously unallocated IPv4 space. If the community cannot solve his problem, what reachability assurance do we have on any future allocations out of spaces with a similar history? James H. Smith II NNCSE NNCDS Senior Systems Engineer First Call Response Center The Presidio Corporation -----Original Message----- From: Michael.Dillon(a)radianz.com [mailto:Michael.Dillon@radianz.com] Sent: Friday, December 06, 2002 11:57 AM To: nanog(a)merit.edu Subject: Re: Operational Issues with 69.0.0.0/8... > My question is as follows - We are losing customers because of this > problem. It is costing us reputation and money. It is out of our > control. If you were us, what would you do? We have already asked ARIN > to reassign us to a "friendlier" CIDR, and they refuse. This is no longer a technical operational issue so it is out of scope for this mailing list. But if you think that ARIN could do something to solve your problem then you should raise the issue on the ARIN public policy mailing list. You can find subscription information for that list here http://www.arin.net/mailing_lists/index.html -- Michael Dillon

2 1

RE: Operational Issues with 69.0.0.0/8...
by Randy Bush 06 Dec '02

06 Dec '02

> This type of problem is likely to spur interest in more regional > registries. There's been talk of CIRA seting up a Canadian IP there already has been a canadian ip address registry. there no longer is. learn from history. randy

1 0

RE: Operational Issues with 69.0.0.0/8...
by Kris Foster 06 Dec '02

06 Dec '02

> > How would more registries help? It would just add more > voices, not the > > number of ears listening.. > > Canadians have a lot more influence on CIRA than on ARIN. Without the pressure from operators assigned out of new space no action would take place. If it was possible to return a block for a new one, there's only so much address space that a RIR could possibly hand out, we'll still come back to the problem of routing new blocks. Kris

1 0

RE: Operational Issues with 69.0.0.0/8...
by Kris Foster 06 Dec '02

06 Dec '02

> This type of problem is likely to spur interest in more regional > registries. There's been talk of CIRA seting up a Canadian IP How would more registries help? It would just add more voices, not the number of ears listening.. Kris

2 1

Microsoft DNS Outage?
by william＠elan.net 06 Dec '02

06 Dec '02

Looks like microsoft is having dns outage.. Anybody else seeing this or is it only me? [william@sokol william]$ whois microsoft.com(a)completewhois.com | more [whois.crsnic.net] Domain names in the .com, .net, and .org domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. Domain Name: MICROSOFT.COM Registrar: NETWORK SOLUTIONS, INC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com Name Server[with whois ip]: DNS1.CP.MSFT.NET 207.46.138.20 Name Server[with whois ip]: DNS1.TK.MSFT.NET 207.46.245.230 Name Server[with whois ip]: DNS3.UK.MSFT.NET 213.199.144.151 Name Server[with whois ip]: DNS3.JP.MSFT.NET 207.46.72.123 Name Server[with whois ip]: DNS1.DC.MSFT.NET 207.68.128.151 Name Server[with whois ip]: DNS1.SJ.MSFT.NET 65.54.248.222 Updated Date: 07-jun-2002 .... [william@sokol william]$ nslookup Default Server: dns1.elan.net Address: 216.151.192.1 > server 207.46.138.20 Default Server: [207.46.138.20] Address: 207.46.138.20 > www.microsoft.com Server: [207.46.138.20] Address: 207.46.138.20 *** [207.46.138.20] can't find www.microsoft.com: Server failed > server 207.46.245.230 Default Server: dns1.tk.msft.net Address: 207.46.245.230 > www.microsoft.com Server: dns1.tk.msft.net Address: 207.46.245.230 *** dns1.tk.msft.net can't find www.microsoft.com: Server failed > server 213.199.144.151 Default Server: dns3.uk.msft.net Address: 213.199.144.151 > www.microsoft.com Server: dns3.uk.msft.net Address: 213.199.144.151 *** dns3.uk.msft.net can't find www.microsoft.com: Server failed > exit [william@sokol william] date [Fri Dec 6 01:18:00 PST 2002 [william@sokol william]$ nslookup Default Server: dns1.elan.net Address: 216.151.192.1 > server 207.46.72.123 Default Server: dns3jp.msft.net Address: 207.46.72.123 > www.microsoft.com Server: dns3jp.msft.net Address: 207.46.72.123 *** dns3jp.msft.net can't find www.microsoft.com: Server failed > server 207.68.128.151 Default Server: dns1.dc.msft.net Address: 207.68.128.151 > www.microsoft.com Server: dns1.dc.msft.net Address: 207.68.128.151 *** dns1.dc.msft.net can't find www.microsoft.com: Server failed > server 65.54.248.222 > server 65.54.248.222 Authoritative answers can be found from: 248.54.65.in-addr.arpa nameserver = ns1.hotmail.com 248.54.65.in-addr.arpa nameserver = ns2.hotmail.com 248.54.65.in-addr.arpa nameserver = ns3.hotmail.com 248.54.65.in-addr.arpa nameserver = ns4.hotmail.com 248.54.65.in-addr.arpa nameserver = tuk1-dns-1.sea.msnglobal.net 248.54.65.in-addr.arpa nameserver = tuk2-dns-1.sea.msnglobal.net Default Server: [65.54.248.222] Address: 65.54.248.222 > www.microsoft.com Server: [65.54.248.222] Address: 65.54.248.222 *** [65.54.248.222] can't find www.microsoft.com: Server failed > exit

1 1

Re: Operational Issues with 69.0.0.0/8...
by Michael.Dillon＠radianz.com 06 Dec '02

06 Dec '02

>> My question is as follows - We are losing customers because of this >> problem. It is costing us reputation and money. It is out of our >> control. If you were us, what would you do? We have already asked >> ARIN >> to reassign us to a "friendlier" CIDR, and they refuse. >ARIN don't guarantee routability of the blocks they allocate, and it's >difficult to see how they ever could. If you want to discuss what ARIN could or could not do, then please join the ARIN ppml list. > Perhaps this is an issue of community education, or one of needing > better tools or methods for managing martian filters. Those issues are > arguably both technical and operational. The original poster doesn't have a problem with the community. He has a problem with network operators who are not part of the community and that is a reality of today's Internet that cannot be dealt with by technical tools or operational methods. But there are non-technical and non-operational actions actions that ARIN could take to help. The details of those actions and whether or not ARIN members want to act are matters for the ppml list. --Michael Dillon

5 4

RE: Operational Issues with 69.0.0.0/8...
by Todd A. Blank 06 Dec '02

06 Dec '02

Thanks for all of the suggestions we have received. If I had only known that talking about ARIN on NANOG was the hot button, I would have pressed it a long time ago :-) I do have some operational factoids to add - my prior post was incomplete. We are multi-homed in a carrier neutral data center. It is imperative that we have our own IP. I do have some small bits of CIDR from other ISPs and have already migrated some of the problem customers to other blocks, but I am not meeting my SLAs with those customers, because we guarantee multiple paths. On IP that belongs to an upstream of ours, traffic only comes inbound through that upstream. That is a problem. Sorry if talking about ARIN is off the topic of this list, but the 69/8 CIDR is "broken" (in customer terms) in lots of places on the internet. ARIN is the one assigning it. If they keep assigning it before everyone's access policies recognize it as valid, this "non-operational" issue is going to cost a lot of people a lot of money in wasted time, effort and resources. I know it has been very painful for us. -----Original Message----- From: Todd A. Blank Sent: Friday, December 06, 2002 10:23 AM To: nanog(a)merit.edu Subject: Re: Operational Issues with 69.0.0.0/8... The list of inaccessible sites continues to grow: Add to the list www.oandp.com - that looks like someone's firewall filtering in front of their DNS server, because we can't even resolve the DNS. We still can't get to www.ocas.com, www.lavalife.com, and www.indofilms.com even after calling and posting repeatedly. There are undoubtedly others out there. Repeated problems posted by myself and others show the extent of the problem with the 69.0.0.0/8 CIDR, and its lack of dependability - it's a human thing. It used to be restricted, so there are a lot of access lists out there - with all the stuff going on in the last year or so, half the people blocking it probably don't even know how to unblock it - i.e. that person no longer works here... If you look at the address space on IANA, http://www.iana.org/assignments/ipv4-address-space you will see that the last CIDR ARIN took before 69/8 was over a year prior to the 69/8 assignment. A lot happened in our industry in that year. Somewhere, this process is broken since the last CIDR was assigned to ARIN. My question is as follows - We are losing customers because of this problem. It is costing us reputation and money. It is out of our control. If you were us, what would you do? We have already asked ARIN to reassign us to a "friendlier" CIDR, and they refuse. Suggestions are welcome. Sincerely, Todd A. Blank CTO IPOutlet LLC 614.207.5853

1 0