Move all 9-1-1 to 8-5-5

Whenever the North American Numbering Planning Administration releases a
new toll-free prefix (e.g. 1-800, 1-888, 1-877, 1-866) there is always a
lengthy delay for individuals operating some telephone switches to update
their routing tables. Its common to be in hotels, and find the hotel PBX
doesn't recognize a recent toll-free prefix.

So to "fix" this problem, why don't we move all 9-1-1 numbers to the new
toll-free prefix, which will break stuff for people who don't update their
PBX's promptly. When they find out they can't report a fire in the hotel
because their PBX is blocking the new prefix, then they'll fix the PBX.

Let's get real, no one is going to break any "critical" resource just for
the purpose of making people fix their systems.

Rob's bogon lists are good, but unless you have the processes in place to
keep it update to date (or hire an consulting firm to do it for you), its
about as useful as putting a list of "invalid" phone numbers in your PBX.
The lists change all the time, and unless you are a full-time LERG expert,
it will probably get quickly out of date.

Of course, we can always use LDAP to keep all the PBX's updated.

Forgive the intrusion...

We have a customer who uses some merchant services off of 208.196.93.204, which seems to be unreachable via any location I try. Emails to UUnet's NOC are unaswered and the guy I talked to on the phone @ UU wouldn't open a ticket because I'm not a customer (but his traces were dying in the same place as mine:

207.ATM6-0.GW11.NYC1.ALTER.NET (152.63.29.185))

Can anybody out there hit that IP (208.196.93.204) at the moment? Or indeed much of anything in that /8?

Forgive the intrusion...

We have a customer who uses some merchant services off of
208.196.93.204, which seems to be unreachable via any location I try.
Emails to UUnet's NOC are unaswered and the guy I talked to on the
phone @ UU wouldn't open a ticket because I'm not a customer (but his
traces were dying in the same place as mine:

traceroutes often die when there are firewalls and/or router acls

207.ATM6-0.GW11.NYC1.ALTER.NET (152.63.29.185))

Can anybody out there hit that IP (208.196.93.204) at the moment? Or
indeed much of anything in that /8?

the /8 is kinda large for me to test 'right now' but this one /32 looks
ok:

xxx.corp.us.uu.net:t 208.196.93.204 80
Trying 208.196.93.204...
Connected to 208.196.93.204 (208.196.93.204).
Escape character is '^]'.

That seems to be a good port 80 connection. route-server.ip.att.net shows
this prefix as:

BGP routing table entry for 208.196.93.0/24, version 107200
Paths: (19 available, best #19, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  12.161.130.230
  7018 701 14462, (received & used)

Have you bothered to call ASN 14462 ?

arin 14462

OrgName: EVS Holding Company, Inc.
OrgID: EHC-8
Address: 1415 RT 70, Suite 620
City: Cherry Hill
StateProv: NJ
PostalCode: 08034
Country: US

ASNumber: 14462
ASName: CYSHOP-COMMERCE
ASHandle: AS14462
Comment:
RegDate: 1999-12-16
Updated: 1999-12-16

TechHandle: MB745-ARIN
TechName: Byrnes, Michael
TechPhone: +1-856-429-9249
TechEmail: mikeb@cyshop.com

Perhaps Michael Byrnes is lurking and can help you?

OK... so I'm an idiot... end of a long day, apologies. The /8 was a jump to a bonehead conclusion on my part. The /24 & IP in question remains unreachable on any port from here, but I did get enough offlist clueXfours to follow up offlist and soothe our client for the time being.

Thanks folks,

You're comparing two different situations, though:
In your case, the people in the hotel that is doing the blocking will be the
ones experiencing the problems. They notice that they can't reach
1-8xx-xxx-xxxx, so they call up the hotel management and yell. Hotel
management calls the person in charge of their PBX, and the problem would be
fixed. I could be wrong (hey, I'm in the DNS business, not the PSTN), but I
can't imagine the 1-8xx number calling the hotel and getting the impression
that the 1-8xx number's provider has problems...
In the 69.0.0.0/8 case, though, the problem is bidirectional. You have
people whose ISP/firewall/etc blocks access to 69.0.0.0/8 - presumably, if
they can't reach some box on 69.0.0.0, they'll yell at their ISP (and, most
likely, at the operator of the thing they're trying to reach, too, but said
operator can tell them to yell at their ISP). But, you also have people on
69.0.0.0 who aren't able to reach other sites due to filtering on the other
end, and those people are likely to yell at their ISP and blame their ISP
for something the ISP can't fix.
That second situation, I think, is the situation that this thread is about,
and your hotel analogy doesn't address that.

With the hotel analogy, basically, the people affected are the ones who have
the relationship with the operator of the broken piece of hardware, not the
ones with the 1-8xx number (though, if you want to be picky, you could argue
they might lose a bit of business to this).
With the 69.x.x.x situation, the people affected are the ones with the 69 IP
space, and they don't have a relationship with whoever has the misconfigured
hardware.

Maybe moving the GTLD servers would be overkill... But certainly, the idea
of asking Google or Yahoo to move seems like a good one. If people can't
reach Google or Yahoo, they'll make their ISP look into the issue, and fix
their filters.

A random comment now I have been dragged into this thread: this issue is not
new with 69.0.0.0/8. When we first got a block from 66.* from an ISP about
two years ago, we had problems too with various people (mostly end users,
though, I think) firewalling 66.*, and yet ARIN had been assigning 66.*
blocks for probably a year or so before we got that IP space. Fortunately
for us, though, most problems seemed to be people who wanted to reach us not
being able to, and not us not being able to reach sites we wanted to talk
to. Still, I suspect the Linux Firewall HOWTO was in large part responsible
for the problems we had...

Vivien