On 22/01/2010 05:07, Jim Mercer wrote:
i'm doing some consulting work for a cable operator in Pakistan.
while i'm guessing that realistically we will be approaching RIPE for address
space, i'm just wandering what happened to 24.0.0.0/8 and what policies
govern who and what can use the
We had some problems with them too between their NYC and Sunnyvale pops
from Jan 21 1000h UTC to 1700h UTC. Edge began dropping packets. No RFO
as of yet.
On Friday, 22 January, 2010 01:58 AM, Hans Goes wrote:
Just wondering if other people on this list experience similar problems with
BGP
On Fri, Jan 22, 2010 at 10:07:35AM +, Nick Hilliard wrote:
On 22/01/2010 05:07, Jim Mercer wrote:
i'm just wandering what happened to 24.0.0.0/8 and what policies
govern who and what can use the address space there.
Not quite sure why you'd want to use 24/8. It became a normal address
Arbor boxes (E30/E100) also do this kind of reporting with very granular
options - not cheap, but work well...
Paul
-Original Message-
From: Raymond Macharia [mailto:rmacha...@gmail.com]
Sent: January-22-10 1:46 AM
To: Isaac Conway
Cc: nanog list
Subject: Re: Network Bandwidth Reporting
On 1/21/10 9:16 PM, Steven Bellovin wrote:
OK, folks -- we've corrected the scheduling conflict. The secure routing
working is now March 10-12. Please come!
But, But, But, That conflicts with ICANN ... Oh. Never mind. According
to the Protocol Supporting Organization Depricated decision
On Fri, 22 Jan 2010 05:52:11 +0200, Gadi Evron said:
1. Did Google hack a Taiwanese server to investigate the breach? If so,
good for them.
No, *not* good. If *you* had a server that got compromised, and used to launch
attacks on 500 sites, would you want to try to deal with 500 return
Bill Stewart wrote:
On Thu, Jan 21, 2010 at 5:13 PM, George Bonser gbon...@seven.com wrote:
Some of that water is dirtier than the rest. I wouldn't want to be the
person who gets 1.2.3.0/24
I'd guess that 1.1.1.1 and 2.2.2.2 are probably much more widely used.
At least 1.1.1.0/24 should be
On 01/22/2010 02:54 PM, William Allen Simpson wrote:
Why not 36 37?
please refer to
http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/
cheers,
raoul
--
DI (FH) Raoul Bhatia M.Sc. email.
On Fri, Jan 22, 2010 at 08:54:37AM -0500,
William Allen Simpson william.allen.simp...@gmail.com wrote
a message of 20 lines which said:
I agree that 1/8 was probably about the *last* that should have been
allocated. It's particularly frustrating that they made two
assignments at the same
* William Allen Simpson:
Bill Stewart wrote:
On Thu, Jan 21, 2010 at 5:13 PM, George Bonser gbon...@seven.com wrote:
Some of that water is dirtier than the rest. I wouldn't want to be the
person who gets 1.2.3.0/24
I'd guess that 1.1.1.1 and 2.2.2.2 are probably much more widely used.
At
On 22/01/2010 13:54, William Allen Simpson wrote:
Also, 27/8 is clearly in the middle of a group of North American military
assignments. So at the very least, these aren't very CIDR'ish.
Is that operationally relevant to the /8 assignment process?
Why not 36 37?
Random selection to ensure
Nick Hilliard wrote:
On 22/01/2010 13:54, William Allen Simpson wrote:
Why not 36 37?
Random selection to ensure that no RIR can accuse IANA of bias. See
David's previous post:
http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/
Because relying on a blog post for
On Fri, Jan 22, 2010 at 10:16:12AM -0500,
William Allen Simpson william.allen.simp...@gmail.com wrote
a message of 17 lines which said:
http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/
Because relying on a blog post for policy
I'm fairly certain that it is because
To echo and earlier post, what's the operational importance of
assigning adjacent /8s? Are you hoping to aggregate them into a /7?
--Richard
On Fri, Jan 22, 2010 at 10:16 AM, William Allen Simpson
william.allen.simp...@gmail.com wrote:
Nick Hilliard wrote:
On 22/01/2010 13:54, William Allen
In the absence of global policy on this matter, the RIRs and IANA
try to work together in the tradition of the Internet in order to
keep things running as smoothly as possible. This is a *feature*
not a bug.
If you want formal policy in this area, it's very easy to submit a
proposal for
On 22/01/2010 15:16, William Allen Simpson wrote:
Because relying on a blog post for policy really meets everybody's
definition of rationality :-(
What works then? What happened to rough consensus and running code?
If you're assigning 2 at the same time, they should be adjacent.
The
Nick Hilliard wrote:
Someone else mentioned that we are now scraping the bottom of the ipv4
barrel. As of two days ago, there were quantifiable problems associated
with 13 out of the 26 remaining /8s. 12 of these are known to be used to
one extent or another on internet connected networks, and
On 22 Jan 2010, at 8:32, Brian Dickson wrote:
[...]
The granularity of allocations is arbitrary, and when scraping the bottom of
the barrel,
where there are known problems, it may time to get more granular.
There's really no difference in managing a handful of /N's rather than /8's,
if
On 22 Jan 2010, at 7:16, William Allen Simpson wrote:
[...]
http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/
Because relying on a blog post for policy really meets everybody's
definition of rationality :-(
It's not a policy, it's an explanation of the reasoning
Hello all,
For the past few days we have been seeing some massive performance problems for
all west coast users who are trying to reach our systems through Comcast. I am
wondering if other people are seeing this. Now I am If anyone from Comcast is
on the board, we would appreciate some
Would it make sense for the RIRs to just carve out the bad parts of
the blocks, instead of IANA? Under current policy, would reserving
bad bits make it more difficult for an RIR to get additional
allocations?
--Richard
On Fri, Jan 22, 2010 at 11:56 AM, Leo Vegoda leo.veg...@icann.org wrote:
On
Anybody know a contractor that could quote on building out a quality
server room in a facility in the Toronto area?
Our executive want to know what it would cost to build a room for our
expansion as opposed to putting the hardware into a co-lo facility.
Off-line response would be fine.
In a message written on Fri, Jan 22, 2010 at 12:32:30PM -0400, Brian Dickson
wrote:
So, if the tainted *portions* of problem /8's are set aside, you end up with
sets of varying
sizes of /N. E.g. if there is one /24 that is a problem, you set that aside,
and end up with
a set that consists
On Jan 22, 2010, at 9:52 AM, Richard Barnes wrote:
Would it make sense for the RIRs to just carve out the bad parts of
the blocks, instead of IANA? Under current policy, would reserving
bad bits make it more difficult for an RIR to get additional
allocations?
Under existing policies, there
This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
Daily listings are sent to bgp-st...@lists.apnic.net
For historical data, please see http://thyme.apnic.net.
If you have any comments please contact Philip Smith
On 22/01/2010 16:32, Brian Dickson wrote:
So, if the tainted *portions* of problem /8's are set aside
What portion of 1/8 is untainted? Or any other /8 that the IANA has
identified as having problems? How do you measure it? How do you ensure
that other /8s which don't _appear_ to have
In a message written on Fri, Jan 22, 2010 at 07:09:00PM +, Nick Hilliard
wrote:
What portion of 1/8 is untainted? Or any other /8 that the IANA has
identified as having problems? How do you measure it? How do you ensure
I, personally, am quite skeptical that any of the /8's are tainted
From the traffic generated by all the port-scanning and other
similarly-useless packets, one could argue that all of unicast v4 space
is tainted at this point.*
Maybe we should be using that as a reason to switch to v6.
Matthew Kaufman
*If you don't believe me, point a /16 or larger down a
I think it would certainly be useful, both diagnostically and operationally,
for IANA and the RIR's to *actually announce* the unused space, and run either
or
both of tar-pits and honey-pots on those, for just such a reason - to gauge
problems
that might exist on unused space, *before* the space
On 2010-01-22, at 14:49, Brian Dickson wrote:
I think it would certainly be useful, both diagnostically and operationally,
for IANA and the RIR's to *actually announce* the unused space, and run
either or
both of tar-pits and honey-pots on those, for just such a reason - to gauge
problems
for this purpose:
apnic AP ipv41.0.0.0 256 20100122assigned
apnic AP ipv41.1.1.0 256 20100122assigned
apnic AP ipv41.2.3.0 256 20100122assigned
apnic AP ipv41.50.0.0102420100122allocated
apnic AP
On Fri, Jan 22, 2010 at 11:49 AM, Brian Dickson
brian.dick...@concertia.com wrote:
I think it would certainly be useful, both diagnostically and operationally,
for IANA and the RIR's to *actually announce* the unused space, and run
either or
both of tar-pits and honey-pots on those, for just
On Fri, Jan 22, 2010 at 11:49 AM, Brian Dickson
brian.dick...@concertia.com wrote:
I think it would certainly be useful, both diagnostically and operationally,
for IANA and the RIR's to *actually announce* the unused space, and run
either or
both of tar-pits and honey-pots on those, for just
BGP Update Report
Interval: 14-Jan-10 -to- 21-Jan-10 (7 days)
Observation Point: BGP Peering with AS131072
TOP 20 Unstable Origin AS
Rank ASNUpds % Upds/PfxAS-Name
1 - AS845231498 1.8% 30.7 -- TEDATA TEDATA
2 - AS764320956 1.2% 22.6
This report has been generated at Fri Jan 22 21:11:28 2010 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date
On Thu, Jan 21, 2010 at 6:53 PM, chaim.rie...@gmail.com wrote:
We had a major turnout this past weekend here in southern cal.
Shout out to the uc system and people.
Yahoo is hosting a Crisis Camp to help support the Haiti relief
efforts here in silicon valley tomorrow:
As of two days ago, there were quantifiable problems associated with
13 out of the 26 remaining /8s.
i love quantification! please send detail.
otherwise, this thread seems a bit content-free and pontification heavy
to me
randy
In the past I've always used /30's for PTP connection subnets out of old
habit (i.e. Ethernet that won't take unnumbered) but now I'm considering
switching to /31's in order to stretch my IPv4 space further. Has anyone
else does this? Good? Bad? Based on the bit of testing I've done this
Greetings,
On Fri, 22 Jan 2010, Seth Mattinen wrote:
In the past I've always used /30's for PTP connection subnets out of old
habit (i.e. Ethernet that won't take unnumbered) but now I'm considering
switching to /31's in order to stretch my IPv4 space further. Has anyone
else does this?
We recently did a backbone router upgrade and the vendor surprisingly
didn't support /31's. We had to renumber all those interconnects and
peering sessions to /30's. That wasn't fun!
On Jan 22, 2010, at 4:53 PM, Seth Mattinen wrote:
Joe Provo wrote:
On Fri, Jan 22, 2010 at 04:08:28PM
rfc3021 is over 9 years old, so should be no suprise that it works
well. :-)
I'm never surprised anymore by something that should work
turning out to
have some obscure quirk about it, so I figured it was worth asking. ;)
It's not a quirk, it's an implementation-specific feature ;)
On Jan 22, 2010, at 4:41 PM, Joe Provo wrote:
On Fri, Jan 22, 2010 at 04:08:28PM -0800, Seth Mattinen wrote:
In the past I've always used /30's for PTP connection subnets out of old
habit (i.e. Ethernet that won't take unnumbered) but now I'm considering
switching to /31's in order to
Shouldn't be any issues...it's 2010 :)
And, your IP allocation utilization will love you.
tv
- Original Message -
From: Seth Mattinen se...@rollernet.us
To: nanOG list nanog@nanog.org
Sent: Friday, January 22, 2010 6:08 PM
Subject: Using /31 for router links
In the past I've always
On Jan 22, 2010, at 12:26 AM, Bruce Williams wrote:
The problem with IE is the same problem as Windows, the basic design
is fundementally insecure and timely updates can't fix that.
You do realize, of course, that IE is recording less than half the security
flaw rate of Firefox? (See
On Fri, 2010-01-22 at 22:16 -0500, Steven Bellovin wrote:
On Jan 22, 2010, at 12:26 AM, Bruce Williams wrote:
The problem with IE is the same problem as Windows, the basic design
is fundementally insecure and timely updates can't fix that.
You do realize, of course, that IE is recording
On 1/22/10 8:37 PM, William Pitcock wrote:
On Fri, 2010-01-22 at 22:16 -0500, Steven Bellovin wrote:
On Jan 22, 2010, at 12:26 AM, Bruce Williams wrote:
The problem with IE is the same problem as Windows, the basic design
is fundementally insecure and timely updates can't fix that.
You do
When did this become slashdot?
Sent via BlackBerry from T-Mobile
On Jan 22, 2010, at 10:37 PM, William Pitcock wrote:
On Fri, 2010-01-22 at 22:16 -0500, Steven Bellovin wrote:
On Jan 22, 2010, at 12:26 AM, Bruce Williams wrote:
The problem with IE is the same problem as Windows, the basic design
is fundementally insecure and timely updates can't fix
On 23/01/2010, at 1:31 PM, Jay Nugent wrote:
Greetings,
On Fri, 22 Jan 2010, Seth Mattinen wrote:
In the past I've always used /30's for PTP connection subnets out of old
habit (i.e. Ethernet that won't take unnumbered) but now I'm considering
switching to /31's in order to stretch my
Nathan Ward na...@daork.net wrote:
ARP is still required on ethernet links, so that the MAC address can be =
discovered for use in the ethernet frame header. /31 does not change the =
behavior of ARP at all.
soapbox
That is why I hate Ethernet with a passion. Ethernet should be for LANs
ARP is still required on ethernet links, so that the MAC address can
be
discovered for use in the ethernet frame header. /31 does not change
the behavior of ARP at all.
--
Nathan Ward
I often manually configure the MAC addresses in static fashion on
point-to-points to eliminate the
On Sat, 23 Jan 2010 04:22:50 GMT
msoko...@ivan.harhan.org (Michael Sokolov) wrote:
Nathan Ward na...@daork.net wrote:
ARP is still required on ethernet links, so that the MAC address can be =
discovered for use in the ethernet frame header. /31 does not change the =
behavior of ARP at
On 1/23/10 6:08 AM, Steven Bellovin wrote:
I think that that's wishful thinking. IE has fewer security problems because Microsoft
has put a tremendous amount of effort -- and often fought its own developers -- in a
disciplined software development environment with careful, structured security
53 matches
Mail list logo
