Re: policies for 24.0.0.0/8 ?
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 address space there. Not quite sure why you'd want to use 24/8. It became a normal address block a very long time ago . RFC3330 sez: 24.0.0.0/8 - This block was allocated in early 1996 for use in provisioning IP service over cable television systems. Although the IANA initially was involved in making assignments to cable operators, this responsibility was transferred to American Registry for Internet Numbers (ARIN) in May 2001. Addresses within this block are assigned in the normal manner and should be treated as such. So, it's just regular IP address space, available for assignment if you live in ARIN-land. Incidentally, Pakistan is serviced by APNIC, not RIPE: http://www.apnic.net/about-APNIC/organization/apnics-region Nick
Re: AS3549
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 sessions behind AS3549 ? It seems our trouble ticket is currently being taken care of and the GlobalCrossing NOC is investigating. If other people experience the same thing please let me know. PS: we are located in Amsterdam, Netherlands Hans Goes Senior Network Engineer IS Interned Services - PROUD AND CLEAR. www.is.nl +31 299 476 185 Gorslaan 18 1441 RG Purmerend The Netherlands cr1.ams2#sho ip bgp flap-stat inc 208.50.59.105 * 4.23.88.0/24 208.50.59.105 1 00:17:43 3549 7018 46164 * 4.23.89.0/24 208.50.59.105 1 00:17:43 3549 7018 46164 * 4.23.92.0/23 208.50.59.105 1 00:17:43 3549 7018 46164 * 4.23.94.0/23 208.50.59.105 1 00:17:43 3549 7018 46164 * 4.38.0.0/21 208.50.59.105 1 00:17:43 3549 7018 46164 * 4.38.8.0/21 208.50.59.105 1 00:17:43 3549 7018 46164 * 4.43.50.0/24 208.50.59.105 1 00:17:43 3549 7018 46164 * 4.43.51.0/24 208.50.59.105 1 00:17:43 3549 7018 46164 * 4.67.96.0/21 208.50.59.105 1 00:17:43 3549 7018 46164 * 4.67.104.0/21 208.50.59.105 1 00:17:43 3549 7018 46164 * 8.14.0.0/20 208.50.59.105 1 00:17:43 3549 7018 46164 * 8.14.16.0/20 208.50.59.105 1 00:17:43 3549 7018 46164 * 24.49.84.0/23 208.50.59.105 1 00:01:22 3549 3356 7843 * 24.49.89.0/24 208.50.59.105 1 00:01:22 3549 3356 7843 * 38.97.109.0/24 208.50.59.105 2 00:25:18 3549 701 20417 * 41.0.144.0/20 208.50.59.105 2 00:21:47 3549 5713 36994
Re: policies for 24.0.0.0/8 ?
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 block a very long time ago . RFC3330 sez: 24.0.0.0/8 - This block was allocated in early 1996 for use in ... Numbers (ARIN) in May 2001. Addresses within this block are assigned in the normal manner and should be treated as such. So, it's just regular IP address space, available for assignment if you live in ARIN-land. hrm, somehow i missed that. Incidentally, Pakistan is serviced by APNIC, not RIPE: http://www.apnic.net/about-APNIC/organization/apnics-region wow, musta been sleeping that day. any how, it is what it is. -- Jim Mercerj...@reptiles.org+92 336 520-4504 I'm Prime Minister of Canada, I live here and I'm going to take a leak. - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, Who are you and where are you going?
RE: Network Bandwidth Reporting Tool
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 Tool Hi, 1. ETINC - www.etinc.com - Really good with a mysql backend and gives you exactly what you are looking for. You can either buy the software and build it into a FreeBSD box or you can get the already built appliance. The price point is also quite good 2. Allot - www.allot.com -Comes with a lot of features and has a good reporting mechanism. They have boxes of different sizes and add on software for reports etc. higher priced but works very well. Regards Raymond Macharia On Fri, Jan 22, 2010 at 5:13 AM, Isaac Conway i...@conwaynetworks.comwrote: Oh mighty list, I am curious what tools you use to generate monthly usage and billing reports for your execs? I am not really looking for a RRD type solution, rather a page I can pull up and gives me the numbers (95p, cost, overage, etc.) for the past month. Copy and paste into a spreadsheet, job complete We are getting to the point where we have multiple datacenters and numerous uplinks and circuits for each, I find I am spending too many hours each month compiling data. I was thinking about writing some quick scripts to poll the router interfaces and put it to database, but I figured I would ask before re-inventing the wheel. Thanks in advance! Isaac The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you.
Re: DIMACS/CCICADA secure routing workshop rescheduled
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 of 2003 and the Address Supporting Organization Dormant Blessed Practices, there is no security and stability rational for secure routing. /rant
Re: Anyone see a game changer here?
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 strikes? Especially if the initial strike happens at 5:47PM on a Friday, and by the time you come in on Monday morning, you've been pwned by 197 different return strikes? Then the fun *really* starts when you call your national CERT and report you've been hit by an organized set of targeted attacks from 198 locations and hilarity ensues because your CERT can't contact 143 of them and verify it was a return strike. Definitely one of the sillier things I've heard Gadi say in a while... pgpzmucqIEEa6.pgp Description: PGP signature
Re: 1/8 and 27/8 allocated to APNIC
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 reserved by IANA or somebody. 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 time, but not to adjacent routing blocks 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. Why not 36 37?
Re: 1/8 and 27/8 allocated to APNIC
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. r.bha...@ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email.off...@ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax.+43 1 3670030 15
Re: 1/8 and 27/8 allocated to APNIC
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 time, but not to adjacent routing blocks http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/
Re: 1/8 and 27/8 allocated to APNIC
* 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 least 1.1.1.0/24 should be reserved by IANA or somebody. I agree that 1/8 was probably about the *last* that should have been allocated. It's probably better to decouple the pain of taking 1/8 and 2/8 into production from the general pain of running out in ernest (assuming that we ever enter an age where IP addresses are a scarce resource). -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Re: 1/8 and 27/8 allocated to APNIC
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 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/ Nick
Re: 1/8 and 27/8 allocated to APNIC
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 policy really meets everybody's definition of rationality :-( If you're assigning 2 at the same time, they should be adjacent. The dribbles here and there policy never was particularly satisfying, because it assumes that this was all temporary until the widespread deployment of IPv6.
Re: 1/8 and 27/8 allocated to APNIC
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 the ICANN staff can post on its own blog at will while creating a real policy and publishing it on the official Web site requires five years, the (paid) advice of ten lawyers and the signature of five vice-presidents.
Re: 1/8 and 27/8 allocated to APNIC
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 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 policy really meets everybody's definition of rationality :-( If you're assigning 2 at the same time, they should be adjacent. The dribbles here and there policy never was particularly satisfying, because it assumes that this was all temporary until the widespread deployment of IPv6.
Re: 1/8 and 27/8 allocated to APNIC
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 global number policy to each of the RIRs and that will produce the desired result. One should be realistic about the time requirements to produce uniform global policy; it looks to take about 12 to 18 months from policy initiation to global adoption at present. /John On Jan 22, 2010, at 10:16 AM, William Allen Simpson wrote: 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 policy really meets everybody's definition of rationality :-( If you're assigning 2 at the same time, they should be adjacent. The dribbles here and there policy never was particularly satisfying, because it assumes that this was all temporary until the widespread deployment of IPv6.
Re: 1/8 and 27/8 allocated to APNIC
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 dribbles here and there policy never was particularly satisfying, because it assumes that this was all temporary until the widespread deployment of IPv6. I don't get where you're coming from here. I can see that there is a (very minor) aesthetic reason to assign adjacent /8s to a RIR. But operationally, I really can't see any other reason. 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 are seen as source addresses on various end-points around the place. One of them (223/8) has rfc-3330 issues (although later fixed in 5735). So, the issue for IANA is how to allocate these /8s in a way which is demonstrably unbiased towards any particular RIR. The solution which they've agreed on with the RIRs looks unbiassed, unpredictable in advance, calculable in retrospect and best of all, it's not open to abuse. And while Chuck Norris could probably predict the footsie, the djia and the hang-seng weeks in advance, this sort of prognostication appears to be beyond the capabilities of ICANN, IANA and the RIRs. At least if it isn't, no-one's saying anything. Do you have a better suggestion about how to allocate tainted address space in a way that is going to ensure that the organisations at the receiving end aren't going to accuse you of bias? Nick
RE: 1/8 and 27/8 allocated to APNIC
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 are seen as source addresses on various end-points around the place. One of them (223/8) has rfc-3330 issues (although later fixed in 5735). So, the issue for IANA is how to allocate these /8s in a way which is demonstrably unbiased towards any particular RIR. The solution which they've agreed on with the RIRs looks unbiassed, unpredictable in advance, calculable in retrospect and best of all, it's not open to abuse. And while Chuck Norris could probably predict the footsie, the djia and the hang-seng weeks in advance, this sort of prognostication appears to be beyond the capabilities of ICANN, IANA and the RIRs. At least if it isn't, no-one's saying anything. Do you have a better suggestion about how to allocate tainted address space in a way that is going to ensure that the organisations at the receiving end aren't going to accuse you of bias? My response: 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 N is not that much bigger than 8. The granularity boundary probably should stay around or above the biggest assignments a given RIR is expected to make, or has made. 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 of one each of /9 through /24. Even if you set aside a /16, you get a set which is /9, /10, /11, /12, /13, /14, /15, and /16. From a documentation and allocation perspective, you could even treat that as giving the whole of the /8 to the RIR, and having them give back (assign) the problem chunk to IANA. Do this for the 13 problem /8's, and then group the resulting untainted sets and give them out. Give them out according to the needs of the RIRs, and the larger community will consider it fair. No one will think badly of giving the /9's to one of the big 3 (APNIC, ARIN, or RIPE), and the smaller ones to the other RIRs, I'm sure. As long as there are no tainted portions assigned to the RIRs, I don't see how this could be a problem. Brian
Re: 1/8 and 27/8 allocated to APNIC
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 N is not that much bigger than 8. You need to change the global policy to do that. ICANN staff cannot allocate anything more specific than a /8 right now because the policy requires IPv4 allocations to the RIRs be in /8 units. http://www.icann.org/en/general/allocation-IPv4-rirs.html Regards, Leo
Re: 1/8 and 27/8 allocated to APNIC
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 behind the implementation of the policy. Regards, Leo
Comcast Packet Loss
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 information as to what is happening. Best Regards, Babak Packets Pings HostLoss% Snt Last Avg Best Wrst StDev 1. 10.255.254.1 0.0% 6750.5 0.4 0.4 19.5 0.8 2. 208.85.64.254 0.0% 6751.7 5.0 0.8 21.6 4.3 3. 208.85.64.253 0.0% 6758.8 6.1 1.4 21.5 4.1 4. gige-g2-9.core1.nyc5.he.net 0.0% 6759.8 2.5 1.4 19.0 2.7 5. 10gigabitethernet1-4.core1.nyc1.he.net0.0% 6753.9 4.0 1.4 25.5 3.8 6. 10gigabitethernet1-1.core1.nyc4.he.net0.0% 6751.8 3.2 1.6 16.3 3.2 7. TenGigabitEthernet1-3.ar5.NYC1.gblx.net 0.0% 6751.7 7.5 1.7 205.3 25.0 8. COMCAST-IP-SERVICES-LLC.TenGigabitEthernet4-4.ar4.NYC1.gblx.net 0.3% 6752.8 8.0 2.2 1131. 70.6 64.211.195.226 COMCAST-IP-SERVICES-LLC.tengigabitethernet1-4.ar5.NYC1.gblx.net 9. pos-2-10-0-0-cr01.chicago.il.ibone.comcast.net0.4% 675 33.2 37.3 33.0 1130. 62.7 te3-7.cr0.gl.cph.ngdc.net 10. pos-1-14-0-0-cr01.denver.co.ibone.comcast.net 0.4% 675 60.4 64.7 60.0 1132. 63.5 te4-3.alb2nxc7.dk.ip.tdc.net 11. pos-0-11-0-0-cr01.sanjose.ca.ibone.comcast.net0.4% 675 94.0 99.4 93.4 1117. 70.9 pe01.111eighthave.ny.ibone.comcast.net 12. pos-0-13-0-0-ar01.sfsutro.ca.sfba.comcast.net 0.4% 675 95.4 100.9 94.7 1118. 71.4 pos-1-8-0-0-cr01.newyork.ny.ibone.comcast.net 13. te-9-4-ur03.pinole.ca.sfba.comcast.net0.3% 675 99.1 105.8 98.8 1162. 74.5 pos-2-10-0-0-cr01.chicago.il.ibone.comcast.net 14. pos-1-14-0-0-cr01.denver.co.ibone.comcast.net99.3% 675 1178. 951.8 415.0 1178. 315.1 15. pos-0-11-0-0-cr01.sanjose.ca.ibone.comcast.net 99.3% 675 1213. 1009. 551.0 1213. 272.0 16. pos-0-13-0-0-ar01.sfsutro.ca.sfba.comcast.net99.1% 675 1217. 889.0 184.7 1217. 408.1 17. te-9-4-ur03.pinole.ca.sfba.comcast.net 99.1% 675 1221. 907.0 202.2 1221. 398.2 18. ??? -- Babak Pasdar President CEO | Certified Ethical Hacker Bat Blue Corporation | Integrity . Privacy . Availability (p) 212.461.3322 x3005 | (f) 212.584. | (w) www.BatBlue.com Receive Bat Blue's Daily Security Intelligence Report Bat Blue's AS: 25885 | BGP Policy | Peering Policy Bat Blue's Legal Notice Reducing IT Security Budget, Burden Risk - Video | Article
Re: 1/8 and 27/8 allocated to APNIC
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 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 N is not that much bigger than 8. You need to change the global policy to do that. ICANN staff cannot allocate anything more specific than a /8 right now because the policy requires IPv4 allocations to the RIRs be in /8 units. http://www.icann.org/en/general/allocation-IPv4-rirs.html Regards, Leo
Computer room construction
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. Thanks, Erik
Re: 1/8 and 27/8 allocated to APNIC
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 of one each of /9 through /24. Even if you set aside a /16, you get a set which is /9, /10, /11, /12, /13, /14, /15, and /16. If the tainted portions were going to be set aside, it makes much more sense to me that they be set aside at the RIR level and simply not be counted against the RIR when they go back to IANA for more. It makes the bookkeeping much simpler. When you go to IANA's web site 1/8 went to an RIR. You can look there to find the few /24's that couldn't be given out. The alternative is to blow up the IANA allocation list by several orders of magnitude, for no good reason. Really though, we need the squatters to feel pain. They are the ones in the wrong. Unfortunately who ever receives the allocations will also feel pain. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpf4F13bBRxy.pgp Description: PGP signature
Re: 1/8 and 27/8 allocated to APNIC
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 is no way for IANA to carve out pieces of address blocks. The /8s with pieces carved out of them by the IETF are/will be allocated to RIRs with an understanding that the RIRs aren't supposed to allocate the IETF-designated reserved chunks (which, presumably, they won't). Regards, -drc
Weekly Routing Table Report
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 p...@cisco.com. Routing Table Report 04:00 +10GMT Sat 23 Jan, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 309323 Prefixes after maximum aggregation: 143748 Deaggregation factor: 2.15 Unique aggregates announced to Internet: 152029 Total ASes present in the Internet Routing Table: 33159 Prefixes per ASN: 9.33 Origin-only ASes present in the Internet Routing Table: 28791 Origin ASes announcing only one prefix: 14048 Transit ASes present in the Internet Routing Table:4368 Transit-only ASes present in the Internet Routing Table:106 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 23 Max AS path prepend of ASN ( 9503) 21 Prefixes from unregistered ASNs in the Routing Table: 764 Unregistered ASNs in the Routing Table: 132 Number of 32-bit ASNs allocated by the RIRs:406 Prefixes from 32-bit ASNs in the Routing Table: 351 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:186 Number of addresses announced to Internet: 2178191808 Equivalent to 129 /8s, 212 /16s and 145 /24s Percentage of available address space announced: 58.8 Percentage of allocated address space announced: 65.9 Percentage of available address space allocated: 89.1 Percentage of address space in use by end-sites: 80.8 Total number of prefixes smaller than registry allocations: 149077 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:74725 Total APNIC prefixes after maximum aggregation: 25834 APNIC Deaggregation factor:2.89 Prefixes being announced from the APNIC address blocks: 71407 Unique aggregates announced from the APNIC address blocks:31479 APNIC Region origin ASes present in the Internet Routing Table:3922 APNIC Prefixes per ASN: 18.21 APNIC Region origin ASes announcing only one prefix: 1070 APNIC Region transit ASes present in the Internet Routing Table:619 Average APNIC Region AS path length visible:3.6 Max APNIC Region AS path length visible: 23 Number of APNIC addresses announced to Internet: 489484832 Equivalent to 29 /8s, 44 /16s and 242 /24s Percentage of available APNIC address space announced: 76.8 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:129460 Total ARIN prefixes after maximum aggregation:67652 ARIN Deaggregation factor: 1.91 Prefixes being announced from the ARIN address blocks: 103566 Unique aggregates announced from the ARIN address blocks: 39277 ARIN Region origin ASes present in the Internet Routing Table:13475 ARIN Prefixes per ASN: 7.69 ARIN Region origin ASes announcing only one prefix:5213 ARIN Region transit ASes present in the Internet Routing Table:1336 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 735487520 Equivalent to 43 /8s, 214 /16s and 166 /24s Percentage of available ARIN address space
Re: 1/8 and 27/8 allocated to APNIC
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 problems really don't have problems due to invisible use? And if you set aside say, the bits that WIANA or some other organisation has delegated to its stakeholders, are you implicitly acknowledging that they are a legitimate ICANN accredited RIR? Or if some large corporation starts reselling CPE gear which uses IANA-unallocated space on one of their popular devices, does their prior use get them some form of rights over that address space? IANA only guarantees that no other RIR has been allocated these /8s according to its registry, and it does not guarantee routability or reachability on the public internet (however much the individuals within IANA / ICANN care about this). If some other organisation has decided to use address space which overlaps with IANA's public registry, then they've created a serious problem for themselves and their customers / stakeholders which could have been avoided in the first place. IPv4 address space is handed out on the basis of need, and there was really no reason for these organisations to squat unallocated space in the first place. IANA hands out /8s. We know that some of these are going to cause serious problems, but life sucks and we just have to deal with what happens. Personally, I feel very sorry for APNIC that they've been allocated 1/8, but that's just the way the cookie crumbles. The RIRs agreed a process with IANA and knew what the consequences of that process were. They also appear to have agreed that it was better to use 1/8 than not use it. Their end-users are going to be incensed at the level of problems which this is going to cause. I can only hope that there won't be inter-governmental bun-fights over it. Nick
Re: 1/8 and 27/8 allocated to APNIC
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 to the point where they are unusable. However, as an example of something I would say rises to the level of tainted. Remember a few years back Netgear hard coded the IP's of the UW time servers, and then shipped a few million boxes, which on by the way had a bug so they asked for time too often? http://pages.cs.wisc.edu/~plonka/netgear-sntp/ The result was a 40,000 packet per second flood. If an RIR was to give out a block with that sort of taint (e.g. UW returned that block, or something out there defaults to contacting 1/8 in a similar manor) then I think it's reasonable for the RIR to mark it as tainted, work with the people to get it fixed, and give folks other address space. Hopefully the RIR could work with the party involved and eventually return the space to service. IANA hands out /8s. We know that some of these are going to cause serious problems, but life sucks and we just have to deal with what happens. Pretty much. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpHYT0Hvr83a.pgp Description: PGP signature
Re: 1/8 and 27/8 allocated to APNIC
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 fractional T1 line and try to get useful work done over the remaining bandwidth.
RE: 1/8 and 27/8 allocated to APNIC
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 is assigned. And, it'd be nice if there were a check-box for I volunteer for the pain. In the movies, where something bad can happen and they draw straws, it is almost always drawing straws from among volunteers. There are certainly reasons for wanting to identify and not assign space that has issues, to certain recipients or when certain conditions exist. E.g.: critical infrastructure /24's; initial assignments (where the recipient doesn't gave another block into which to internally interchange addresses); less technically adept recipients (e.g. in the developing nations, where adding pain would really be unusually cruel.) Brian -Original Message- From: Nick Hilliard [mailto:n...@foobar.org] Sent: January-22-10 3:09 PM To: Brian Dickson Cc: William Allen Simpson; nanog@nanog.org Subject: Re: 1/8 and 27/8 allocated to APNIC 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 problems really don't have problems due to invisible use? IANA hands out /8s. We know that some of these are going to cause serious problems, but life sucks and we just have to deal with what happens.
Re: 1/8 and 27/8 allocated to APNIC
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 that might exist on unused space, *before* the space is assigned. I believe the RIRs have already been doing this with each /8 they've received from the IANA for quite some time. Joe
Re: 1/8 and 27/8 allocated to APNIC
On 22 Jan 2010, at 11:52, Joe Abley 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 that might exist on unused space, *before* the space is assigned. I believe the RIRs have already been doing this with each /8 they've received from the IANA for quite some time. And indeed the latest APNIC stats file shows that they have made assignments from their new /8s, presumably 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 ipv41.255.0.0 65536 20100122allocated apnic AP ipv427.0.0.0256 20100122assigned apnic AP ipv427.50.0.0 102420100122allocated apnic AP ipv427.255.0.0 65536 20100122allocated Regards, Leo
Re: 1/8 and 27/8 allocated to APNIC
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 such a reason - to gauge problems that might exist on unused space, *before* the space is assigned. $ whois -h whois.apnic.net 1.1.1.1 % [whois.apnic.net node-1] % Whois data copyright termshttp://www.apnic.net/db/dbcopyright.html inetnum: 1.1.1.0 - 1.1.1.255 netname: Debogon-prefix descr:APNIC Debogon Project descr:APNIC Pty Ltd country: AU admin-c: AP16-AP tech-c: AP16-AP mnt-by: APNIC-HM mnt-routes: MAINT-APNIC-DEBOGON (Similar things exist for 1.1.2.0/24 and several others) I'm not seeing them announced yet, but it's only a matter of time. Scott.
Re: 1/8 and 27/8 allocated to APNIC
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 such a reason - to gauge problems that might exist on unused space, *before* the space is assigned. And, it'd be nice if there were a check-box for I volunteer for the pain. In the movies, where something bad can happen and they draw straws, it is almost always drawing straws from among volunteers. *heh* And there's always going to be a set of normally-outbound-heavy networks that would *love* to get more inbound traffic by hosting honeypots for tainted networks...so there's one set of hands ready and waiting to shoot up the minute you need volunteers for your tar-pits and honey-pots. Matt
BGP Update Report
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 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 3 - AS268618448 1.1% 160.4 -- ATT Global Network Services - EMEA 4 - AS982915740 0.9% 18.8 -- BSNL-NIB National Internet Backbone 5 - AS432313846 0.8% 3.1 -- TWTC - tw telecom holdings, inc. 6 - AS773812597 0.7% 29.2 -- Telecomunicacoes da Bahia S.A. 7 - AS179012342 0.7% 99.5 -- Sprint US 8 - AS37986 12219 0.7% 140.4 -- TULIP Tulip Telecom Ltd. 9 - AS580011189 0.6% 50.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 10 - AS943010187 0.6% 328.6 -- STPI-NOIDA Software Technology Parks of India,Block-IV 11 - AS4270 9177 0.5%1835.4 -- Red de Interconexion Universitaria 12 - AS6389 9023 0.5% 2.2 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 13 - AS5668 8813 0.5% 11.1 -- AS-5668 - CenturyTel Internet Holdings, Inc. 14 - AS151 8798 0.5% 549.9 -- IND-NTC-AS - Hewlett-Packard Company 15 - AS145227857 0.5% 22.6 -- Satnet 16 - AS235777456 0.4% 12.5 -- ATM-MPLS-AS-KR Korea Telecom 17 - AS5803 7384 0.4% 78.6 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 18 - AS1785 7183 0.4% 3.8 -- AS-PAETEC-NET - PaeTec Communications, Inc. 19 - AS3255 7136 0.4% 44.9 -- UARNET-AS Ukrainian Academic and Research Network 20 - AS174887132 0.4% 4.8 -- HATHWAY-NET-AP Hathway IP Over Cable Internet TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS200662426 0.1%2426.0 -- MORRISTECH - Morris Technologies, Inc. 2 - AS487542323 0.1%2323.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 3 - AS4270 9177 0.5%1835.4 -- Red de Interconexion Universitaria 4 - AS454083300 0.2%1650.0 -- 5 - AS37020 996 0.1% 996.0 -- CELTEL-DRC 6 - AS22570 550 0.0% 550.0 -- AUTODESK-1 Autodesk, Inc. 7 - AS151 8798 0.5% 549.9 -- IND-NTC-AS - Hewlett-Packard Company 8 - AS43818 546 0.0% 546.0 -- MELLAT-AS bankmellat 9 - AS48309 388 0.0% 388.0 -- AGS-AS Ariana Gostar Spadana Autonomous Number 10 - AS151793433 0.2% 381.4 -- RNT-HOSTING-1 - RightNow Technologies, Inc. 11 - AS47262 726 0.0% 363.0 -- HAMARA-AS Hamara System Tabriz Engineering Company 12 - AS48944 687 0.0% 343.5 -- ASKHALIJFARSONLINE Khalij Ettela Resan Jonoub LTD 13 - AS43197 332 0.0% 332.0 -- TT-MOBILE-AS JSC TT Mobile 14 - AS943010187 0.6% 328.6 -- STPI-NOIDA Software Technology Parks of India,Block-IV 15 - AS36988 654 0.0% 327.0 -- MILLICOM-SL 16 - AS31303 323 0.0% 323.0 -- NIOC-AS NIOC Network, Iran 17 - AS48359 967 0.1% 322.3 -- HESABGAR-AS Hesabgar Pardaz Gharb Co. Private J.S. 18 - AS49697 318 0.0% 318.0 -- SHABAKIEH-AS Shabakieh Isfahan Co. 19 - AS47806 630 0.0% 315.0 -- TEL4TEL-AS Pishgaman Rayaneh Zaman Co. Ltd. 20 - AS41152 628 0.0% 314.0 -- AFTAB Aftab Internet Service Provider TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 170.210.56.0/229155 0.5% AS4270 -- Red de Interconexion Universitaria 2 - 203.162.118.128/ 4921 0.3% AS7643 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 3 - 110.234.206.0/23 4001 0.2% AS37986 -- TULIP Tulip Telecom Ltd. 4 - 110.234.208.0/23 4001 0.2% AS37986 -- TULIP Tulip Telecom Ltd. 5 - 110.234.204.0/23 4001 0.2% AS37986 -- TULIP Tulip Telecom Ltd. 6 - 74.117.203.0/243400 0.2% AS15179 -- RNT-HOSTING-1 - RightNow Technologies, Inc. 7 - 222.255.186.0/25 3125 0.2% AS7643 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 8 - 16.139.64.0/24 2923 0.2% AS151 -- IND-NTC-AS - Hewlett-Packard Company 9 - 15.219.192.0/202915 0.2% AS151 -- IND-NTC-AS - Hewlett-Packard Company 10 - 15.154.208.0/202915 0.2% AS151 -- IND-NTC-AS - Hewlett-Packard Company 13 - 192.12.120.0/242559 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 14 - 174.47.118.0/242426 0.1% AS20066 -- MORRISTECH - Morris Technologies, Inc. 15 - 69.34.220.0/22 2399 0.1% AS1790 -- Sprint US 16 - 69.69.228.0/22 2399 0.1% AS1790 -- Sprint US 17 - 67.77.98.0/23 2399 0.1% AS1790 -- Sprint US 18 - 69.34.252.0/23 2399 0.1%
The Cidr Report
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 PrefixesCIDR Agg
15-01-10314098 192139
16-01-10314591 192352
17-01-10314553 192190
18-01-10314561 191509
19-01-10314356 191890
20-01-10314595 192239
21-01-10314760 190487
22-01-10311605 190808
AS Summary
33400 Number of ASes in routing system
14227 Number of ASes announcing only one prefix
4377 Largest number of prefixes announced by an AS
AS4323 : TWTC - tw telecom holdings, inc.
93176320 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 22Jan10 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 311872 190816 12105638.8% All ASes
AS6389 4147 322 382592.2% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 4377 1701 267661.1% TWTC - tw telecom holdings,
inc.
AS4766 1857 484 137373.9% KIXS-AS-KR Korea Telecom
AS1785 1817 661 115663.6% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS22773 1125 71 105493.7% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS17488 1273 282 99177.8% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS18566 1059 149 91085.9% COVAD - Covad Communications
Co.
AS4755 1310 412 89868.5% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS8151 1572 677 89556.9% Uninet S.A. de C.V.
AS10620 1006 181 82582.0% TV Cable S.A.
AS19262 1056 240 81677.3% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS18101 1079 284 79573.7% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS8452 1017 304 71370.1% TEDATA TEDATA
AS17908 763 58 70592.4% TCISL Tata Communications
AS6478 1104 440 66460.1% ATT-INTERNET3 - ATT WorldNet
Services
AS4808 836 225 61173.1% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS7018 1593 1030 56335.3% ATT-INTERNET4 - ATT WorldNet
Services
AS4804 634 71 56388.8% MPX-AS Microplex PTY LTD
AS7303 672 109 56383.8% Telecom Argentina S.A.
AS3356 1205 647 55846.3% LEVEL3 Level 3 Communications
AS24560 836 294 54264.8% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS4134 1020 488 53252.2% CHINANET-BACKBONE
No.31,Jin-rong Street
AS7545 950 438 51253.9% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS22047 548 65 48388.1% VTR BANDA ANCHA S.A.
AS855609 132 47778.3% CANET-ASN-4 - Bell Aliant
Regional Communications, Inc.
AS11492 1128 651 47742.3% CABLEONE - CABLE ONE, INC.
AS9808 483 17 46696.5% CMNET-GD Guangdong Mobile
Communication Co.Ltd.
AS9443 540 80 46085.2% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS5668 786 330 45658.0% AS-5668 - CenturyTel Internet
Holdings, Inc.
AS9299 665 211 45468.3% IPG-AS-AP Philippine Long
Distance
Re: UC phone system for Haiti (was Katrina Response)
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: http://crisiscamphaitisiliconvalley.eventbrite.com/ If you have some spare time, please consider bringing your laptop and coming over to help with supporting relief efforts in Haiti. Thanks! Matt (and for those not in sunnyvale, there's similar efforts going on in other cities around the globe:) http://www.colombiassh.org/site/CrisisCamp Haiti, Bogota, Colombia http://www.eventbrite.com/event/541831633 CrisisCamp Haiti, Boston http://crisiscampboulderdenver.eventbrite.com/ CrisisCamp Haiti, Boulder/Denver http://crisiscamphaitila2.eventbrite.com/ CrisisCamp Haiti, Los Angeles http://crisiscampmiami.eventbrite.com/ CrisisCamp Haiti, Miami http://crisiscampmontreal.wordpress.com/about/ CrisisCamp Haiti, Montreal http://crisiscampnola.eventbrite.com/CrisisCamp Haiti, New Orleans http://www.eventbrite.com/event/543649069 CrisisCamp Haiti, New York http://crisiscamphaitipdx.eventbrite.com/ CrisisCamp Haiti, Portland http://www.eventbrite.com/event/542966026/?ref=esdgCrisisCamp Haiti, Seattle http://crisiscamphaitiwdc.eventbrite.com/ CrisisCamp Haiti, Washington, DC
Re: 1/8 and 27/8 allocated to APNIC
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
Using /31 for router links
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 shouldn't be a problem since it's only between routers. ~Seth
Re: Using /31 for router links
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? Good? Bad? Based on the bit of testing I've done this shouldn't be a problem since it's only between routers. Yes, this *IS* done *ALL* the time. P-t-P means that there are ONLY two devices on the wire - hence point to point. It ONLY uses two IP addresses (one on each end) and there is no reason or need to ARP on this wire. So no need for a broadcast or network addresses - it is just the two end points. --- Jay Nugent Nugent Telecommunications Train how you will Operate, and you will Operate how you were Trained. ++ | Jay Nugent j...@nuge.com(734)484-5105(734)649-0850/Cell | | Nugent Telecommunications [www.nuge.com]| | Internet Consulting/Linux SysAdmin/Engineering Design/ISP Reseller | | ISP Monitoring [www.ispmonitor.org] ISP Modem Performance Monitoring | | Web-Pegasus[www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts| ++ 7:01pm up 43 days, 18:42, 3 users, load average: 1.10, 0.96, 0.63
Re: Using /31 for router links
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 -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 stretch my IPv4 space further. Has anyone else does this? Good? Bad? Based on the bit of testing I've done this shouldn't be a problem since it's only between routers. 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. ;) ~Seth
RE: Using /31 for router links
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 ;)
Re: Using /31 for router links
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 stretch my IPv4 space further. Has anyone else does this? Good? Bad? Based on the bit of testing I've done this shouldn't be a problem since it's only between routers. rfc3021 is over 9 years old, so should be no suprise that it works well. :-) Works well if supported. Vendor b (nee f) apparently dropped it off their roadmap. -- kris
Re: Using /31 for router links
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 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 shouldn't be a problem since it's only between routers. ~Seth
Re: Anyone see a game changer here?
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 http://prosecure.netgear.com/community/security-blog/2009/11/web-browser-vulnerability-report---firefox-leads-the-pack-at-44.php) --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: Anyone see a game changer here?
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 less than half the security flaw rate of Firefox? (See http://prosecure.netgear.com/community/security-blog/2009/11/web-browser-vulnerability-report---firefox-leads-the-pack-at-44.php) Consider for a moment that both Firefox and Safari are built on open-source code where the code can be audited. As a result, it is clear why Firefox and Safari are more insecure than IE, it is simply because the code is there to be audited. Frankly, they are all about the same security-wise. William
Re: Anyone see a game changer here?
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 realize, of course, that IE is recording less than half the security flaw rate of Firefox? (See http://prosecure.netgear.com/community/security-blog/2009/11/web-browser-vulnerability-report---firefox-leads-the-pack-at-44.php) Consider for a moment that both Firefox and Safari are built on open-source code where the code can be audited. As a result, it is clear why Firefox and Safari are more insecure than IE, it is simply because the code is there to be audited. Frankly, they are all about the same security-wise. William I have a feeling that most of the 'security' problems with firefox is related to extensions/addons/plugins, rather then the firefox application itself. You can't fault the devs for unsupported addons/extensions/plugins that are made by a third party with questionable levels of programming skills. M$ tried this same thing, comparing Linux to Windows vulns, neglecting to mention that the only reason why there was more Linux exploits was because they were including things other then the kernel and base system. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: Anyone see a game changer here?
When did this become slashdot? Sent via BlackBerry from T-Mobile
Re: Anyone see a game changer here?
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 that. You do realize, of course, that IE is recording less than half the security flaw rate of Firefox? (See http://prosecure.netgear.com/community/security-blog/2009/11/web-browser-vulnerability-report---firefox-leads-the-pack-at-44.php) Consider for a moment that both Firefox and Safari are built on open-source code where the code can be audited. As a result, it is clear why Firefox and Safari are more insecure than IE, it is simply because the code is there to be audited. Frankly, they are all about the same security-wise. 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 reviews by people who have the power to say no, you can't ship this. They've also put a lot of effort into building and using security tools. (For earlier comments by me on this subject, see http://www.cs.columbia.edu/~smb/blog/2009-04/2009-04-29.html) I'm not a fan of Windows. I think it's ugly and bloated, and I don't like it as a user environment. I'm typing this on a Mac (which I like for its JFW properties, not its security; I do not think it is more secure than Vista or Windows 7); I'm also a heavy user -- and a developer -- of NetBSD. If the world suddenly switched its OS of choice away from Windows, I wouldn't weep. But I also would and do hope that the other platforms, be they open or closed source, would learn from what Bill Gates has done well. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: Using /31 for router links
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 IPv4 space further. Has anyone else does this? Good? Bad? Based on the bit of testing I've done this shouldn't be a problem since it's only between routers. Yes, this *IS* done *ALL* the time. P-t-P means that there are ONLY two devices on the wire - hence point to point. It ONLY uses two IP addresses (one on each end) and there is no reason or need to ARP on this wire. So no need for a broadcast or network addresses - it is just the two end points. 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
Re: Using /31 for router links
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 only; using Ethernet for WANs and PTP links is the vilest invention in the entire history of data networking in my opinion. My medium of choice for PTP links (WAN) is HDLC over a synchronous serial bit stream, with a V.35 or EIA-530 interface between the router and the modem/DSU. Over HDLC I then run either RFC 1490 routed mode or straight PPP (RFC 1662); in the past I used Cisco HDLC (0F 00 08 00 IP header follows...). My 4.3BSD router (or I should better say gateway as that's the proper 80s/90s term) then sees a PTP interface which has no netmask at all, hence the near and far end IP addresses don't have to have any numerical relationship between them at all. No netmask, no MAC addresses, no ARP, none of that crap, just a PTP IP link. /soapbox MS
RE: Using /31 for router links
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 ARPing but that is nothing unique to a /31. It does eliminate the need for ARP, though.
Re: Using /31 for router links
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 all. soapbox That is why I hate Ethernet with a passion. Ethernet should be for LANs only; using Ethernet for WANs and PTP links is the vilest invention in the entire history of data networking in my opinion. My medium of choice for PTP links (WAN) is HDLC over a synchronous serial bit stream, with a V.35 or EIA-530 interface between the router and the modem/DSU. Over HDLC I then run either RFC 1490 routed mode or straight PPP (RFC 1662); in the past I used Cisco HDLC (0F 00 08 00 IP header follows...). My 4.3BSD router (or I should better say gateway as that's the proper 80s/90s term) then sees a PTP interface which has no netmask at all, hence the near and far end IP addresses don't have to have any numerical relationship between them at all. No netmask, no MAC addresses, no ARP, none of that crap, just a PTP IP link. /soapbox That's not a soapbox, that's a soap factory! What about NAT, ATM cell tax, unnecessary addressing fields in PTP protocols (including your beloved HDLC), SSAP, DSAP fields not being big enough in 802.2 necessitating SNAP, IPX directly over 802.3, AAL1 through AAL4, PPPoE dumbell MTUs and MSS hacks? Some of those are far worse sins in my opinion.
Re: Anyone see a game changer here?
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 reviews by people who have the power to say no, you can't ship this. They've also put a lot of effort into building and using security tools. (For earlier comments by me on this subject, see http://www.cs.columbia.edu/~smb/blog/2009-04/2009-04-29.html) I'm not a fan of Windows. I think it's ugly and bloated, and I don't like it as a user environment. I'm typing this on a Mac (which I like for its JFW properties, not its security; I do not think it is more secure than Vista or Windows 7); I'm also a heavy user -- and a developer -- of NetBSD. If the world suddenly switched its OS of choice away from Windows, I wouldn't weep. But I also would and do hope that the other platforms, be they open or closed source, would learn from what Bill Gates has done well. Microsoft has put a lot into securing its code, and is very good at doing so. My main argument here is about the policy of handling vulnerabilities for 6 months without patching (such as this one apparently was) and the policy of waiting a whole month before patching an in-the-wild 0day exploit. Microsoft is the main proponent of responsible disclosure, and has shown it is a responsible vendor. Also, patching vulnerabilities is far from easy, and Microsoft has done a tremendous job at getting it done. I simply call on it to stay responsible and amend its faulty and dangerous policies. A whole month as the default response to patching a 0day? Really? With their practical monopoly, and the resulting monoculture, perhaps their policies ought to be examined for regulation as critical infrastructure, if they can't bring themselves to be more responsible on their own. This is the first time in a long while that I find it fit to criticize Microsoft on security. Perhaps they have grown complacent with the PR nightmare of full disclosure a decade behind them, with most vulnerabilities now sold to them directly or indirectly by the security industry. Gadi. -- Gadi Evron, g...@linuxbox.org. Blog: http://gevron.livejournal.com/
