Verio is one of the remaining providers that performs filtering. These filters currently extend out to/22. You can view their peer filtering policy here
We have a few things that happened here I believe.
Denial of service attacks lead the reason people would filter out 'unallocated' space. A bunch of people just used rand() to generate fake source IPs to DoS from. Dropping from unallocated or unrouted space has become commonplace as it can prevent that extra little bit of packets from reaching your firewall/router/end host. It can make the difference for some people being able to survive an attack and not.
The "dot com" bubble that burst created a lot of devices that used to be cared about deeply and now are ignored by the suits as the network is too stable and runs itself. This is both good and bad. As the network becomes more reliable more people start using VoIP and other technologies that reduce costs. Problem is this ends up causing jobs to be lost. (VoIP aside, if you take 250mil phone calls all going on at the same time, using 64k per call, you've got ~16Gb/s of traffic. Most of the international backbones can easily handle this traffic. What does this mean for the existing PSTN networks once the IP networks are more reliable.)
People are just busy. I know that I sometimes lag in updating software on my systems unless it's necessary. Imagine the people who think "hey, i need to update these filters" but never get around to it.
puck is handling the load quite nicely, but thanks for the offer. make sure you check out the atlantic.net split-screen traceroute tool. It's quite cool.
This is actually how SIP ends up communicating. I have set up a number of the Cisco 7960 phones running SIP software and what acutally happens is this:
Message sent to central sip server saying 'where is ext 1000' (or whatever number you dial). Sip server comes back and can say 'no idea where that is', or provide a referal to another ip/dns name. The underlying request can look like 267@204.42.254.14 or 90753@iptel.org for example. Once it finds a positive answer for the lookup, it uses information contained in the SDP packet to determine what udp ports to talk on and the phone(hard or soft) communicates directly to the other phone. The central server is kept in the loop for call-completion (billing) data. But you could just 'dial by ip'. If you know that 267 is assigned to 204.42.254.14, you can communicate directly and the phone will ring.
I suspect a number of the hard phone people will soon be providing a VPN/ipsec type client on the actual phone as SIP does not work very well in a firewall/nat environment.
Slashdot Mirror
"You've got Certified Mail"
Verio is one of the remaining providers that performs filtering. These filters currently extend out to /22. You can view their peer filtering policy here
We have a few things that happened here I believe. Denial of service attacks lead the reason people would filter out 'unallocated' space. A bunch of people just used rand() to generate fake source IPs to DoS from. Dropping from unallocated or unrouted space has become commonplace as it can prevent that extra little bit of packets from reaching your firewall/router/end host. It can make the difference for some people being able to survive an attack and not. The "dot com" bubble that burst created a lot of devices that used to be cared about deeply and now are ignored by the suits as the network is too stable and runs itself. This is both good and bad. As the network becomes more reliable more people start using VoIP and other technologies that reduce costs. Problem is this ends up causing jobs to be lost. (VoIP aside, if you take 250mil phone calls all going on at the same time, using 64k per call, you've got ~16Gb/s of traffic. Most of the international backbones can easily handle this traffic. What does this mean for the existing PSTN networks once the IP networks are more reliable.) People are just busy. I know that I sometimes lag in updating software on my systems unless it's necessary. Imagine the people who think "hey, i need to update these filters" but never get around to it.
puck is handling the load quite nicely, but thanks for the offer. make sure you check out the atlantic.net split-screen traceroute tool. It's quite cool.
This is actually how SIP ends up communicating. I have set up a number of the Cisco 7960 phones running SIP software and what acutally happens is this:
Message sent to central sip server saying 'where is ext 1000'
(or whatever number you dial). Sip server comes back and can say 'no idea where that is', or provide a referal to another ip/dns name. The underlying request can look like 267@204.42.254.14 or 90753@iptel.org for example. Once it finds a positive answer for the lookup, it uses information contained in the SDP packet to determine what udp ports to talk on and the phone(hard or soft) communicates directly to the other phone. The central server is kept in the loop for call-completion (billing) data. But you could just 'dial by ip'. If you know that 267 is assigned to 204.42.254.14, you can communicate directly and the phone will ring.
I suspect a number of the hard phone people will soon be providing a VPN/ipsec type client on the actual phone as SIP does not work very well in a firewall/nat environment.