RE: Gender and other protocol issues
Speaking of Gender and Protocol, I think this whole gender bias thing can be solved by implementing an LDAP server Sorry - wrong thread... -Original Message- From: Cutler, James R [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 10:44 PM To: [EMAIL PROTECTED] Subject: Gender and other protocol issues A famous Internet personality is alleged to have said, approximately, Be liberal in what you accept. Be exact in what you emit. 'Seems like this continues to be sound advice. :-) JimC
RE: Put part of Google on 69/8 (was Re: 69/8...this sucks)
Wanting to continue to be a part of the solution, and not part of the problem, I just want to post publicly to the list that we would gladly donate some IP space from our ARIN direct assignment (which lives in the 69/8 CIDR) to the cause. If anyone is interested, please contact me off list. Sincerely, Todd A. Blank CTO IPOutlet LLC 614.207.5853 -Original Message- From: McBurnett, Jim [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 8:00 PM To: JC Dill; [EMAIL PROTECTED] Subject: RE: Put part of Google on 69/8 (was Re: 69/8...this sucks) Idea #2.. CNN.com-- Put some of their content.. They would probrably really enjoy the publicity.. And that would really be an educational point.. Anybody here from there??? Jim The suggestion of putting Yahoo or Google on a 69/8 IP led me to this idea: Google could put their *beta* sites on a 69/8 IP, without causing them (Google) much Internet reachability/connectivity harm, and benefiting the Internet at large considerably. Set up a page (hopefully linked from www.google.com) that lists all of Google's present beta sites.
RE: 69/8...this sucks -- Centralizing filtering..
I continue to agree that moving critical resources (see below) to these new blocks is the best approach I have seen or heard in the months since I made the original post. This approach punishes the clueless instead of the people that already know what the problem is (and have to live with it every day). I can't begin to calculate the amount of support time we have burned contacting the offending networks. I know the cost has been prohibitive at best. I have seen this suggestion once before (maybe even by Jon) and I still think it is the best way things will get resolved quickly. Maybe we should suggest that ARIN also host some of their stuff on this block :-) Todd IPOutlet LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 12:52 PM To: E.B. Dreger Cc: [EMAIL PROTECTED] Subject: RE: 69/8...this sucks -- Centralizing filtering.. On Mon, 10 Mar 2003, E.B. Dreger wrote: Now, how can we force that? Sufficient reward for doing so, or pain for failure. Evidently some people can't reach you isn't enough pain, and having full reachability isn't enough reward. I think the only way that's relatively guaranteed to be effective is to move a critical resource (like the gtld-servers) into new IP blocks when previously reserved blocks are assigned to RIR's. I still have a couple hundred thousand IPs to check (I'm going to step up the pace and see if I can get through the list today), but I already have a list of several hundred IPs in networks that ignore 69/8. The list includes such networks as NASA, the US DoD, and networks in China, Russia, and Poland. Those are just a few that I've done manual whois's for. I haven't decided yet whether I'll send automated messages to all the broken networks and give them time to respond and fix their filters, or just post them all to NANOG when the list is complete. Are people interested in seeing the full list (at least the ones I find) of networks that filter 69/8? Does Atlantic.Net get an ARIN discount for doing all this leg work? :) -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: 69.0.0.0/8 - Please update your filters
We were an early user of the 69/8 address space. I started the original thread on this subject back in Sept/Oct 2002. While I am very disturbed (but not surprised) to find out that there are still serious issues with networks acknowledging this allocation, this is one of the best suggestions I have seen for doing something to force the issue. Todd A. Blank IPOutlet LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 25, 2003 9:32 PM To: Haesu Cc: Stephen Sprunk; E.B. Dreger; North American Noise and Off-topic Gripes Subject: Re: 69.0.0.0/8 - Please update your filters On Tue, 25 Feb 2003, Haesu wrote: And how quickly would those ASN's respond to or even comprehend the bogon-filter update notices? If those ASN's are competent and quick-responsive ones, we should not even be having these prroblems to begin with. If the alternative is getting space, giving it to customers, and explaining why they can't reach X, Y, and Z on their connection to us, but they can on other internet connections, we're going to at least have to try. I like the idea of moving the gtld servers into such space. That way, the networks that are at fault will break, and they'll be well motivated to fix their filters. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: 69.0.0.0/8 - Please update your filters
In my original thread, I referred to the orphaned equipment in use in many networks. I am sure it does not help when organizations have massive layoffs and the people that put these filters in place or originally managed the offending devices are no longer employed by the organization in question. As once told to me by a prior employer of mine (right before he eliminated my job): After all, once the network is up and running, who needs all those extra people to manage it? :-) Todd -Original Message- From: Sameer R. Manek [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 10:58 AM To: Todd A. Blank; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: 69.0.0.0/8 - Please update your filters -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Todd A. Blank We were an early user of the 69/8 address space. I started the original thread on this subject back in Sept/Oct 2002. While I am very disturbed (but not surprised) to find out that there are still serious issues with networks acknowledging this allocation, this is one of the best suggestions I have seen for doing something to force the issue. Filters once in place are rarely removed, unless the maintainers of the filters are notified about a specific problem. Even then the filters never completely go away. There is always a device or two in everyone's network that have been forgotten about, with outdated filters. Sameer
RE: Dropouts since Saturday 1/25/03 only affecting web traffic?
I am seeing this as well, but only from a few hosts on a single network. I have contacted their NOC and asked them to knock it off - no pun intended... Could be some nimda infected boxes or whatever. Firewalls are stopping it, but it is annoying to wade through the logs. Todd -Original Message- From: Al Rowland [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 10:31 AM To: [EMAIL PROTECTED] Subject: RE: Dropouts since Saturday 1/25/03 only affecting web traffic? A single point of consumer data. I haven't checked by home router logs since Monday night but I was seeing a pattern of significant incoming port 80 traffic (I'm not running any services) over the last week or so, similar to increased 1433/1434 traffic before Saturday's flurry. Best regards, __ Al Rowland -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Sean Donelan Sent: Tuesday, January 28, 2003 9:46 PM To: [EMAIL PROTECTED] Subject: Dropouts since Saturday 1/25/03 only affecting web traffic? According to Matrix Systems (http://average.miq.net/Weekly/markR.html) there have been two additional dropouts of global Web reachability on January 26 and January 28. These dropouts have been for few hours or so, but nearly as large as we saw from the SQL worm. However it doesn't seem to affect other network services, as measured by Matrix. Just the measured web servers. The most recent was tonight from 3-5pm and again from 5-7pm EST (http://average.miq.net/) Any ideas what is causing them? Measurement artifact? Are you seeing something strange on your networks about that time?
RE: Aggregate traffic management
We are a RouteScience customer. We are using this box and it rules. We have been extremely happy with the results. We have multiple OC-x circuits that we are engineering traffic over, and this box gives us the ability to see things that we could not see before. It also really allows us to differentiate our upstream providers - or tell that they are really all the same. The reports it produces are excellent. We have even used it to negotiate better SLAs and pricing with our bandwidth providers. Feel free to email me off-list if you want more information. Sincerely, Todd A. Blank IPOutlet LLC -Original Message- From: Kyle C. Bacon [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 5:43 PM To: Stanislav Rost Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Aggregate traffic management Take a look at a product called Path Control by RouteScience. http://www.routescience.com/ I have seen their product in action and it is very slick. Does exactly what you want, plus a whole lot more and does it transparently (so if it fails you aren't SOL) via manipulating BGP tables and nexthop based on a multitude of criteria. K Stanislav Rost To: [EMAIL PROTECTED] stanrost@lcscc: .mit.eduSubject: Aggregate traffic management Sent by: owner-nanog@m erit.edu 01/28/2003 04:59 PM Dear NANOGers, I have a very hands-on question: Suppose I am a network operator for a decent-sized ISP, and I decide that I want to divide aggregate traffic flowing through a router toward some destination, in order to then send some of it through one route and the remainder through another route. Thus, I desire to enforce some traffic engineering decision. How would I be able to accomplish this division? What technologies (even if vendor-specific) would I use? I can think of some methods like prefix-matching classification and ECMP, but I am still not sure exactly how the latter works in practice (at the router level) and how one may set them up to achieve such load-sharing. Thank you for your expertise and lore, -- Stanislav Rost [EMAIL PROTECTED] Laboratory for Computer Science, MIT
RE: Operational Issues with 69.0.0.0/8 - or, does the Army read NANOG posts?
Yes, but can you help us get it fixed, since you know about their inner workings? This is continually using valuable resources of ours and the others out there that have been kind enough to help. New sites are hitting the inaccessible list every day. I try to post only sites like this one, or ones that seem to have a common thread between them - i.e. they use the same transit... This is why we posted to NANOG for help - in the hopes that someone somewhere in the community is either involved or knows people involved with these networks. Todd -Original Message- From: Brad Knowles [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 5:11 AM To: Todd A. Blank Subject: Re: Operational Issues with 69.0.0.0/8 - or, does the Army read NANOG posts? At 8:05 PM -0500 on 2002/12/10, you wrote: Another site that is filtering 69.0.0.0/8: www.army.mil If anybody has any way to reach anyone responsible for this, or if the people who run this site are reading this, PLEASE STOP THE MADNESS! The US military is well-known for firewalling all non-US IP addresses around the world. This makes it kind of hard for people in NATO (served by Belgacom Skynet, and issued IP space from them) to contact people in the US military. This is one of those standard Oops situations that periodically crops up whenever they get some new 16 year-old firewall operator that doesn't understand why the moron before him had a non-US IP address in the allowed list, and promptly decides to remove it without checking with anyone. Doing martian filtering for 69/8 is nothing compared to the kind of stupidity we see from them on a regular basis. I say this as a former DISA.MIL Technical POC, so I have seen the kind of stupid stuff they do, first-hand and from the inside. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
RE: FW: /8s and filtering
Thank you! I thought that was the whole point of CIDR... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 4:54 PM To: Harsha Narayan Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: FW: /8s and filtering but there is no class C space anymore. there is no class A space either. its all CIDR space and some providers have retained some vestigal classfull concepts in the creation/maintaince of their routing filters. a /24 may or may not get you past my filters. any you'll have no way to know until/unless you try to get to my sites or we develop a peering relationship. wrt the evolution of filters. yes, they do evolve. and so does ARIN policy. you presume too much to second guess that ARIN policy will evolve in the way you outline. Hello, Thank you very much everyone for all your replies. When Class C space gets used up, wouldn't the filtering policies have to change to allow the same kind of multihoming from the Class A space. Currently, a /24 from Class C is enough to get past filters. However later, a /22 (or is it /20) from Class A would be required to get past filters. Since there are only three /8s left in Class C, I was curious whether filtering policies would change to accommodate this. If filtering policies won't change ARIN will have to change its multihoming PA policy to giving away a /22 instead of a /24. Though officially it is RIR policy not to worry about the routability of an a prefix I guess they do worry about it? Thanks, Harsha. On Tue, 10 Dec 2002 [EMAIL PROTECTED] wrote: Hello, Now I am confused because I have got two sets of contradicting answers. Some say that anyone can multihome, some say that you need to be of a certain minimum size to multihome. May I know what is the right answer? I agree that allowing anyone to multihome would increase the size of the routing table. So does this mean that someone has to be of a certain size to multihome? Harsha. anyone can multihome, with the cooperation of others. current practice seems to dictate that the standard operating procedures to protect the integrity of the routing system mandate that only prefixes of certain lengths are allowed at -SOME- isp boundaries. you seem to have the assumption that there is a single standard here. There is not. --bill
Re: Operational Issues with 69.0.0.0/8 - or, does the Army read NANOG posts?
Another site that is filtering 69.0.0.0/8: www.army.mil If anybody has any way to reach anyone responsible for this, or if the people who run this site are reading this, PLEASE STOP THE MADNESS! Sincerely, Todd A. Blank 614.207.5853
Re: Operational Issues with 69.0.0.0/8...
Hello Everyone, I appreciate all of the discussion regarding this issue. Nothing has changed. This is getting worse. We spoke to one network on Friday that said they had cleared the problem, yet our users still can't go there. For those of you that feel this is not anyone's problem, and that the internet should just work it out; I hereby challenge one of you to trade CIDRs with us. You take this 69.1.192.0/19 ARIN assigned us and you go spend your valuable time, resources, and money working out what seems to be nobody's problem. Also, if you would like to come over and answer the support calls and explain to our customers why the competitor's networks can reach these sites, but ours can't. Hey - after all, it's just CIDR - it's all the same, right? Some of you have accused others of being too lazy to call the networks that don't work - I assure all of you we have called the ones we know of - over and over. They still don't work. Some of you have suggested that all we need to do is talk to people. We have been calling and talking for a months (almost three to be exact), and the list of inaccessible sites continues to grow. We have called and talked until we are blue in the face. What all of you don't know, is that for the first month we had this CIDR, we could not register hosts on it at NetSol/Verisign, because their core registry did not recognize it. We have been getting F***ed by this CIDR since day one. We have only been successful with two networks in getting filters removed. How many more are out there? I think we can all agree that whoever's responsibility it is, the current system is broken. You can't actually count on people to read this list. Maybe if IANA and ARIN and the other organizations that are supposed to work together to make all this stuff work weren't so busy trying to pass the buck, someone might have time to figure something out... Somebody out there has to have a spare /19 lying around :-) You know - the good old IP numbers like the ones I used to get - they actually worked ;-) What we do know is that the number ARIN took from us sure worked for them. Do you think they would be calling us if their bank suddenly told them that even though they had delivered IP Addresses to us, they could not receive our 3,000.00 dollars because it originated from a bank that has a previously restricted routing code? Todd
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
RE: Operational Issues with 69.0.0.0/8...
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: [EMAIL PROTECTED] 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
RE: Operational Issues with 69.0.0.0/8...
Some of this is beginning to clear up. The Cable and Wireless stuff
seems to be working now.
Still, when we source from the 69.0.0.0/8 CIDR, traffic can't go (http)
to the following destinations:
www.ocas.com
www.lavalife.com
www.indofilms.com
The first two are on ATT and ATT Canada. The last one is on
allegiance internet.
Any insight would be much appreciated. We are sure this is affecting
access to other destinations when using 69.0.0.0/8 as a source - we just
haven't found them all yet...
Thanks,
Todd A. Blank
614.207.5853
-Original Message-
From: Martin J. Levy [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 02, 2002 2:17 PM
To: Todd A. Blank; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Operational Issues with 69.0.0.0/8...
Todd,
If this helps. Do something like the following...
telnet route-views.oregon-ix.net /tmp/file
term len 0
sh ip bgp 69.0.0.0 255.0.0.0 l
quit
cut -c62-2000 /tmp/file | awk '{print $1}' | sort -n | uniq -c
| more
...your commands will vary.
You will see plenty of routes within 69/8.
A closer look with show that around 121 routes are seen in the 69/8
range via most of the feeds into Oregon. There is one big exception...
69.4.64.0/20
... it shows up via AS-2548 (Digex) and the other feeds, but it's the
only route within 69/8 that shows up via AS-2548. This is valuable
information.
It does not mean there is filtering within AS-2548, but I would
recommend you contact them to further this investigation.
BTW: This is exactly what Oregon is great for! It shows up issues like
this with ease. Thanks!
Martin
---
At 01:47 PM 12/2/2002 -0500, Todd A. Blank wrote:
Thanks for the reply, James.
I wish I could tell you the answer. We see traffic passing through
some
of the routers (transit), but on each network, or their downstreams
there seem to be different devices filtering. Sometimes it is a border
or peering router. In other cases, it has been access devices, such as
firewalls.
One we resolved this morning (with some help from the good folks at
ARIN) was a downstream provider from one of these transit providers
that
was filtering in their devices as well.
I am just trying to raise general awareness that the 69.0.0.0/8 block
is
assigned and out there in use, and to get people to re-examine their
filters, access lists, etc.
You help and response is appreciated.
Sincerely,
Todd A. Blank
614.207.5853
-Original Message-
From: Feger, James [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 02, 2002 1:35 PM
To: Todd A. Blank
Subject: Re: Operational Issues with 69.0.0.0/8...
When you say 'Networks involved' do you mean those providers are
blocking
the traffic, or you see these networks in the transit?
Thanks,
James
On Mon, 2 Dec 2002, Todd A. Blank wrote:
To all concerned:
We have been assigned a CIDR of 69.1.192.0/19.
We have had numerous problems getting traffic through to various
destinations.
We are finding that many routers are still filtering 69.0.0.0/8.
This block used to be restricted, but was assigned by IANA to ARIN in
August of 2002.
If anyone is still filtering this block in their routers, please
remove the filters!
Here are some of the destinations that are not reachable if your
source is anywhere in the 69.0.0.0/8 CIDR:
www.cplink2.com
www.ocas.com
www.indofilms.com
www.lavalife.com
Some of the Networks involved are Cable and Wireless, Allegiance
Internet and ATT.
Thank you,
Todd A. Blank
IPOutlet LLC
614.207.5853
Operational Issues with 69.0.0.0/8...
Thanks for the reply, James. I wish I could tell you the answer. We see traffic passing through some of the routers (transit), but on each network, or their downstreams there seem to be different devices filtering. Sometimes it is a border or peering router. In other cases, it has been access devices, such as firewalls. One we resolved this morning (with some help from the good folks at ARIN) was a downstream provider from one of these transit providers that was filtering in their devices as well. I am just trying to raise general awareness that the 69.0.0.0/8 block is assigned and out there in use, and to get people to re-examine their filters, access lists, etc. You help and response is appreciated. Sincerely, Todd A. Blank 614.207.5853 -Original Message- From: Feger, James [mailto:[EMAIL PROTECTED]] Sent: Monday, December 02, 2002 1:35 PM To: Todd A. Blank Subject: Re: Operational Issues with 69.0.0.0/8... When you say 'Networks involved' do you mean those providers are blocking the traffic, or you see these networks in the transit? Thanks, James On Mon, 2 Dec 2002, Todd A. Blank wrote: To all concerned: We have been assigned a CIDR of 69.1.192.0/19. We have had numerous problems getting traffic through to various destinations. We are finding that many routers are still filtering 69.0.0.0/8. This block used to be restricted, but was assigned by IANA to ARIN in August of 2002. If anyone is still filtering this block in their routers, please remove the filters! Here are some of the destinations that are not reachable if your source is anywhere in the 69.0.0.0/8 CIDR: www.cplink2.com www.ocas.com www.indofilms.com www.lavalife.com Some of the Networks involved are Cable and Wireless, Allegiance Internet and ATT. Thank you, Todd A. Blank IPOutlet LLC 614.207.5853
RE: Operational Issues with 69.0.0.0/8...
We feel your pain, Scott. We are just glad that we are able to verify that there are problems with this CIDR other than on our network. Now to get them resolved. Hopefully this conversation will end up in the proper inboxes to help clean this up. Does anyone besides me worry that because of the recent cutbacks in this industry that there are orphaned pieces of equipment out there causing some of these problems? Todd 614.207.5853 -Original Message- From: Scott Granados [mailto:[EMAIL PROTECTED]] Sent: Monday, December 02, 2002 1:52 PM To: Todd A. Blank Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Operational Issues with 69.0.0.0/8... I'd like to second this. We have ran in to problems as well. Usually this is a great place to get help however we have had very responsive actions taken by others out there who had filters in place. On Mon, 2 Dec 2002, Todd A. Blank wrote: Thanks for the reply, James. I wish I could tell you the answer. We see traffic passing through some of the routers (transit), but on each network, or their downstreams there seem to be different devices filtering. Sometimes it is a border or peering router. In other cases, it has been access devices, such as firewalls. One we resolved this morning (with some help from the good folks at ARIN) was a downstream provider from one of these transit providers that was filtering in their devices as well. I am just trying to raise general awareness that the 69.0.0.0/8 block is assigned and out there in use, and to get people to re-examine their filters, access lists, etc. You help and response is appreciated. Sincerely, Todd A. Blank 614.207.5853 -Original Message- From: Feger, James [mailto:[EMAIL PROTECTED]] Sent: Monday, December 02, 2002 1:35 PM To: Todd A. Blank Subject: Re: Operational Issues with 69.0.0.0/8... When you say 'Networks involved' do you mean those providers are blocking the traffic, or you see these networks in the transit? Thanks, James On Mon, 2 Dec 2002, Todd A. Blank wrote: To all concerned: We have been assigned a CIDR of 69.1.192.0/19. We have had numerous problems getting traffic through to various destinations. We are finding that many routers are still filtering 69.0.0.0/8. This block used to be restricted, but was assigned by IANA to ARIN in August of 2002. If anyone is still filtering this block in their routers, please remove the filters! Here are some of the destinations that are not reachable if your source is anywhere in the 69.0.0.0/8 CIDR: www.cplink2.com www.ocas.com www.indofilms.com www.lavalife.com Some of the Networks involved are Cable and Wireless, Allegiance Internet and ATT. Thank you, Todd A. Blank IPOutlet LLC 614.207.5853
