[Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
I didn't see this on NANOG yet, but it's caused a stir on the RIPE list. ---BeginMessage--- Dear Colleagues, As you may be aware, the International Telecommunication Union's (ITU) Telecommunication Standardization Bureau (TSB) has convened an ITU IPv6 Group, the first meeting of which will be held on 15-16 March 2010 in Geneva, Switzerland. Information on this group is available at: http://www.itu.int/ITU-T/othergroups/ipv6/ Among the group's Terms of Reference are the following: * To draft a global policy proposal for the reservation of a large IPv6 block, taking into consideration the future needs of developing countries (as outlined in paragraph 23 of ITU document C09/29). * To further study possible methodologies and related implementation mechanisms to ensure 'equitable access' to IPv6 resource by countries. * To further study the possibility for ITU to become another Internet Registry, and propose policies and procedures for ITU to manage a reserved IPv6 block. * To further study the feasibility and advisability of implementing the CIR [Country Internet Registry] model for those countries who would request national allocations. The ITU IPv6 Group is open to ITU Member States and Sector Members of ITU-T and ITU-D. RIRs that are not members have also been extended an invitation to participate. IPv6 address policy is clearly of critical importance to the RIPE NCC membership, and the unsympathetic implementation of any of the Terms of Reference stated above would have serious impact on the global IP address distribution environment. Members of RIPE NCC staff will be participating in this meeting of the ITU IPv6 Group to represent the interests of our members and community. The position of the RIPE NCC is based on support for smooth and reliable working of the Internet globally, and for the bottom-up, open policy development process that allows for all stakeholders, including business, government and the technical community, to participate. Some of the issues addressed in the Terms of Reference listed above are a cause for concern because they could directly affect the RIPE NCC operations as a Regional Internet Registry (RIR). Therefore, the RIPE NCC position on the Terms of Reference is as follows: * The needs of developing economies in IP address policy are important. Network operators in these economies have fair and equal access to IPv6 resources from the Regional Internet Registries (RIRs), and to the Policy Development Processes in their RIR and globally. Each of the RIRs has been allocated an equal block of IPv6 to distribute to networks in their region. (eg. AfriNIC has been allocated the same sized block of IPv6 as the RIPE NCC). * IPv6 allocations made by RIRs to date amount to the equivalent of 500 times the size of the entire IPv4 address pool, allocated to networks in over 150 economies. * If a significant sector in the Internet community feels that the reservation of a large IPv6 block for the future needs of developing countries is warranted, the open, bottom-up Policy Development Processes (PDPs) of the RIRs provide an appropriate forum in which to argue that case and develop such a policy. * The RIRs, as the recognised stewards of Internet Number Resources, are working, individually, jointly, and with invited experts, to engage the ITU membership. We have closely followed discussions in the ITU to date. The RIPE NCC does not believe that there are any problems that would be solved by the shift to a country-based allocation system or the installation of the ITU as an Internet Registry. The purpose of this email is to ensure that all RIPE NCC members are informed of the RIPE NCC's participation in this ITU IPv6 Group, and our position. If you have any comments or questions regarding this information, please send an email to n...@ripe.net. Kind regards, Axel Pawlik Managing Director RIPE NCC If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ First click on General and then click on Edit. At the bottom of the Page you can add or remove addresses. ---End Message---
RE: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
Interesting, why is it causing quite a stir? Is it because they are trying to allocate a large pool of addresses? Date: Fri, 26 Feb 2010 13:03:01 +0100 From: awa...@tuenti.com To: nanog@nanog.org Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] I didn't see this on NANOG yet, but it's caused a stir on the RIPE list. --Forwarded Message Attachment-- From: n...@ripe.net To: ncc-annou...@ripe.net Date: Thu, 25 Feb 2010 17:20:18 +0100 Subject: [Admin] [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group Dear Colleagues, As you may be aware, the International Telecommunication Union's (ITU) Telecommunication Standardization Bureau (TSB) has convened an ITU IPv6 Group, the first meeting of which will be held on 15-16 March 2010 in Geneva, Switzerland. Information on this group is available at: http://www.itu.int/ITU-T/othergroups/ipv6/ Among the group's Terms of Reference are the following: * To draft a global policy proposal for the reservation of a large IPv6 block, taking into consideration the future needs of developing countries (as outlined in paragraph 23 of ITU document C09/29). * To further study possible methodologies and related implementation mechanisms to ensure 'equitable access' to IPv6 resource by countries. * To further study the possibility for ITU to become another Internet Registry, and propose policies and procedures for ITU to manage a reserved IPv6 block. * To further study the feasibility and advisability of implementing the CIR [Country Internet Registry] model for those countries who would request national allocations. The ITU IPv6 Group is open to ITU Member States and Sector Members of ITU-T and ITU-D. RIRs that are not members have also been extended an invitation to participate. IPv6 address policy is clearly of critical importance to the RIPE NCC membership, and the unsympathetic implementation of any of the Terms of Reference stated above would have serious impact on the global IP address distribution environment. Members of RIPE NCC staff will be participating in this meeting of the ITU IPv6 Group to represent the interests of our members and community. The position of the RIPE NCC is based on support for smooth and reliable working of the Internet globally, and for the bottom-up, open policy development process that allows for all stakeholders, including business, government and the technical community, to participate. Some of the issues addressed in the Terms of Reference listed above are a cause for concern because they could directly affect the RIPE NCC operations as a Regional Internet Registry (RIR). Therefore, the RIPE NCC position on the Terms of Reference is as follows: * The needs of developing economies in IP address policy are important. Network operators in these economies have fair and equal access to IPv6 resources from the Regional Internet Registries (RIRs), and to the Policy Development Processes in their RIR and globally. Each of the RIRs has been allocated an equal block of IPv6 to distribute to networks in their region. (eg. AfriNIC has been allocated the same sized block of IPv6 as the RIPE NCC). * IPv6 allocations made by RIRs to date amount to the equivalent of 500 times the size of the entire IPv4 address pool, allocated to networks in over 150 economies. * If a significant sector in the Internet community feels that the reservation of a large IPv6 block for the future needs of developing countries is warranted, the open, bottom-up Policy Development Processes (PDPs) of the RIRs provide an appropriate forum in which to argue that case and develop such a policy. * The RIRs, as the recognised stewards of Internet Number Resources, are working, individually, jointly, and with invited experts, to engage the ITU membership. We have closely followed discussions in the ITU to date. The RIPE NCC does not believe that there are any problems that would be solved by the shift to a country-based allocation system or the installation of the ITU as an Internet Registry. The purpose of this email is to ensure that all RIPE NCC members are informed of the RIPE NCC's participation in this ITU IPv6 Group, and our position. If you have any comments or questions regarding this information, please send an email to n...@ripe.net. Kind regards, Axel Pawlik Managing Director RIPE NCC If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ First click on General and then click on Edit. At the bottom of the Page you can add or remove addresses.
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
On Feb 26, 2010, at 8:47 AM, Brandon Kim wrote: Interesting, why is it causing quite a stir? Is it because they are trying to allocate a large pool of addresses? For those of you that are unaware, it is possible to contact the State Department to get involved with ITU activities and be added to their mailing lists to discuss these positions. - Jared
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
On Feb 26, 2010, at 8:55 AM, Jared Mauch wrote: On Feb 26, 2010, at 8:47 AM, Brandon Kim wrote: Interesting, why is it causing quite a stir? Is it because they are trying to allocate a large pool of addresses? For those of you that are unaware, it is possible to contact the State Department to get involved with ITU activities and be added to their mailing lists to discuss these positions. I, for one, did not know this. The State Department is a rather large organization. Can you provide a link or a reference to the appropriate way to do this ? Regards Marshall - Jared
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
Subject: RE: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU?IPv6 Group] Date: Fri, Feb 26, 2010 at 08:47:57AM -0500 Quoting Brandon Kim (brandon@brandontek.com): Interesting, why is it causing quite a stir? Is it because they are trying to allocate a large pool of addresses? The ITU is sulking because noone cares about them anymore; everybody just runs IP instead of being obedient Phone Company customers and using E.164 numbers. By becoming provider of IPv6 space the ITU hopes to restore the notion of country code addresses and also to again become a power factor in datacom. It is no coincidence that this wacky idea centers around developing countries; since one country -- one vote still is the norm for much ITU work this is a way to move power distribution back from an economy driven model (where actual usage and amount of money invested in operations matter) to a national-state model where Internet-heavy information economies like North Korea or Bangladesh have equal voting rights as USA or Japan. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Will the third world war keep Bosom Buddies off the air? pgpaVirzJhz2x.pgp Description: PGP signature
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
Interesting, why is it causing quite a stir? Is it because they are trying to allocate a large pool of addresses? ITU is trying to stay relevant and justify its existence, over the years they have been loosing their grip over telecom and networking standards. This last move to grab a chunk of IPv6 address space and become a registry does not have any valid justification and some of the reasons they have been crying out load at the IGF and ICANN meetings, all circle around ICANN's monopoly and USG control of some network resources. There is an ecosystem that grew up around these organizations where too many people/corporations are milking from and everybody wants to be in control of (or have a part of it) the cows. I don't know if already happened but ethernet (local, metro, wide) and TCP/IP are probably today the most deployed data communication technologies, add VoIP, keep few of the encoding and mobile (for a while) standards and I guess nobody needs ITU-T anymore, or do we ? Cheers Jorge
Euro-IX ASN Tools updated
After several peering community requests we have now extended our ASN tool set to allow searches on not only European IXP participants but also those in other regions. The Euro-IX ASN database has some 9.200 entries of participants from 280 IXPs from around the globe. The data stored in our ASN database is a culmination of our member IXPs updating their records, all relevant entries from the peeringDB and me trawling through the rest of the IXP websites. I don't claim that this set of data is exhaustive but we do our very best! The data stored looks something like this. Europe: IXP Participants - 5,383 Unique ASNs - 2,952 Asia-Pacific: IXP Participants - 1,102 Unique ASNs - 635 North America: IXP Participants - 2,015 Unique ASNs - 832 South America: IXP Participants - 274 Unique ASNs - 158 Africa: IXP Participants - 199 Unique ASNs - 111 Global: IXP Participants - 9,199 Unique ASNs - 4,519 So you can get a closer look at these ASNs by searching in the Euro-IX ASN database: https://www.euro-ix.net/member/m/isp/choosing/ixpmembers/search Or having look at the ASN filter that now includes all 280 IXPs: https://www.euro-ix.net/member/m/asnfilter And for fun we have a list of ASNs that peer at 10 or more IXPs globally: https://www.euro-ix.net/multixp.php I will be at APRICOT 2010 KL from this Sunday to Wednesday if anyone wants to chat with me about this data. Serge
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
On Feb 26, 2010, at 9:19 AM, Marshall Eubanks wrote: On Feb 26, 2010, at 8:55 AM, Jared Mauch wrote: On Feb 26, 2010, at 8:47 AM, Brandon Kim wrote: Interesting, why is it causing quite a stir? Is it because they are trying to allocate a large pool of addresses? For those of you that are unaware, it is possible to contact the State Department to get involved with ITU activities and be added to their mailing lists to discuss these positions. I, for one, did not know this. The State Department is a rather large organization. Can you provide a link or a reference to the appropriate way to do this ? Regards Marshall Hi Marshall, Contact Anne Jillson and she'll set you up. Cheers, TV Begin forwarded message: From: Jillson, Anne D jillso...@state.gov Date: January 4, 2010 12:05:16 PM EST To: i...@lmlist.state.gov Subject: [ITAC] U.S. Delegation for the ITU Council Working Group Meetings, Jan. 25 - Feb. 5, Geneva Reply-To: Jillson, Anne D jillso...@state.gov We need to start forming the U.S. Delegation to the ITU Council Working Group Meetings that begin in three weeks in Geneva. If you are interested in being part of the U.S. delegation, please reply to jillso...@state.gov no later than this Friday, Jan. 8.Please indicate if you only plan to participate in some of the meetings. Thanks. Anne Anne Jillson International Communications and Information Policy EEB/CIP/MA ASRC Management Services Contractor Department of State Tel: 202-647-2592 Fax: 202-647-7407
Re: ISP in Johannesburg in Southdafrika
On 2010-02-26 00:41, Graham Beneke wrote: On 26/02/2010 04:08, Randy Bush wrote: Internet connectivity here in 'deepest darkest Africa' is actually quite advanced ;-) and the most expensive you can imagine. welcome to a telkom monopoly. The monopoly is over! how many carriers with international fiber? randy
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
For those of you that are unaware, it is possible to contact the State Department to get involved with ITU activities and be added to their mailing lists to discuss these positions. In addition, if you work for a largish company, they probably have a regulatory department which may already have someone involved in ITU standardisation activities, or already involved with the State Department, or involved with the FCC. So it would be a good idea to hunt around internally (contact legal and ask them if they know of anyone dealing with regulatory issues) and then liaise with that person. In particular, if your employer is a telco, it is unlikely that the regulatory liaison knows anything about the self-regulatory RIR system, and maybe some education is in order. I believe the ITU intends to set themselves up as an alternative to the RIRs with a large IANA allocation, if they can get it. --Michael Dillon
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
On Fri, 2010-02-26 at 09:40 -0600, Jorge Amodio wrote: I guess nobody needs ITU-T anymore, or do we ? ZCZC well, from vague memory, H.264, G711/729, H323, X.509 were/are ITU-T standards - maybe X.25 too though I could have that one wrong. I'll just sit on the fence: as an old radiocomms guy, I'd say ITU-_R_ is still very relevant if you guys DON'T want to watch/listen N. Korean or Bangladeshi TV/radio on your home Sat systems or car radios, to name a couple of recently quoted countries :) But ITU-T? That's one for the VoIP guys to shout about. de Gord
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
On Feb 26, 2010, at 11:29 AM, Tom Vest wrote: On Feb 26, 2010, at 9:19 AM, Marshall Eubanks wrote: On Feb 26, 2010, at 8:55 AM, Jared Mauch wrote: On Feb 26, 2010, at 8:47 AM, Brandon Kim wrote: Interesting, why is it causing quite a stir? Is it because they are trying to allocate a large pool of addresses? For those of you that are unaware, it is possible to contact the State Department to get involved with ITU activities and be added to their mailing lists to discuss these positions. I, for one, did not know this. The State Department is a rather large organization. Can you provide a link or a reference to the appropriate way to do this ? Regards Marshall Hi Marshall, Contact Anne Jillson and she'll set you up. Cheers, Dear Tom; Thank you very much. Is there a list of these mailing lists anywhere ? Regards Marshall TV Begin forwarded message: From: Jillson, Anne D jillso...@state.gov Date: January 4, 2010 12:05:16 PM EST To: i...@lmlist.state.gov Subject: [ITAC] U.S. Delegation for the ITU Council Working Group Meetings, Jan. 25 - Feb. 5, Geneva Reply-To: Jillson, Anne D jillso...@state.gov We need to start forming the U.S. Delegation to the ITU Council Working Group Meetings that begin in three weeks in Geneva. If you are interested in being part of the U.S. delegation, please reply to jillso...@state.gov no later than this Friday, Jan. 8.Please indicate if you only plan to participate in some of the meetings. Thanks. Anne Anne Jillson International Communications and Information Policy EEB/CIP/MA ASRC Management Services Contractor Department of State Tel: 202-647-2592 Fax: 202-647-7407
MENOG6 Call for Papers
Colleagues thought it would be useful to send this to few lists who have interest in doing / extending their business in Middle East. Looking forward to see you all in Riyadh! Mehmet Akcin / MENOG Programme Committee Middle East Network Operators Group (MENOG) Riyadh, Saudi Arabia 10 - 14 April 2010 http://www.menog.net Call for Papers The MENOG Programme Committee is now seeking contributions to the programme for MENOG 6. We would like to invite people to submit their presentation proposals as soon as possible to help us produce the programme in a timely fashion. We would also like to encourage people through out the Middle East region who have not previously presented their work to do so. We are looking for people who would : * Offer a technical tutorial on an appropriate topic; and/or * Participate in the technical conference sessions as a speaker. * Share their local experience with any of the fields of interest for MENOG. Presentation proposals can be submitted at: http://submission.menog.net/paper/user/login.php?event=23 MENOG 6 FORMAT -- MENOG 6 will run for 5 days, and will include 3 days of hands-on technical workshops, followed by Opening and Closing Plenaries, several Technical Conference sessions including updates from the RIPE NCC, as well half a day of tutorials. Workshop 10th-12th Tutorials 13th (morning) Conference13th (afternoon) and 14th CONFERENCE MILESTONES - Call for Papers Opens: now Deadline for Speaker Submissions: 15th March 2010 Final Slides: 10th April 2010 Final Programme Published: 22nd March 2010 TECHNICAL CONFERENCE Each Technical session in MENOG will last 90 minutes - multiple sessions can be cover one subject area if there is demand. A 90 minute session allows presentations to be up to 25 minutes in length, meaning 3 presentations per session and some time for QA. Longer presentations should be submitted as tutorials. The Technical Conference commences after lunchtime on the 13th of April. Expected subject areas for MENOG 6 include: 1. HTTP and Non-HTTP Content Filtering; Anti-spam 2 Internationalised Domain Names (IDN) and Localisation 3. NREN (National Research and Education Networks) 4. ISP Operations, Peering and Internet Exchange Points 5. SP Network Security 6. IPv4 depletion/IPv6 deployment 7. Datacentres, Applications Services 8. VSAT technologies TUTORIALS -- Tutorials are 90 minute technical presentations which focus on a particular subject in-depth. Tutorials will take place on the morning of the 13th of April. Tutorial Instructors are encouraged to also sign up to be a Speaker in the Technical Conference Programme as well. You can sign up to give a tutorial and/or conference session presentation by following the instructions at the end of this message for signing up as a speaker or instructor. Examples of Tutorial topics might be: - Network security, IPSec, Auditing/Forensics, DDoS Mitigation - Routing, Network Design, BGP - IPv6 deployment - IDN, Localisation - Content filtering anti-spam - Network planning, management and traffic engineering - Internet exchanges, construction, peering and collocation - Operations, NOC, Helpdesk and other support aspects - DNS and DNSSEC If you have an idea for a tutorial subject that is not listed, please feel free to submit it to us. CFP SUBMISSION -- When considering a presentation or tutorial, remember that the MENOG audience is mainly comprised of technical network operators and engineers with a wide range of experience levels from beginners to multi-year experience. There is a strong orientation to offer core skills and basic knowledge in the tutorials and to address issues relevant to the day-to-day operations of ISPs and network operators over the next 12 - 18 months in the conference sessions. Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions. The Programme Committee cannot consider a presentation proposal without accompanying draft slides. While the majority of speaking slots will be allocated by 15th of March 2010, a limited number of slots may be available after then for presentations that are exceptionally timely, important, or of critical operational importance. IMPORTANT NOTE -- MENOG is a TECHNICAL conference so marketing and commercial content is not allowed within the programme. The programme committee will maintain the technical standard of MENOG, and will therefore not accept inappropriate materials. It is expected that the presenter be a technical person and not a sales or marketing person. The audience is extremely technical and expects that the speakers are themselves very knowledgeable. All sessions provide time for questions, so presenters should expect technical questions and be prepared to deliver insightful and technically
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
From: gordon b slater gordsla...@ieee.org Date: Fri, 26 Feb 2010 16:52:21 + On Fri, 2010-02-26 at 09:40 -0600, Jorge Amodio wrote: I guess nobody needs ITU-T anymore, or do we ? ZCZC well, from vague memory, H.264, G711/729, H323, X.509 were/are ITU-T standards - maybe X.25 too though I could have that one wrong. I'll just sit on the fence: as an old radiocomms guy, I'd say ITU-_R_ is still very relevant if you guys DON'T want to watch/listen N. Korean or Bangladeshi TV/radio on your home Sat systems or car radios, to name a couple of recently quoted countries :) But ITU-T? That's one for the VoIP guys to shout about. No, it is one for everyone who does networking to shout about! ITU is exactly the sort of organization I DON'T want to see in control of the Internet. If you think IETF has gotten to unmanageable, wait until you deal with the ITU-T. It is VERY lawyer heavy. I had to attend some X.400/X.500 meetings and, while the lawyers were never running anything, most of the technical people could only speak through the lawyers and the suits out-numbered the techies by almost two to one. And this was a low-level working group. I understand it gets worse as you move up the ladder. The network revolution has left the ITU-T very little to do (at least compared to the old telco days) and they show every sign of wanting to bring all of us wild IP folks under control. Oh, and X.25 and X.509 are from an older organization that merged into the ITU-T when it was created, the CCITT (International Telegraph and Telephone Consultative Committee). It became the ITU-T in 1992. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: ISP in Johannesburg in Southdafrika
On 26/02/2010 18:43, Randy Bush wrote: On 2010-02-26 00:41, Graham Beneke wrote: On 26/02/2010 04:08, Randy Bush wrote: Internet connectivity here in 'deepest darkest Africa' is actually quite advanced ;-) and the most expensive you can imagine. welcome to a telkom monopoly. The monopoly is over! how many carriers with international fiber? I can think of six operators lighting their own fiber to the borders and the landing stations of the various cable systems. Additional to that - I know of dozens of operators running their own international L2 circuits and lighting their own metro and national fiber. Its still early days and there much work still left to do before the effects of the past monopoly is fully overcome. Why is it so hard for you to believe that things are changing for the better? -- Graham Beneke
Re: Spamcop Blocks Facebook?
Shon Elliott s...@unwiredbb.com writes: Feb 25 19:08:18 postfix/smtpd[12682]: NOQUEUE: reject: RCPT from outmail011.snc1.tfbnw.net[69.63.178.170]: 554 5.7.1 Service unavailable; host [69.63.178.170] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?69.63.178.170; Using the Spamcop BL *solely* as the basis for rejecting mail is a sure way to lose wanted email. From Spamcop's website: ... SpamCop encourages use of the SCBL in concert with an actively maintained whitelist of wanted email senders. SpamCop encourages SCBL users to tag and divert email, rather than block it outright. The SCBL is aggressive and often errs on the side of blocking mail... Many mailservers operate with blacklists in a tag only mode, which is preferable in many situations. IMO, the best use of the SCBL is as a scoring metric with Spam Assassin. Additional discussion should be directed to SPAM-L. -- Bob Poortinga K9SQLhttp://www.linkedin.com/in/bobpoortinga Bloomington, Indiana US
Re: ISP in Johannesburg in Southdafrika
I can think of six operators lighting their own fiber to the borders and the landing stations of the various cable systems. Additional to that - I know of dozens of operators running their own international L2 circuits and lighting their own metro and national fiber. no intl L1? Why is it so hard for you to believe that things are changing for the better? because i have dealt with the effects of that particular monopoly for over twenty years. and it has been among the most pernicious in africa. randy
Re: Spamcop Blocks Facebook?
On 2/26/10 9:56 AM, Bob Poortinga wrote: Shon Elliott s...@unwiredbb.com writes: Feb 25 19:08:18 postfix/smtpd[12682]: NOQUEUE: reject: RCPT from outmail011.snc1.tfbnw.net[69.63.178.170]: 554 5.7.1 Service unavailable; host [69.63.178.170] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?69.63.178.170; Using the Spamcop BL *solely* as the basis for rejecting mail is a sure way to lose wanted email. From Spamcop's website: ... SpamCop encourages use of the SCBL in concert with an actively maintained whitelist of wanted email senders. SpamCop encourages SCBL users to tag and divert email, rather than block it outright. The SCBL is aggressive and often errs on the side of blocking mail... Many mailservers operate with blacklists in a tag only mode, which is preferable in many situations. IMO, the best use of the SCBL is as a scoring metric with Spam Assassin. Additional discussion should be directed to SPAM-L. In the early days of spamcop I'd agree with you unconditionally, but over the years they've become much better to the point where I'd argue it's suitable for blocking. In the case of Facebook it certainly is; if they're is feeding spamtraps with enough volume to merit a listing then it is wholeheartedly deserved. ~Seth
Fwd: Comcast IPv6 Trials Update
Received this message today. They haven't updated the http://www.comcast6.net/ site yet. Mike Begin forwarded message: An Important Message From Comcast Dear Comcast Customer, Thank you for volunteering to participate in Comcast's IPv6 trials! I wanted to provide you with a quick update on what our next steps are and when you can expect to hear from us again. As you know, we have four trials described at http://www.comcast6.net. We're in detailed planning on the first three: 6RD, plus native dual-stack for residential and for commercial customers. We expect each of these to start sometime within the next 90 days or so. 6RD Trial: We anticipate having customers from around our network, not limited to any specific areas, participate. We will start the trial on a very small scale and then progressively increase the number of participants. We plan to ship a new home gateway device to each trial participant. Residential Native Dual-Stack Trial: This trial will be limited to a few areas in our network. We are in the midst of determining precisely what those areas will be, based on where we have volunteers and where the infrastructure will be ready. If trial participants do not have an IPv6-capable home gateway and cable modem, one will be provided. Commercial Native Dual-Stack Trial: This trial will be limited to a few areas in our network. We have tentatively identified these trial areas and will soon be in touch with potential trial users. Within approximately the next 30 days we will begin to contact some of our volunteers regarding each of these trials, so expect to hear from us soon. Thanks again for your interest! Regards Jason Livingood Internet Systems Engineering Comcast
Re: ISP in Johannesburg in Southdafrika
Why is it so hard for you to believe that things are changing for the better? http://www.hellkom.co.za/ http://www.ispa.org.za/ http://www.ispa.org.za/press-release/ispa-calls-on-icasa-to-make-a-firm-commitment-to-llu randy
Re: Future timestamps in /var/log/secure
On 2/26/10 11:20 AM, Wade Peacock wrote: I found a while ago in /var/log/secure that for an invalid ssh login attempt the ssh Bye Bye line is in the future. I have searched the web and can not find a reason for the future time in the log. Here is a sample. Repeated lines are shown once in first part Feb 26 17:50:38 mx sshd[19115]: Received disconnect from 210.212.145.152: 11: Bye Bye Feb 26 17:50:38 mx sshd[19118]: Received disconnect from 210.212.145.152: 11: Bye Bye Feb 26 09:52:39 mx proftpd[17297]: mx.example.com (208.xxx.xxx.xxx[208.xxx.xxx.xxx]) - FTP no transfer timeout, disconnected Can anyone explain the future time stamp on the Bye Bye lines? OS is Centos 5.4, FYI Isn't the timestamps inserted by syslog rather then the reporting program itself? What syslog do you use - classic (ie: sysklogd) or a modern one like rsyslog? It almost looks like the timezone got changed from local to GMT or similar, then swapped back (as odd as it may sound). Perhaps time to file a bug report with the author of the syslog daemon you use? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
RE: Comcast IPv6 Trials Update
Wow that's great, hopefully Cablevision will do the same with their optimum online!!! From: mich...@thegrebs.com Subject: Fwd: Comcast IPv6 Trials Update Date: Fri, 26 Feb 2010 13:15:45 -0500 To: nanog@nanog.org Received this message today. They haven't updated the http://www.comcast6.net/ site yet. Mike Begin forwarded message: An Important Message From Comcast Dear Comcast Customer, Thank you for volunteering to participate in Comcast's IPv6 trials! I wanted to provide you with a quick update on what our next steps are and when you can expect to hear from us again. As you know, we have four trials described at http://www.comcast6.net. We're in detailed planning on the first three: 6RD, plus native dual-stack for residential and for commercial customers. We expect each of these to start sometime within the next 90 days or so. 6RD Trial: We anticipate having customers from around our network, not limited to any specific areas, participate. We will start the trial on a very small scale and then progressively increase the number of participants. We plan to ship a new home gateway device to each trial participant. Residential Native Dual-Stack Trial: This trial will be limited to a few areas in our network. We are in the midst of determining precisely what those areas will be, based on where we have volunteers and where the infrastructure will be ready. If trial participants do not have an IPv6-capable home gateway and cable modem, one will be provided. Commercial Native Dual-Stack Trial: This trial will be limited to a few areas in our network. We have tentatively identified these trial areas and will soon be in touch with potential trial users. Within approximately the next 30 days we will begin to contact some of our volunteers regarding each of these trials, so expect to hear from us soon. Thanks again for your interest! Regards Jason Livingood Internet Systems Engineering Comcast
Re: Future timestamps in /var/log/secure
On 2/26/2010 12:29 PM, Brielle Bruns wrote: On 2/26/10 11:20 AM, Wade Peacock wrote: I found a while ago in /var/log/secure that for an invalid ssh login attempt the ssh Bye Bye line is in the future. I have searched the web and can not find a reason for the future time in the log. Here is a sample. Repeated lines are shown once in first part Feb 26 17:50:38 mx sshd[19115]: Received disconnect from 210.212.145.152: 11: Bye Bye Feb 26 17:50:38 mx sshd[19118]: Received disconnect from 210.212.145.152: 11: Bye Bye Feb 26 09:52:39 mx proftpd[17297]: mx.example.com (208.xxx.xxx.xxx[208.xxx.xxx.xxx]) - FTP no transfer timeout, disconnected Can anyone explain the future time stamp on the Bye Bye lines? OS is Centos 5.4, FYI Isn't the timestamps inserted by syslog rather then the reporting program itself? What syslog do you use - classic (ie: sysklogd) or a modern one like rsyslog? It almost looks like the timezone got changed from local to GMT or similar, then swapped back (as odd as it may sound). Perhaps time to file a bug report with the author of the syslog daemon you use? Been a long time since I've dealt with this stuff, but it looks like the shell for proftpd has a different TZ from the one running the other stuff. (syslogd runs in the shell of the caller, right?) -- Government big enough to supply everything you need is big enough to take everything you have. Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
On Feb 26, 2010, at 10:22 AM, gordon b slater wrote: I must admit to total confusion over why they need to grab IPs from the v6 address space? Surely they don't need the equivalent of band-plans for IP space? Or have I missed some v6 technical point totally? The ITU Secretariat and a few member states (Syria being the most frequent) point to the inequality of distribution of IPv4 space and argue that developing countries must not be left out of IPv6 the same way. They have also suggested that the establishment of Country Internet Registries (that is, national PTT-based allocation registries) could provide competition for the RIRs, thereby using market forces to improve address allocation services. (Please note that I am not commenting on these proposals, merely trying to summarize them in a non-biased way). There are a couple of papers put out by the ITU (or perhaps more accurately, ITU-funded folks) that discuss this. If anyone cares, I can dig them up. There is much political froth being stirred up here. Regards, -drc
Re: ISP in Johannesburg in Southdafrika
On Fri, Feb 26, 2010 at 8:17 PM, Randy Bush ra...@psg.com wrote: Why is it so hard for you to believe that things are changing for the better? http://www.hellkom.co.za/ http://www.ispa.org.za/ http://www.ispa.org.za/press-release/ispa-calls-on-icasa-to-make-a-firm-commitment-to-llu Hi Randy, Those are all _extremely_ out dated references. The reality is here though. Personally, for the last 12 months I have not paid a single cent to Telkom. Not one of my packets traverses a single Telkom owned piece of equipment. In fact, as I type this email I'm enjoying a lovely secluded beach holiday on the south coast with 7Mbps HSDPA (which really is clocking 7Mbps) and paying about $10 per GB - and none of those bytes go via Telkom either. Yes, you envy me, you can admit it ;) Numerous ISP's have Seacom STM-1 circuits to an international peering point of their choice, doing last mile over their own metro fibre or wireless. While we all appreciate outrage from across the pond, it's important to keep in touch with change. . Africa is no longer dark - but it can still be cheaper. Regards, CA
RE: Future timestamps in /var/log/secure
I happend upon this ( https://bugzilla.redhat.com/show_bug.cgi?id=193184 ) which seems to suggest/explain the occurrence. I know it was mentioned to be in the CentOS distro, but I think this might have been adopted into that distro as well since I see the same issues on a RedHat Distro. Not sure if the article helps or hinders but good food for thought. -Joe Blanchard -Original Message- From: Brielle Bruns [mailto:br...@2mbit.com] Sent: Friday, February 26, 2010 1:29 PM To: nanog@nanog.org Subject: Re: Future timestamps in /var/log/secure On 2/26/10 11:20 AM, Wade Peacock wrote: I found a while ago in /var/log/secure that for an invalid ssh login attempt the ssh Bye Bye line is in the future. I have searched the web and can not find a reason for the future time in the log. Here is a sample. Repeated lines are shown once in first part Feb 26 17:50:38 mx sshd[19115]: Received disconnect from 210.212.145.152: 11: Bye Bye Feb 26 17:50:38 mx sshd[19118]: Received disconnect from 210.212.145.152: 11: Bye Bye Feb 26 09:52:39 mx proftpd[17297]: mx.example.com (208.xxx.xxx.xxx[208.xxx.xxx.xxx]) - FTP no transfer timeout, disconnected Can anyone explain the future time stamp on the Bye Bye lines? OS is Centos 5.4, FYI Isn't the timestamps inserted by syslog rather then the reporting program itself? What syslog do you use - classic (ie: sysklogd) or a modern one like rsyslog? It almost looks like the timezone got changed from local to GMT or similar, then swapped back (as odd as it may sound). Perhaps time to file a bug report with the author of the syslog daemon you use? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
well, from vague memory, H.264, G711/729, H323, X.509 were/are ITU-T standards - maybe X.25 too though I could have that one wrong. Some of the encoding stds are not that bad. The X series and colored books are from the CCITT era, that BTW given that they were Recommendations many phone companies and equipment vendors didn't give a squat and implemented them as they pleased, interoperability was a challenge and sort of an art of the dark ages of telecommunications. I still remember getting my butt smoked trying to get a derivate Spanish implementation of X.25 talking with the Turkish one. ITU has nothing to do with managing Internet address and name space, if they want to go back to the dark ages of networking they can build their own network and use CLNP or RSCS ala BITNET. Cheers Jorge
Re: Future timestamps in /var/log/secure
On Fri, 2010-02-26 at 11:29 -0700, Brielle Bruns wrote: Isn't the timestamps inserted by syslog rather then the reporting program itself? that's my understanding also (clarification: syslogs of your server have timestamps of your syslegsserver's time, IMHO) eg: on my Debain systems I don't split the logging to /var/log/secure, I can usually handle a large log OK, but it's easy enough to get the authpriv* stuff to log to /v/l/secure if needed. So, my point is, syslogd.conf tells syslogd where to put them, and it stamps the time for each entry. What syslog do you use - classic (ie: sysklogd) or a modern one like rsyslog? It almost looks like the timezone got changed from local to GMT or similar, then swapped back (as odd as it may sound). On a cautionary note, I've seen tz-change shenanigans to mask unauthorised access before, so might be a good time to have quick poke around with a tinfoil hat on, just in case. Don't have a heart attack tough, not yet :) Gord -- this .sig space reserved by ITU-T pending clarification of intentions
Re: Future timestamps in /var/log/secure
It is classic syslogd syslogd -v syslogd 1.4.1 I was thinking timezone but we are PST (-8:00) so I can not explain the +12:00 difference. Isn't the timestamps inserted by syslog rather then the reporting program itself? What syslog do you use - classic (ie: sysklogd) or a modern one like rsyslog? It almost looks like the timezone got changed from local to GMT or similar, then swapped back (as odd as it may sound). Perhaps time to file a bug report with the author of the syslog daemon you use?
Re: Future timestamps in /var/log/secure
the proftpd line happened to be the next line in the log. the next simular ssh lines looks like (duplicate removed) Feb 26 10:08:48 mx sshd[22165]: Did not receive identification string from UNKNOWN Feb 26 10:09:27 mx sshd[22261]: Failed password for root from 219.137.192.231 port 54111 ssh2 Been a long time since I've dealt with this stuff, but it looks like the shell for proftpd has a different TZ from the one running the other stuff. (syslogd runs in the shell of the caller, right?)
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 pfsi...@gmail.com. Routing Table Report 04:00 +10GMT Sat 27 Feb, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 312233 Prefixes after maximum aggregation: 144486 Deaggregation factor: 2.16 Unique aggregates announced to Internet: 153304 Total ASes present in the Internet Routing Table: 33408 Prefixes per ASN: 9.35 Origin-only ASes present in the Internet Routing Table: 29005 Origin ASes announcing only one prefix: 14141 Transit ASes present in the Internet Routing Table:4403 Transit-only ASes present in the Internet Routing Table:100 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 22 Max AS path prepend of ASN (32374) 19 Prefixes from unregistered ASNs in the Routing Table: 883 Unregistered ASNs in the Routing Table: 140 Number of 32-bit ASNs allocated by the RIRs:447 Prefixes from 32-bit ASNs in the Routing Table: 433 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:235 Number of addresses announced to Internet: 2208633792 Equivalent to 131 /8s, 165 /16s and 19 /24s Percentage of available address space announced: 59.6 Percentage of allocated address space announced: 66.2 Percentage of available address space allocated: 90.0 Percentage of address space in use by end-sites: 81.2 Total number of prefixes smaller than registry allocations: 150079 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:75132 Total APNIC prefixes after maximum aggregation: 25995 APNIC Deaggregation factor:2.89 Prefixes being announced from the APNIC address blocks: 71811 Unique aggregates announced from the APNIC address blocks:31790 APNIC Region origin ASes present in the Internet Routing Table:3970 APNIC Prefixes per ASN: 18.09 APNIC Region origin ASes announcing only one prefix: 1083 APNIC Region transit ASes present in the Internet Routing Table:624 Average APNIC Region AS path length visible:3.6 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 513310752 Equivalent to 30 /8s, 152 /16s and 128 /24s Percentage of available APNIC address space announced: 80.5 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:130267 Total ARIN prefixes after maximum aggregation:67799 ARIN Deaggregation factor: 1.92 Prefixes being announced from the ARIN address blocks: 104360 Unique aggregates announced from the ARIN address blocks: 39769 ARIN Region origin ASes present in the Internet Routing Table:13524 ARIN Prefixes per ASN: 7.72 ARIN Region origin ASes announcing only one prefix:5222 ARIN Region transit ASes present in the Internet Routing Table:1335 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 739540256 Equivalent to 44 /8s, 20 /16s and 125 /24s Percentage of available ARIN address space
Re: Future timestamps in /var/log/secure
On Fri, 2010-02-26 at 11:29 -0700, Brielle Bruns wrote: Isn't the timestamps inserted by syslog rather then the reporting program itself? The syslog message sent to the local unix socket (/dev/log or /dev/syslog) may contain a timestamp, in which case, that timestamp may be used instead of the local time. As the syslog protocol defines that timestamps are localtime, without any specification of what timezone localtime actually is, the TZ environment variable of the application calling syslog() will affect the timestamp placed in the log. William
Re: Future timestamps in /var/log/secure
On Fri, 2010-02-26 at 10:55 -0800, Wade Peacock wrote: the proftpd line happened to be the next line in the log. the next simular ssh lines looks like (duplicate removed) Feb 26 10:08:48 mx sshd[22165]: Did not receive identification string from UNKNOWN Feb 26 10:09:27 mx sshd[22261]: Failed password for root from 219.137.192.231 port 54111 ssh2 is it possible that a local user changed the time (maybe with a GUI app) around the time of these attempts? (failed attempts like this are normal for a machine hooked to the internet without ACLs BTW, the problem is the strange timestamp for the benefit of casual onlookers in the thread) Gord -- latest ITU-T declaration: all syslogs must show timestamps in Geneva time
Re: Future timestamps in /var/log/secure
If someone wants to do testing, I believe I can fairly easily build a Xen CentOS domU once I get home (30 mins). Contact me offlist and we'll figure it out. --Original Message-- From: gordon b slater To: wade.peac...@sunwave.net Cc: nanog@nanog.org ReplyTo: gordsla...@ieee.org Subject: Re: Future timestamps in /var/log/secure Sent: Feb 26, 2010 12:23 PM On Fri, 2010-02-26 at 10:51 -0800, Wade Peacock wrote: I was thinking timezone but we are PST (-8:00) so I can not explain the +12:00 difference. whois gives India? 12 hrs maybe? From a brief recon of it looks a bit, shall we say, soft - get your hat on just in case. I can confirm that changing my time on the ssh client machine end does not reproduce this on my Debain machines, no matter where the entries are logged to. Sorry I don't have any RH/Centos I can test with at this time of day, even virtualised - anyone ? Gord -- incoming! -- Brielle Bruns http://www.sosdg.org / http://www.ahbl.org
Re: Future timestamps in /var/log/secure
On Fri, 2010-02-26 at 13:17 -0600, William Pitcock wrote: On Fri, 2010-02-26 at 11:29 -0700, Brielle Bruns wrote: Isn't the timestamps inserted by syslog rather then the reporting program itself? The syslog message sent to the local unix socket (/dev/log or /dev/syslog) may contain a timestamp, in which case, that timestamp may be used instead of the local time. As the syslog protocol defines that timestamps are localtime, without any specification of what timezone localtime actually is, the TZ environment variable of the application calling syslog() will affect the timestamp placed in the log. aha! there you go, mine doesn't but maybe yours does? Gord -- tic toc
Re: Future timestamps in /var/log/secure
On Fri, 26 Feb 2010 10:51:43 PST, Wade Peacock said: It is classic syslogd syslogd -v syslogd 1.4.1 I was thinking timezone but we are PST (-8:00) so I can not explain the +12:00 difference. Feb 26 09:50:38 mx sshd[19102]: Feb 26 17:50:38 mx sshd[19113]: That's 8 hours difference, one logged in UTC, one in local. Where do you see +12? pgp58vMmMVTIO.pgp Description: PGP signature
Re: Future timestamps in /var/log/secure
On Fri, 2010-02-26 at 19:30 +, gordon b slater wrote: On Fri, 2010-02-26 at 13:17 -0600, William Pitcock wrote: The syslog message sent to the local unix socket (/dev/log or /dev/syslog) may contain a timestamp, in which case, that timestamp may be used instead of the local time. As the syslog protocol defines that timestamps are localtime, without any specification of what timezone localtime actually is, the TZ environment variable of the application calling syslog() will affect the timestamp placed in the log. aha! there you go, mine doesn't but maybe yours does? The specification for the syslog protocol is that timestamps embedded in the message should be used instead of syslogd's time. Most syslog daemons as a result apply this concept to both local and remote messages. You have to keep in mind that syslogd can also send/receive messages to/from remote destinations. William
Re: Future timestamps in /var/log/secure
On 2/26/2010 11:46, William Pitcock wrote: On Fri, 2010-02-26 at 19:30 +, gordon b slater wrote: On Fri, 2010-02-26 at 13:17 -0600, William Pitcock wrote: The syslog message sent to the local unix socket (/dev/log or /dev/syslog) may contain a timestamp, in which case, that timestamp may be used instead of the local time. As the syslog protocol defines that timestamps are localtime, without any specification of what timezone localtime actually is, the TZ environment variable of the application calling syslog() will affect the timestamp placed in the log. aha! there you go, mine doesn't but maybe yours does? The specification for the syslog protocol is that timestamps embedded in the message should be used instead of syslogd's time. Most syslog daemons as a result apply this concept to both local and remote messages. You have to keep in mind that syslogd can also send/receive messages to/from remote destinations. It's easier to see these timezone issues when using an ISO timestamp like 2010-02-26T06:26:17-08:00 instead of the old style that omits the timezone. ~Seth
Re: Future timestamps in /var/log/secure
It might be prudent to mention that all of the connections of this type are null routed via an iptables drop rule after three failed attempts via a home grown daemon similar to DENYHOSTS. All traffic from host is DENIED for 120 days unless we manually over ride it. I do appreciate the cautionary, better have a look around just to be sure comments Wade
Re: Future timestamps in /var/log/secure
That does make sense. I will try to simulate that with a temporary virtual machine as a different timezone. Wade aha! there you go, mine doesn't but maybe yours does? The specification for the syslog protocol is that timestamps embedded in the message should be used instead of syslogd's time. Most syslog daemons as a result apply this concept to both local and remote messages. You have to keep in mind that syslogd can also send/receive messages to/from remote destinations. William
Re: ISP in Johannesburg in Southdafrika
http://www.ispa.org.za/press-release/ispa-calls-on-icasa-to-make-a-firm-commitment-to-llu Those are all _extremely_ out dated references. i am used to dealing with time zones, even the international date line. but i am having a really hard time considering 2010-02-23 as extremely out of date. guys, yes things have changed a bit there. and after decades of being in the 1800s i can see you getting great joy out of seeing telkom dragged kicking and screaming into the 20th century. congratulations. randy
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
On Fri, 26 Feb 2010, David Conrad wrote: non-biased way). There are a couple of papers put out by the ITU (or perhaps more accurately, ITU-funded folks) that discuss this. If anyone cares, I can dig them up. Some googling for 'itu ipv6' turns up the following (among other things): http://www.itu.int/net/ITU-T/ipv6/itudocs.aspx Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.net
Locations with no good Internet (was ISP in Johannesburg)
Daniel Senie d...@senie.com wrote: Better than western Massachusetts, where there's just no connectivity at = all. Even dialup fails to function over crappy lines. Hmm. Although I've never been to Western MA and hence have no idea what the telecom situation is like over there, I'm certainly aware of quite a few places in first world USA where DSL is still a fantasy, let alone fiber. As a local example, I have a friend in a rural area of Southern California who can't get any kind of high-speed Internet. I've run a prequal on her address and it tells me she is 31 kft from the CO. The CO in question has a Covad DSLAM in it, but at 31 kft those rural residents' options are limited to either IDSL at 144 kbps (not much point in that) or a T1 starting at ~$700/month. The latter figure is typically well out of range for the kind of people who live in such places. That got me thinking: ISDN/IDSL and T1 can be extended infinitely far into the boondocks because those signal formats support repeaters. What I'm wondering is how can we do the same thing with SDSL - and I mean politically rather than technically. The technical part is easy: some COs already have CLECs in them that serve G.shdsl (I've been told that NEN does that) and for G.shdsl repeaters are part of the standard (searching around shows a few vendors making them); in the case of SDSL/2B1Q (Covad and DSL.net) there is no official support for repeaters and hence no major vendors making such, but I can build such a repeater unofficially. The difficulty is with the political part, and that's where I'm seeking the wisdom of this list. How would one go about sticking a mid-span repeater into an ILEC-owned 31 kft rural loop? From what I understand (someone please correct me if I'm wrong!), when a CLEC orders a loop from an ILEC, if it's for a T1 or IDSL, the CLEC actually orders a T1 or ISDN BRI transport from the ILEC rather than a dry pair, and any mid-span repeaters or HDSLx converters or the like become the responsibility of the ILEC rather than the CLEC, right? So how could one extend this model to provide, say, repeatered G.shdsl service to far-outlying rural subscribers? Is there some political process (PUC/FCC/etc) by which an ILEC could be forced to allow a third party to stick a repeater in the middle of their loop? Or would it have to work by way of the ILEC providing a G.shdsl transport service to CLECs, with the ILEC being responsible for the selection, procurement and deployment of repeater hardware? And what if the ILEC is not interested in providing such a service - any PUC/FCC/etc political process via which they could be forced to cooperate? Things get even more complicated in those locations where the CO has a Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC serving G.shdsl. Even if the ILEC were to provide a G.shdsl transport service with repeaters, it wouldn't help with SDSL/2B1Q. My idea involves building a gadget in the form factor of a standard mid-span repeater that would function as a converter from SDSL/2B1Q to G.shdsl: if the loop calls for one mid-span repeater, stick this gadget in as if it were that repeater; if the loop calls for 2 or more repeaters, use my gadget as the first repeater and then standard G.shdsl repeaters after it. But of course this idea is totally dependent on the ability of a third party to stick these devices in the middle of long rural loops, perhaps in the place of loading coils which are likely present on such loops. Any ideas? MS
Re: Locations with no good Internet (was ISP in Johannesburg)
Get dry loops from the ILEC and place repeaters at strategic points? On 2/26/10, Michael Sokolov msoko...@ivan.harhan.org wrote: Daniel Senie d...@senie.com wrote: Better than western Massachusetts, where there's just no connectivity at = all. Even dialup fails to function over crappy lines. Hmm. Although I've never been to Western MA and hence have no idea what the telecom situation is like over there, I'm certainly aware of quite a few places in first world USA where DSL is still a fantasy, let alone fiber. As a local example, I have a friend in a rural area of Southern California who can't get any kind of high-speed Internet. I've run a prequal on her address and it tells me she is 31 kft from the CO. The CO in question has a Covad DSLAM in it, but at 31 kft those rural residents' options are limited to either IDSL at 144 kbps (not much point in that) or a T1 starting at ~$700/month. The latter figure is typically well out of range for the kind of people who live in such places. That got me thinking: ISDN/IDSL and T1 can be extended infinitely far into the boondocks because those signal formats support repeaters. What I'm wondering is how can we do the same thing with SDSL - and I mean politically rather than technically. The technical part is easy: some COs already have CLECs in them that serve G.shdsl (I've been told that NEN does that) and for G.shdsl repeaters are part of the standard (searching around shows a few vendors making them); in the case of SDSL/2B1Q (Covad and DSL.net) there is no official support for repeaters and hence no major vendors making such, but I can build such a repeater unofficially. The difficulty is with the political part, and that's where I'm seeking the wisdom of this list. How would one go about sticking a mid-span repeater into an ILEC-owned 31 kft rural loop? From what I understand (someone please correct me if I'm wrong!), when a CLEC orders a loop from an ILEC, if it's for a T1 or IDSL, the CLEC actually orders a T1 or ISDN BRI transport from the ILEC rather than a dry pair, and any mid-span repeaters or HDSLx converters or the like become the responsibility of the ILEC rather than the CLEC, right? So how could one extend this model to provide, say, repeatered G.shdsl service to far-outlying rural subscribers? Is there some political process (PUC/FCC/etc) by which an ILEC could be forced to allow a third party to stick a repeater in the middle of their loop? Or would it have to work by way of the ILEC providing a G.shdsl transport service to CLECs, with the ILEC being responsible for the selection, procurement and deployment of repeater hardware? And what if the ILEC is not interested in providing such a service - any PUC/FCC/etc political process via which they could be forced to cooperate? Things get even more complicated in those locations where the CO has a Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC serving G.shdsl. Even if the ILEC were to provide a G.shdsl transport service with repeaters, it wouldn't help with SDSL/2B1Q. My idea involves building a gadget in the form factor of a standard mid-span repeater that would function as a converter from SDSL/2B1Q to G.shdsl: if the loop calls for one mid-span repeater, stick this gadget in as if it were that repeater; if the loop calls for 2 or more repeaters, use my gadget as the first repeater and then standard G.shdsl repeaters after it. But of course this idea is totally dependent on the ability of a third party to stick these devices in the middle of long rural loops, perhaps in the place of loading coils which are likely present on such loops. Any ideas? MS -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141
Re: Locations with no good Internet (was ISP in Johannesburg)
The Massachusetts Broadband Institute is currently working a middle mile solution to help with some of the issues in western ma. Thing do sound promising. On 2/26/10 4:34 PM, Michael Sokolov wrote: Daniel Senied...@senie.com wrote: Better than western Massachusetts, where there's just no connectivity at = all. Even dialup fails to function over crappy lines. Hmm. Although I've never been to Western MA and hence have no idea what the telecom situation is like over there, I'm certainly aware of quite a few places in first world USA where DSL is still a fantasy, let alone fiber. As a local example, I have a friend in a rural area of Southern California who can't get any kind of high-speed Internet. I've run a prequal on her address and it tells me she is 31 kft from the CO. The CO in question has a Covad DSLAM in it, but at 31 kft those rural residents' options are limited to either IDSL at 144 kbps (not much point in that) or a T1 starting at ~$700/month. The latter figure is typically well out of range for the kind of people who live in such places. That got me thinking: ISDN/IDSL and T1 can be extended infinitely far into the boondocks because those signal formats support repeaters. What I'm wondering is how can we do the same thing with SDSL - and I mean politically rather than technically. The technical part is easy: some COs already have CLECs in them that serve G.shdsl (I've been told that NEN does that) and for G.shdsl repeaters are part of the standard (searching around shows a few vendors making them); in the case of SDSL/2B1Q (Covad and DSL.net) there is no official support for repeaters and hence no major vendors making such, but I can build such a repeater unofficially. The difficulty is with the political part, and that's where I'm seeking the wisdom of this list. How would one go about sticking a mid-span repeater into an ILEC-owned 31 kft rural loop? From what I understand (someone please correct me if I'm wrong!), when a CLEC orders a loop from an ILEC, if it's for a T1 or IDSL, the CLEC actually orders a T1 or ISDN BRI transport from the ILEC rather than a dry pair, and any mid-span repeaters or HDSLx converters or the like become the responsibility of the ILEC rather than the CLEC, right? So how could one extend this model to provide, say, repeatered G.shdsl service to far-outlying rural subscribers? Is there some political process (PUC/FCC/etc) by which an ILEC could be forced to allow a third party to stick a repeater in the middle of their loop? Or would it have to work by way of the ILEC providing a G.shdsl transport service to CLECs, with the ILEC being responsible for the selection, procurement and deployment of repeater hardware? And what if the ILEC is not interested in providing such a service - any PUC/FCC/etc political process via which they could be forced to cooperate? Things get even more complicated in those locations where the CO has a Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC serving G.shdsl. Even if the ILEC were to provide a G.shdsl transport service with repeaters, it wouldn't help with SDSL/2B1Q. My idea involves building a gadget in the form factor of a standard mid-span repeater that would function as a converter from SDSL/2B1Q to G.shdsl: if the loop calls for one mid-span repeater, stick this gadget in as if it were that repeater; if the loop calls for 2 or more repeaters, use my gadget as the first repeater and then standard G.shdsl repeaters after it. But of course this idea is totally dependent on the ability of a third party to stick these devices in the middle of long rural loops, perhaps in the place of loading coils which are likely present on such loops. Any ideas? MS
Re: Locations with no good Internet (was ISP in Johannesburg)
From what I've read, they may well get higher bandwidth out to the town centers on fiber. There has been little discussion of how to distribute from there. I suppose Verizon, the only company offering anything out there, will take advantage and use the fiber to improve speeds in the centers of towns. But there's no CATV in most of the hill towns, and unless MBI intends to stretch fiber out to the neighborhoods, I remain skeptical. Today, most of the town halls have public access wifi, and people drive up and sit in their cars and get their email that way. This isn't a solution. On Feb 26, 2010, at 4:40 PM, James Jones wrote: The Massachusetts Broadband Institute is currently working a middle mile solution to help with some of the issues in western ma. Thing do sound promising. On 2/26/10 4:34 PM, Michael Sokolov wrote: Daniel Senied...@senie.com wrote: Better than western Massachusetts, where there's just no connectivity at = all. Even dialup fails to function over crappy lines. Hmm. Although I've never been to Western MA and hence have no idea what the telecom situation is like over there, I'm certainly aware of quite a few places in first world USA where DSL is still a fantasy, let alone fiber. As a local example, I have a friend in a rural area of Southern California who can't get any kind of high-speed Internet. I've run a prequal on her address and it tells me she is 31 kft from the CO. The CO in question has a Covad DSLAM in it, but at 31 kft those rural residents' options are limited to either IDSL at 144 kbps (not much point in that) or a T1 starting at ~$700/month. The latter figure is typically well out of range for the kind of people who live in such places. That got me thinking: ISDN/IDSL and T1 can be extended infinitely far into the boondocks because those signal formats support repeaters. What I'm wondering is how can we do the same thing with SDSL - and I mean politically rather than technically. The technical part is easy: some COs already have CLECs in them that serve G.shdsl (I've been told that NEN does that) and for G.shdsl repeaters are part of the standard (searching around shows a few vendors making them); in the case of SDSL/2B1Q (Covad and DSL.net) there is no official support for repeaters and hence no major vendors making such, but I can build such a repeater unofficially. The difficulty is with the political part, and that's where I'm seeking the wisdom of this list. How would one go about sticking a mid-span repeater into an ILEC-owned 31 kft rural loop? From what I understand (someone please correct me if I'm wrong!), when a CLEC orders a loop from an ILEC, if it's for a T1 or IDSL, the CLEC actually orders a T1 or ISDN BRI transport from the ILEC rather than a dry pair, and any mid-span repeaters or HDSLx converters or the like become the responsibility of the ILEC rather than the CLEC, right? So how could one extend this model to provide, say, repeatered G.shdsl service to far-outlying rural subscribers? Is there some political process (PUC/FCC/etc) by which an ILEC could be forced to allow a third party to stick a repeater in the middle of their loop? Or would it have to work by way of the ILEC providing a G.shdsl transport service to CLECs, with the ILEC being responsible for the selection, procurement and deployment of repeater hardware? And what if the ILEC is not interested in providing such a service - any PUC/FCC/etc political process via which they could be forced to cooperate? Things get even more complicated in those locations where the CO has a Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC serving G.shdsl. Even if the ILEC were to provide a G.shdsl transport service with repeaters, it wouldn't help with SDSL/2B1Q. My idea involves building a gadget in the form factor of a standard mid-span repeater that would function as a converter from SDSL/2B1Q to G.shdsl: if the loop calls for one mid-span repeater, stick this gadget in as if it were that repeater; if the loop calls for 2 or more repeaters, use my gadget as the first repeater and then standard G.shdsl repeaters after it. But of course this idea is totally dependent on the ability of a third party to stick these devices in the middle of long rural loops, perhaps in the place of loading coils which are likely present on such loops. Any ideas? MS
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
On 26/02/2010 21:13, Antonio Querubin wrote: Some googling for 'itu ipv6' turns up the following (among other things): http://www.itu.int/net/ITU-T/ipv6/itudocs.aspx Wow, there are some real classics in there. Anyone in need of a good end-of-week belly laugh should take a look at Delayed Contribution 93 and Contribution 30. The pitiful level of misunderstanding displayed by the authors of these documents is frightening. Nick
BGP Update Report
BGP Update Report Interval: 18-Feb-10 -to- 25-Feb-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS31055 19341 1.8%6447.0 -- CONSULTIX-AS Consultix GmbH 2 - AS45983 11585 1.1%1448.1 -- SKUNIV-AS-KR Seokyeong UNIV. 3 - AS35805 10339 1.0% 17.9 -- UTG-AS United Telecom AS 4 - AS982910116 1.0% 20.4 -- BSNL-NIB National Internet Backbone 5 - AS144209987 0.9% 26.6 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 6 - AS454089876 0.9%4938.0 -- 7 - AS318109845 0.9% 273.5 -- AOTL-AS 8 - AS7738 9132 0.9% 19.2 -- Telecomunicacoes da Bahia S.A. 9 - AS369928660 0.8% 15.7 -- ETISALAT-MISR 10 - AS165698222 0.8%4111.0 -- ASN-CITY-OF-CALGARY - City of Calgary 11 - AS178198217 0.8%1369.5 -- ASN-EQUINIX-AP Equinix Asia Pacific 12 - AS290497924 0.8% 27.7 -- DELTA-TELECOM-AS Delta Telecom LTD. 13 - AS288787287 0.7%1041.0 -- SIGNET-AS Signet B.V. 14 - AS260257281 0.7%7281.0 -- COC - City of Calgary 15 - AS457697240 0.7% 144.8 -- DVOIS-IN No. 70, 2nd Floor, 9th Main, H.M.T. Main Road 16 - AS179746886 0.7% 10.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 17 - AS5800 6566 0.6% 24.8 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 18 - AS270975510 0.5%1102.0 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 19 - AS8151 5380 0.5% 6.1 -- Uninet S.A. de C.V. 20 - AS8452 5358 0.5% 8.9 -- TEDATA TEDATA TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS260257281 0.7%7281.0 -- COC - City of Calgary 2 - AS31055 19341 1.8%6447.0 -- CONSULTIX-AS Consultix GmbH 3 - AS454089876 0.9%4938.0 -- 4 - AS165698222 0.8%4111.0 -- ASN-CITY-OF-CALGARY - City of Calgary 5 - AS5691 2624 0.2%2624.0 -- MITRE-AS-5 - The MITRE Corporation 6 - AS272451785 0.2%1785.0 -- HEIDRICK-CHICAGO - HEIDRICK 7 - AS45983 11585 1.1%1448.1 -- SKUNIV-AS-KR Seokyeong UNIV. 8 - AS178198217 0.8%1369.5 -- ASN-EQUINIX-AP Equinix Asia Pacific 9 - AS270975510 0.5%1102.0 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 10 - AS288787287 0.7%1041.0 -- SIGNET-AS Signet B.V. 11 - AS3220 644 0.1% 644.0 -- INTERNET-TECHNOLOGY-ADVISORS The AS formally known as EUnet Sweden 12 - AS28052 565 0.1% 565.0 -- Arte Radiotelevisivo Argentino 13 - AS45960 554 0.1% 554.0 -- YTLCOMMS-AS-AP YTL COMMUNICATIONS SDN BHD 14 - AS32794 546 0.1% 546.0 -- ICFG - International Church of the Foursquare Gospel 15 - AS27027 452 0.0% 452.0 -- ANBELL ASN-ANBELL 16 - AS104452611 0.2% 435.2 -- HTG - Huntleigh Telcom 17 - AS179644026 0.4% 402.6 -- DXTNET Beijing Dian-Xin-Tong Network Technologies Co., Ltd. 18 - AS12130 401 0.0% 401.0 -- BWCCLEC - Bandwidth.com CLEC LLC 19 - AS35291 793 0.1% 396.5 -- ICOMM-AS SC Internet Communication Systems SRL 20 - AS47961 345 0.0% 345.0 -- SATLINK SATLINK COMMUNICATIONS LTD . TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 62.168.199.0/24 19316 1.7% AS31055 -- CONSULTIX-AS Consultix GmbH 2 - 208.98.230.0/248221 0.7% AS16569 -- ASN-CITY-OF-CALGARY - City of Calgary 3 - 208.98.231.0/247281 0.6% AS26025 -- COC - City of Calgary 4 - 214.15.217.0/245372 0.5% AS27097 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 5 - 193.177.160.0/23 5229 0.5% AS28878 -- SIGNET-AS Signet B.V. 6 - 114.70.96.0/24 4938 0.4% AS45408 -- 7 - 114.70.97.0/24 4938 0.4% AS45408 -- 8 - 121.65.245.0/243603 0.3% AS45983 -- SKUNIV-AS-KR Seokyeong UNIV. 9 - 199.114.154.0/24 3338 0.3% AS1733 -- CENTAF-SWA - 754th Electronic Systems Group 10 - 143.138.107.0/24 2963 0.3% AS747 -- TAEGU-AS - Headquarters, USAISC 11 - 202.167.253.0/24 2798 0.2% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 12 - 202.177.223.0/24 2798 0.2% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 13 - 192.12.120.0/242624 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 14 - 202.167.247.0/24 2606 0.2% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 15 - 91.208.167.0/242041 0.2% AS28878 -- SIGNET-AS Signet B.V. 16 - 203.249.122.0/24 1894 0.2% AS45983 -- SKUNIV-AS-KR Seokyeong UNIV. 17 - 63.84.91.0/24 1785 0.2% AS27245 -- HEIDRICK-CHICAGO - HEIDRICK 18 - 212.220.14.0/24
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
Some googling for 'itu ipv6' turns up the following (among other things): http://www.itu.int/net/ITU-T/ipv6/itudocs.aspx yeah, yeah, ITU still making noise with the Y Series docs and NGN (Next Generation Networks) framework. Jeluuu ITU, kind of you are 25+ years late ...
The Cidr Report
This report has been generated at Fri Feb 26 06:11:26 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
19-02-10314156 193278
20-02-10314382 193171
21-02-10314286 193384
22-02-10314579 193201
23-02-10314271 193206
24-02-10314688 193182
25-02-10314529 193511
26-02-10314600 193465
AS Summary
33695 Number of ASes in routing system
14346 Number of ASes announcing only one prefix
4384 Largest number of prefixes announced by an AS
AS4323 : TWTC - tw telecom holdings, inc.
93180416 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').
--- 26Feb10 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 314483 193473 12101038.5% All ASes
AS6389 4110 320 379092.2% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 4384 1852 253257.8% TWTC - tw telecom holdings,
inc.
AS4766 1860 491 136973.6% KIXS-AS-KR Korea Telecom
AS1785 1838 660 117864.1% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS4755 1287 213 107483.4% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS22773 1101 74 102793.3% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS18566 1059 33 102696.9% COVAD - Covad Communications
Co.
AS17488 1289 346 94373.2% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS8151 1584 674 91057.4% Uninet S.A. de C.V.
AS18101 1083 221 86279.6% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS10620 1010 178 83282.4% TV Cable S.A.
AS19262 1068 243 82577.2% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS6478 1116 444 67260.2% ATT-INTERNET3 - ATT WorldNet
Services
AS4808 852 238 61472.1% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS4804 678 72 60689.4% MPX-AS Microplex PTY LTD
AS7303 678 106 57284.4% Telecom Argentina S.A.
AS4134 1019 460 55954.9% CHINANET-BACKBONE
No.31,Jin-rong Street
AS7018 1561 1008 55335.4% ATT-INTERNET4 - ATT WorldNet
Services
AS17908 768 230 53870.1% TCISL Tata Communications
AS8452 866 330 53661.9% TEDATA TEDATA
AS24560 849 316 53362.8% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS3356 1165 660 50543.3% LEVEL3 Level 3 Communications
AS28573 910 407 50355.3% NET Servicos de Comunicao S.A.
AS35805 579 83 49685.7% UTG-AS United Telecom AS
AS4780 631 137 49478.3% SEEDNET Digital United Inc.
AS7545 975 494 48149.3% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS17676 563 82 48185.4% GIGAINFRA Softbank BB Corp.
AS9443 559 80 47985.7% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS9808 462 14 44897.0% CMNET-GD Guangdong Mobile
Communication Co.Ltd.
AS7738 476 30 44693.7% Telecomunicacoes da Bahia S.A.
Total 36380104962588471.1% Top 30 total
Possible Bogus Routes
1.0.0.0/8AS237 MERIT-AS-14 - Merit Network Inc.
2.0.0.0/16
Re: Locations with no good Internet (was ISP in Johannesburg)
I am in planning states for a new metro ethernet service here in the springfield area. that will slowly extend to the town as I can get there. On 2/26/10 4:45 PM, Daniel Senie wrote: From what I've read, they may well get higher bandwidth out to the town centers on fiber. There has been little discussion of how to distribute from there. I suppose Verizon, the only company offering anything out there, will take advantage and use the fiber to improve speeds in the centers of towns. But there's no CATV in most of the hill towns, and unless MBI intends to stretch fiber out to the neighborhoods, I remain skeptical. Today, most of the town halls have public access wifi, and people drive up and sit in their cars and get their email that way. This isn't a solution. On Feb 26, 2010, at 4:40 PM, James Jones wrote: The Massachusetts Broadband Institute is currently working a middle mile solution to help with some of the issues in western ma. Thing do sound promising. On 2/26/10 4:34 PM, Michael Sokolov wrote: Daniel Senied...@senie.com wrote: Better than western Massachusetts, where there's just no connectivity at = all. Even dialup fails to function over crappy lines. Hmm. Although I've never been to Western MA and hence have no idea what the telecom situation is like over there, I'm certainly aware of quite a few places in first world USA where DSL is still a fantasy, let alone fiber. As a local example, I have a friend in a rural area of Southern California who can't get any kind of high-speed Internet. I've run a prequal on her address and it tells me she is 31 kft from the CO. The CO in question has a Covad DSLAM in it, but at 31 kft those rural residents' options are limited to either IDSL at 144 kbps (not much point in that) or a T1 starting at ~$700/month. The latter figure is typically well out of range for the kind of people who live in such places. That got me thinking: ISDN/IDSL and T1 can be extended infinitely far into the boondocks because those signal formats support repeaters. What I'm wondering is how can we do the same thing with SDSL - and I mean politically rather than technically. The technical part is easy: some COs already have CLECs in them that serve G.shdsl (I've been told that NEN does that) and for G.shdsl repeaters are part of the standard (searching around shows a few vendors making them); in the case of SDSL/2B1Q (Covad and DSL.net) there is no official support for repeaters and hence no major vendors making such, but I can build such a repeater unofficially. The difficulty is with the political part, and that's where I'm seeking the wisdom of this list. How would one go about sticking a mid-span repeater into an ILEC-owned 31 kft rural loop? From what I understand (someone please correct me if I'm wrong!), when a CLEC orders a loop from an ILEC, if it's for a T1 or IDSL, the CLEC actually orders a T1 or ISDN BRI transport from the ILEC rather than a dry pair, and any mid-span repeaters or HDSLx converters or the like become the responsibility of the ILEC rather than the CLEC, right? So how could one extend this model to provide, say, repeatered G.shdsl service to far-outlying rural subscribers? Is there some political process (PUC/FCC/etc) by which an ILEC could be forced to allow a third party to stick a repeater in the middle of their loop? Or would it have to work by way of the ILEC providing a G.shdsl transport service to CLECs, with the ILEC being responsible for the selection, procurement and deployment of repeater hardware? And what if the ILEC is not interested in providing such a service - any PUC/FCC/etc political process via which they could be forced to cooperate? Things get even more complicated in those locations where the CO has a Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC serving G.shdsl. Even if the ILEC were to provide a G.shdsl transport service with repeaters, it wouldn't help with SDSL/2B1Q. My idea involves building a gadget in the form factor of a standard mid-span repeater that would function as a converter from SDSL/2B1Q to G.shdsl: if the loop calls for one mid-span repeater, stick this gadget in as if it were that repeater; if the loop calls for 2 or more repeaters, use my gadget as the first repeater and then standard G.shdsl repeaters after it. But of course this idea is totally dependent on the ability of a third party to stick these devices in the middle of long rural loops, perhaps in the place of loading coils which are likely present on such loops. Any ideas? MS
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
On Feb 26, 2010, at 1:58 PM, Nick Hilliard wrote: On 26/02/2010 21:13, Antonio Querubin wrote: Some googling for 'itu ipv6' turns up the following (among other things): http://www.itu.int/net/ITU-T/ipv6/itudocs.aspx Wow, there are some real classics in there. Anyone in need of a good end-of-week belly laugh should take a look at Delayed Contribution 93 and Contribution 30. Given the folks who read/write these sorts of documents tend to make national laws attempting to implement the policies the documents describe, I'm not sure belly laugh is the right anatomical reaction. The pitiful level of misunderstanding displayed by the authors of these documents is frightening. If you want to be really frightened, remember that the IPv4 free pool is going to be exhausted in something like 576 days. Given the lack of IPv6 deployment, the subsequent food fights that erupt as markets in IPv4 addresses are established are likely going to be interesting. Politicians very much like to be seen to be doing something in interesting food fights. If this causes you any level of concern, for any of you going to APNIC, you might want to participate in http://www.apnic.net/publications/news/2010/apnic-29-consultation. Regards, -drc
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
On Fri, 26 Feb 2010, Nick Hilliard wrote: The pitiful level of misunderstanding displayed by the authors of these documents is frightening. Indeed. A usern...@domain is as valid a VOIP ID as is a traditional telephone number. And country coded TLDs can be moved around the net more easily than telephone country codes tied to a national carrier network. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.net
Re: Locations with no good Internet (was ISP in Johannesburg)
Brandon Galbraith brandon.galbra...@gmail.com wrote: Get dry loops from the ILEC and place repeaters at strategic points? I guess I need a little more education on how the process of ordering dry pairs from an ILEC works. I thought it works like this: 1. You have to be colocated in the CO to begin with. 2. You give the ILEC the address of an end site and they run a dry pair from your cage within their CO to that address. 3. You don't get access to any intermediate points. As far as placing the repeaters at strategic points, yeah, that's exactly what I meant, but my point was that these strategic points are owned by the ILEC, and I was/am wondering how to go about making it possible for a third party to stick repeater equipment in there. I envision the following picture: * There is a CO in a town, and there is a Covad DSLAM in that CO, serving those folks who are located in the town itself. * There is a winding mountain road going out of town into the countryside, and there are phone wires running alongside that road, several miles long. * There gotta be a bunch of cyan-colored cross-connect boxes on the side of the road, manholes and other places where the ILEC has mid-span access to those lng loops. They also very likely have loading coils on loops like that, and although I confess that I've never seen one of those coils with my own eyes, I've heard that they are rather bulky in terms of physical dimensions, probably bigger than a repeater PCB. The problem is that these mid-span access points are property of the ILEC along with the rest of the loop plant, and although there probably exists an ILEC-internal procedure for installing mid-span repeaters for T1s and maybe ISDN BRI, that is most certainly done by the ILEC itself, not by any third parties. Making it possible for a third party to access those intermediate points to install repeater equipment which the ILEC won't understand (handling Covad's non-standard flavor of SDSL/2B1Q) is the problem I'm trying to solve. MS
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
The pitiful level of misunderstanding displayed by the authors of these documents is frightening. Are the ITU folks planning to manage IPv6 address space allocations the same way they number their documents (ie no more than 100 docs per subject on the Y series) ? ;-}
RE: Locations with no good Internet (was ISP in Johannesburg)
I had good luck getting my dad some form of broadband access in rural Oregon using a 3g router (Cradlepoint), a Wilson Electronics signal amp (model 811211), and an outdoor mount high gain antenna. It's not great, but considering the alternatives (33.6k dialup for $60/mo or satellite broadband for $150-$200/mo) it wasn't a bad deal for my dad when you consider that the dialup ISP + dedicated POTS line cost about as much as the 5GB 3G data plan does. Speed is somewhere between dialup and Uverse or FIOS. I get the sense that it is somewhere in the range of 256 - 512 kbps with high latency (Dad's not one for much in the way of network performance testing). -Original Message- From: Michael Sokolov [mailto:msoko...@ivan.harhan.org] Sent: Friday, February 26, 2010 3:35 PM To: nanog@nanog.org Subject: Locations with no good Internet (was ISP in Johannesburg) Daniel Senie d...@senie.com wrote: Better than western Massachusetts, where there's just no connectivity at = all. Even dialup fails to function over crappy lines. Hmm. Although I've never been to Western MA and hence have no idea what the telecom situation is like over there, I'm certainly aware of quite a few places in first world USA where DSL is still a fantasy, let alone fiber. As a local example, I have a friend in a rural area of Southern California who can't get any kind of high-speed Internet. I've run a prequal on her address and it tells me she is 31 kft from the CO. The CO in question has a Covad DSLAM in it, but at 31 kft those rural residents' options are limited to either IDSL at 144 kbps (not much point in that) or a T1 starting at ~$700/month. The latter figure is typically well out of range for the kind of people who live in such places. That got me thinking: ISDN/IDSL and T1 can be extended infinitely far into the boondocks because those signal formats support repeaters. What I'm wondering is how can we do the same thing with SDSL - and I mean politically rather than technically. The technical part is easy: some COs already have CLECs in them that serve G.shdsl (I've been told that NEN does that) and for G.shdsl repeaters are part of the standard (searching around shows a few vendors making them); in the case of SDSL/2B1Q (Covad and DSL.net) there is no official support for repeaters and hence no major vendors making such, but I can build such a repeater unofficially. The difficulty is with the political part, and that's where I'm seeking the wisdom of this list. How would one go about sticking a mid-span repeater into an ILEC-owned 31 kft rural loop? From what I understand (someone please correct me if I'm wrong!), when a CLEC orders a loop from an ILEC, if it's for a T1 or IDSL, the CLEC actually orders a T1 or ISDN BRI transport from the ILEC rather than a dry pair, and any mid-span repeaters or HDSLx converters or the like become the responsibility of the ILEC rather than the CLEC, right? So how could one extend this model to provide, say, repeatered G.shdsl service to far-outlying rural subscribers? Is there some political process (PUC/FCC/etc) by which an ILEC could be forced to allow a third party to stick a repeater in the middle of their loop? Or would it have to work by way of the ILEC providing a G.shdsl transport service to CLECs, with the ILEC being responsible for the selection, procurement and deployment of repeater hardware? And what if the ILEC is not interested in providing such a service - any PUC/FCC/etc political process via which they could be forced to cooperate? Things get even more complicated in those locations where the CO has a Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC serving G.shdsl. Even if the ILEC were to provide a G.shdsl transport service with repeaters, it wouldn't help with SDSL/2B1Q. My idea involves building a gadget in the form factor of a standard mid-span repeater that would function as a converter from SDSL/2B1Q to G.shdsl: if the loop calls for one mid-span repeater, stick this gadget in as if it were that repeater; if the loop calls for 2 or more repeaters, use my gadget as the first repeater and then standard G.shdsl repeaters after it. But of course this idea is totally dependent on the ability of a third party to stick these devices in the middle of long rural loops, perhaps in the place of loading coils which are likely present on such loops. Any ideas? MS
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
Maybe I'm dense, but I don't see the problem. One of the great things about IPv6's address space being mindbogglingly large is that there's plenty of it to experiment with. If the ITU wants an RIR-sized block to do RIR-like work, so what? If they wanted a /2 or /4 I'd be concerned, or if there were many organizations out there that wanted RIR-sized chunks, but ITU's close enough to unique that they're not going to cause the space to run out. And sure, maybe they're sufficiently outdated and irrelevant that they could get by with a /16, but it might be interesting to have somebody assigning IPv6 addresses as :prefix:e164:host or whatever. (Admittedly, that made more sense back when e.164 addresses were 12 digits as opposed to the current 15.) -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
RE: Locations with no good Internet (was ISP in Johannesburg)
As we all know it's expensive building out any landline network. Rural areas just get over looked. Check out this tech coming out of Motorola and to a Verizon/ATT tower near you soon. 100 Mbps possible off cellular signals. Looks like they will throttle it to 20 Mbps and less though. http://business.motorola.com/experiencelte/lte-depth.html http://news.techworld.com/networking/3203498/motorola-predicts-20mbps-download-speed-with-future-lte-networks/ WPH -Original Message- From: Crooks, Sam [mailto:sam.cro...@experian.com] Sent: Friday, February 26, 2010 4:51 PM To: Michael Sokolov; nanog@nanog.org Subject: RE: Locations with no good Internet (was ISP in Johannesburg) I had good luck getting my dad some form of broadband access in rural Oregon using a 3g router (Cradlepoint), a Wilson Electronics signal amp (model 811211), and an outdoor mount high gain antenna. It's not great, but considering the alternatives (33.6k dialup for $60/mo or satellite broadband for $150-$200/mo) it wasn't a bad deal for my dad when you consider that the dialup ISP + dedicated POTS line cost about as much as the 5GB 3G data plan does. Speed is somewhere between dialup and Uverse or FIOS. I get the sense that it is somewhere in the range of 256 - 512 kbps with high latency (Dad's not one for much in the way of network performance testing). -Original Message- From: Michael Sokolov [mailto:msoko...@ivan.harhan.org] Sent: Friday, February 26, 2010 3:35 PM To: nanog@nanog.org Subject: Locations with no good Internet (was ISP in Johannesburg) Daniel Senie d...@senie.com wrote: Better than western Massachusetts, where there's just no connectivity at = all. Even dialup fails to function over crappy lines. Hmm. Although I've never been to Western MA and hence have no idea what the telecom situation is like over there, I'm certainly aware of quite a few places in first world USA where DSL is still a fantasy, let alone fiber. As a local example, I have a friend in a rural area of Southern California who can't get any kind of high-speed Internet. I've run a prequal on her address and it tells me she is 31 kft from the CO. The CO in question has a Covad DSLAM in it, but at 31 kft those rural residents' options are limited to either IDSL at 144 kbps (not much point in that) or a T1 starting at ~$700/month. The latter figure is typically well out of range for the kind of people who live in such places. That got me thinking: ISDN/IDSL and T1 can be extended infinitely far into the boondocks because those signal formats support repeaters. What I'm wondering is how can we do the same thing with SDSL - and I mean politically rather than technically. The technical part is easy: some COs already have CLECs in them that serve G.shdsl (I've been told that NEN does that) and for G.shdsl repeaters are part of the standard (searching around shows a few vendors making them); in the case of SDSL/2B1Q (Covad and DSL.net) there is no official support for repeaters and hence no major vendors making such, but I can build such a repeater unofficially. The difficulty is with the political part, and that's where I'm seeking the wisdom of this list. How would one go about sticking a mid-span repeater into an ILEC-owned 31 kft rural loop? From what I understand (someone please correct me if I'm wrong!), when a CLEC orders a loop from an ILEC, if it's for a T1 or IDSL, the CLEC actually orders a T1 or ISDN BRI transport from the ILEC rather than a dry pair, and any mid-span repeaters or HDSLx converters or the like become the responsibility of the ILEC rather than the CLEC, right? So how could one extend this model to provide, say, repeatered G.shdsl service to far-outlying rural subscribers? Is there some political process (PUC/FCC/etc) by which an ILEC could be forced to allow a third party to stick a repeater in the middle of their loop? Or would it have to work by way of the ILEC providing a G.shdsl transport service to CLECs, with the ILEC being responsible for the selection, procurement and deployment of repeater hardware? And what if the ILEC is not interested in providing such a service - any PUC/FCC/etc political process via which they could be forced to cooperate? Things get even more complicated in those locations where the CO has a Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC serving G.shdsl. Even if the ILEC were to provide a G.shdsl transport service with repeaters, it wouldn't help with SDSL/2B1Q. My idea involves building a gadget in the form factor of a standard mid-span repeater that would function as a converter from SDSL/2B1Q to G.shdsl: if the loop calls for one mid-span repeater, stick this gadget in as if it were that repeater; if the loop calls for 2 or more repeaters, use my gadget as the first repeater and then standard G.shdsl repeaters after it. But of course this idea is totally dependent on
Re: Locations with no good Internet (was ISP in Johannesburg)
I think a lot of people often forget that ISPs are actually businesses trying to turn a profit. At my last job we built out a fiber to the home ILEC in relatively rural Louisiana. This means that we had quite a number of customers that didn't meet the density requirements for deployment. Using made-up numbers for the sake of discussion, lets assume that a customer provides $1/month for service. If you can place deployment in a highly-dense area you'll make a lot more of those $1's per month with that investment. When you start deploying further to the edge you really slide into the we're not even breaking even on this market. Obviously anyone that has a job for profit knows that this is a no-no. As telcos deploy high-density technologies (fiber, metroE, etc) they can pull the legacy technology (xDSL, T1, etc) and push that to the edge. Unfortunately the edge is always going to get the hand-me-downs but it's better than nothing. My wife is from a tiny town in central PA (the vortex between Pittsburgh and Philly) and her parents have had dialup until last year, when the local telco finally pushed DSL to their location. They only draw 1.5meg but it's better than the 56k they were paying for. As they say in vegas, It's just business, baby. On Fri, Feb 26, 2010 at 5:51 PM, Crooks, Sam sam.cro...@experian.comwrote: I had good luck getting my dad some form of broadband access in rural Oregon using a 3g router (Cradlepoint), a Wilson Electronics signal amp (model 811211), and an outdoor mount high gain antenna. It's not great, but considering the alternatives (33.6k dialup for $60/mo or satellite broadband for $150-$200/mo) it wasn't a bad deal for my dad when you consider that the dialup ISP + dedicated POTS line cost about as much as the 5GB 3G data plan does. Speed is somewhere between dialup and Uverse or FIOS. I get the sense that it is somewhere in the range of 256 - 512 kbps with high latency (Dad's not one for much in the way of network performance testing). -Original Message- From: Michael Sokolov [mailto:msoko...@ivan.harhan.org] Sent: Friday, February 26, 2010 3:35 PM To: nanog@nanog.org Subject: Locations with no good Internet (was ISP in Johannesburg) Daniel Senie d...@senie.com wrote: Better than western Massachusetts, where there's just no connectivity at = all. Even dialup fails to function over crappy lines. Hmm. Although I've never been to Western MA and hence have no idea what the telecom situation is like over there, I'm certainly aware of quite a few places in first world USA where DSL is still a fantasy, let alone fiber. As a local example, I have a friend in a rural area of Southern California who can't get any kind of high-speed Internet. I've run a prequal on her address and it tells me she is 31 kft from the CO. The CO in question has a Covad DSLAM in it, but at 31 kft those rural residents' options are limited to either IDSL at 144 kbps (not much point in that) or a T1 starting at ~$700/month. The latter figure is typically well out of range for the kind of people who live in such places. That got me thinking: ISDN/IDSL and T1 can be extended infinitely far into the boondocks because those signal formats support repeaters. What I'm wondering is how can we do the same thing with SDSL - and I mean politically rather than technically. The technical part is easy: some COs already have CLECs in them that serve G.shdsl (I've been told that NEN does that) and for G.shdsl repeaters are part of the standard (searching around shows a few vendors making them); in the case of SDSL/2B1Q (Covad and DSL.net) there is no official support for repeaters and hence no major vendors making such, but I can build such a repeater unofficially. The difficulty is with the political part, and that's where I'm seeking the wisdom of this list. How would one go about sticking a mid-span repeater into an ILEC-owned 31 kft rural loop? From what I understand (someone please correct me if I'm wrong!), when a CLEC orders a loop from an ILEC, if it's for a T1 or IDSL, the CLEC actually orders a T1 or ISDN BRI transport from the ILEC rather than a dry pair, and any mid-span repeaters or HDSLx converters or the like become the responsibility of the ILEC rather than the CLEC, right? So how could one extend this model to provide, say, repeatered G.shdsl service to far-outlying rural subscribers? Is there some political process (PUC/FCC/etc) by which an ILEC could be forced to allow a third party to stick a repeater in the middle of their loop? Or would it have to work by way of the ILEC providing a G.shdsl transport service to CLECs, with the ILEC being responsible for the selection, procurement and deployment of repeater hardware? And what if the ILEC is not interested in providing such a service - any PUC/FCC/etc political process via which they could be
Re: Locations with no good Internet (was ISP in Johannesburg)
On Fri, Feb 26, 2010 at 5:10 PM, Paul Bosworth pboswo...@gmail.com wrote: I think a lot of people often forget that ISPs are actually businesses trying to turn a profit. There are alternatives though, if the need exists and folks are able: http://www.rric.net/ -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
Maybe I'm dense, but I don't see the problem. It breaks the existing regional allocation and policy development process model establishing a second source that will probably not just want to allocate but also develop a parallel policy that will most probably not be consistent or compatible with the other RIR's. My .02
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
On Fri, 26 Feb 2010 10:43:11 -0800 David Conrad d...@virtualized.org wrote: On Feb 26, 2010, at 10:22 AM, gordon b slater wrote: I must admit to total confusion over why they need to grab IPs from the v6 address space? Surely they don't need the equivalent of band-plans for IP space? Or have I missed some v6 technical point totally? The ITU Secretariat and a few member states (Syria being the most frequent) point to the inequality of distribution of IPv4 space and argue that developing countries must not be left out of IPv6 the same way. They have also suggested that the establishment of Country Internet Registries (that is, national PTT-based allocation registries) could provide competition for the RIRs, thereby using market forces to improve address allocation services. I think that PTT is the operative token here, but for reasons having nothing to do with competition. If all they wanted was competition, the easy answer would be to set up more registries -- or registrars -- not bounded by geography; as long as the number wasn't too large, it wouldn't do too much violence to the size of the routing tables. If a PTT-like body is *the* registry for a country, and if the country chose to require local ISPs and business to obtain address space from it, what's the natural prefix announcement to the world? Right -- that country's registry prefix, which means that all traffic to that country just naturally flows through the PTT's routers and DPI boxes. And it benefits everyone, right? It really cuts down on the number of prefixes we have to worry about It's funny -- just yesterday, I was telling my class that the Internet's connectivity was not like the pre-deregulation telco model. The latter had O(1) telco/country, with highly regulated interconnections to anywhere else. The Internet grew up under the radar, partly because of the deregulatory climate and partly because especially in the early days, it wasn't facilities-based -- if you wanted an international link to a peer or a branch office, you just leased the circuit. The result was much richer connectivity than in the telco world, and -- in some sense -- less order. Syria wants to roll the clock back. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
Syria wants to roll the clock back. Not only Syria, some developed countries want to have 100% control of the big switch to turn the net off/on, if possible on a packet by packet basis. PTT = Prehistoric Telecommunications Technologies ... IMHO the most important driving factor behind all these are just politics and power. -J
Re: Locations with no good Internet (was ISP in Johannesburg)
Brandon Galbraith brandon.galbra...@gmail.com wrote: http://www.rric.net/ I'm very familiar with those folks of course, they've been an inspiration to me for a long time. However, my needs are different. RRIC's model basically involves a specific community with a well-defined boundary: bring the bandwidth into the community via a bulk feed, then sublet inside the community. But I don't have a specific community in mind - I'm trying to develop a more generic solution. (The case of my friend who is at 31 kft from a Covad-enabled CO is only an example and nothing more.) Again, consider a town with a Covad-enabled CO plus an outlying countryside. The people in the town proper already have Covad xDSL available to them, and if we could stick my SDSL/2B1Q repeater in the middle of some longer loops, it would enable the people in the countryside to get *exactly the same* Covad (or ISP-X-via-Covad) services as those in the town proper. My repeater approach would also allow me to stay out of ISP or ISP-like business which I really don't want to get into - I would rather just make hardware and let someone else operate it. A repeater is totally unlike a router, it is not IP-aware, it just makes the loop seem shorter, allowing farther-outlying users to connect to *existing* ISPs with an already established business structure. Anyway, I just saw a post on NANOG about an area deprived of high-speed Internet services and thought I would post my idea in the hope that someone would have some ideas that would actually be *helpful* to what I'm trying to do. If not - oh well, I'll just put the idea back on the dusty shelf in the back of my mind until I'm ready to try presenting it to the folks who own the CO-colocated DSLAMs it would have to work with - gotta finish a few other things before I open that can of worms in the earnest. MS
Re: Locations with no good Internet (was ISP in Johannesburg)
Hopefully someone will bother to cover the rural areas with cell service eventually. Much of western Massachusetts (by which I mean the Berkshires, more than I mean the Pioneer Valley) is not covered by cell service. Where there is cell service, most cell sites have only minimal data speeds. Vermont is far worse, as is much of Maine. If there were 3G cellular, it'd be a big step up. But I expect the inner cities will all be running LTE for years before more rural areas even get voice service. On Feb 26, 2010, at 6:04 PM, Haney, Wilson wrote: As we all know it's expensive building out any landline network. Rural areas just get over looked. Check out this tech coming out of Motorola and to a Verizon/ATT tower near you soon. 100 Mbps possible off cellular signals. Looks like they will throttle it to 20 Mbps and less though. http://business.motorola.com/experiencelte/lte-depth.html http://news.techworld.com/networking/3203498/motorola-predicts-20mbps-download-speed-with-future-lte-networks/ WPH -Original Message- From: Crooks, Sam [mailto:sam.cro...@experian.com] Sent: Friday, February 26, 2010 4:51 PM To: Michael Sokolov; nanog@nanog.org Subject: RE: Locations with no good Internet (was ISP in Johannesburg) I had good luck getting my dad some form of broadband access in rural Oregon using a 3g router (Cradlepoint), a Wilson Electronics signal amp (model 811211), and an outdoor mount high gain antenna. It's not great, but considering the alternatives (33.6k dialup for $60/mo or satellite broadband for $150-$200/mo) it wasn't a bad deal for my dad when you consider that the dialup ISP + dedicated POTS line cost about as much as the 5GB 3G data plan does. Speed is somewhere between dialup and Uverse or FIOS. I get the sense that it is somewhere in the range of 256 - 512 kbps with high latency (Dad's not one for much in the way of network performance testing). -Original Message- From: Michael Sokolov [mailto:msoko...@ivan.harhan.org] Sent: Friday, February 26, 2010 3:35 PM To: nanog@nanog.org Subject: Locations with no good Internet (was ISP in Johannesburg) Daniel Senie d...@senie.com wrote: Better than western Massachusetts, where there's just no connectivity at = all. Even dialup fails to function over crappy lines. Hmm. Although I've never been to Western MA and hence have no idea what the telecom situation is like over there, I'm certainly aware of quite a few places in first world USA where DSL is still a fantasy, let alone fiber. As a local example, I have a friend in a rural area of Southern California who can't get any kind of high-speed Internet. I've run a prequal on her address and it tells me she is 31 kft from the CO. The CO in question has a Covad DSLAM in it, but at 31 kft those rural residents' options are limited to either IDSL at 144 kbps (not much point in that) or a T1 starting at ~$700/month. The latter figure is typically well out of range for the kind of people who live in such places. That got me thinking: ISDN/IDSL and T1 can be extended infinitely far into the boondocks because those signal formats support repeaters. What I'm wondering is how can we do the same thing with SDSL - and I mean politically rather than technically. The technical part is easy: some COs already have CLECs in them that serve G.shdsl (I've been told that NEN does that) and for G.shdsl repeaters are part of the standard (searching around shows a few vendors making them); in the case of SDSL/2B1Q (Covad and DSL.net) there is no official support for repeaters and hence no major vendors making such, but I can build such a repeater unofficially. The difficulty is with the political part, and that's where I'm seeking the wisdom of this list. How would one go about sticking a mid-span repeater into an ILEC-owned 31 kft rural loop? From what I understand (someone please correct me if I'm wrong!), when a CLEC orders a loop from an ILEC, if it's for a T1 or IDSL, the CLEC actually orders a T1 or ISDN BRI transport from the ILEC rather than a dry pair, and any mid-span repeaters or HDSLx converters or the like become the responsibility of the ILEC rather than the CLEC, right? So how could one extend this model to provide, say, repeatered G.shdsl service to far-outlying rural subscribers? Is there some political process (PUC/FCC/etc) by which an ILEC could be forced to allow a third party to stick a repeater in the middle of their loop? Or would it have to work by way of the ILEC providing a G.shdsl transport service to CLECs, with the ILEC being responsible for the selection, procurement and deployment of repeater hardware? And what if the ILEC is not interested in providing such a service - any PUC/FCC/etc political process via which they could be forced to cooperate? Things get even more complicated in those locations where the CO has a Covad DSLAM in it
Revelation Networks
Does anyone have any experiences with Revelation Networks? They're AS26821, and I'm looking for good or bad experiences with their services. Prefer an off-list reply. Thanks
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
On 26/02/2010 22:13, David Conrad wrote: If you want to be really frightened, remember that the IPv4 free pool is going to be exhausted in something like 576 days. Given the lack of IPv6 deployment, the subsequent food fights that erupt as markets in IPv4 addresses are established are likely going to be interesting. Politicians very much like to be seen to be doing something in interesting food fights. There is no doubt that there will be the most unholy bun-fight. Journalists will elevate themselves to the highest ivory towers and crow about how they foresaw all this happening years in advance, if only anyone had bothered to listen to them. Communications regulators will tut-tut loudly and commission long-winded reports on the effect of ipv4 starvation to the Digital Economy, and set up sub-committees and sub-sub-committees to examine potential solutions, all due to report within an 18-24 month time-frame, and all recommending migration to ipv6 over time (woohoo! - what insight!). The vendors will have a field day selling NATs, carrier grade NATs and all sorts of magical upgrades, all designed at milking the last tiny amounts of value out of each single ipv4 address - and your wallet. Notwithstanding this, their IPv6 support will still be curiously badly implemented, tacked on as an afterthought for those stingy service provider types rather than the cash-cow corporates and public sector customers who'll swallow anything that's given a good review in the trade rags. The WSIS will turn into a shouting match, or even more of a shouting match. Actually, scratch that: it'll turn into a foaming pit of rabid evangelists, each preaching their gospel of ill-informed craziness, allowing the ITU to step in and demonstrate that their mature and seasoned approach to the problem is the only realistic way of dealing with ipv4 scarcity, if only the internet and its short-sighted approach to proper standards based telco engineering were to come under their control. And the politicians. Yes, they will erupt in hitherto unseen outbursts of self-righteous indignation at the stupid internet engineers who let this problem happen in the first place and who made no provision whatsoever for viable alternatives, and will then declare the the only reasonable way of dealing with the problem is their particular type of regulation, mandating this or that but - funnily enough - very little of it making any sense whatever and all of it adding to the old maxim that there is no problem which exists which can't be made worse by regulation. As you note, anything for a couple of column inches. Oh, it will be fun. Nick
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
On Feb 26, 2010, at 1:58 PM, Nick Hilliard wrote: On 26/02/2010 21:13, Antonio Querubin wrote: Some googling for 'itu ipv6' turns up the following (among other things): http://www.itu.int/net/ITU-T/ipv6/itudocs.aspx Wow, there are some real classics in there. Anyone in need of a good end-of-week belly laugh should take a look at Delayed Contribution 93 and Contribution 30. The pitiful level of misunderstanding displayed by the authors of these documents is frightening. Nick What is more frightening is that when these authors get their contributions turned into ITU policy, it often carries the force of law in many jurisdictions. Owen
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
On Feb 26, 2010, at 4:41 PM, Steven M. Bellovin wrote: I think that PTT is the operative token here, but for reasons having nothing to do with competition. If all they wanted was competition, the easy answer would be to set up more registries -- or registrars -- not bounded by geography; as long as the number wasn't too large, it wouldn't do too much violence to the size of the routing tables. If a PTT-like body is *the* registry for a country, and if the country chose to require local ISPs and business to obtain address space from it, what's the natural prefix announcement to the world? Right -- that country's registry prefix, which means that all traffic to that country just naturally flows through the PTT's routers and DPI boxes. And it benefits everyone, right? It really cuts down on the number of prefixes we have to worry about Until routing domains (i.e., ASNs) are carved up to become congruent to national boundaries for national security, censorship or other reasons. When this happens, not only will those IPv6 prefixes become fragmented, so to will their legacy IPv4 space, and certainly to the detriment of routing scalability, security, and stability. Then add something like RPKI to the mix and you've got a very effective hammer to enforce national policy - all network operators will use the national RPKI trust anchor, and all of your address space will be allocated (and certified) strictly from this national Internet registry - so that they can surgically control precisely who can reach you, and who you can reach - within the whole of the global routing system, and DPI, tariffing, etc.. are all much akin to models of yester that they can wrap their heads around. And all the efforts and bottom-up policy driven by the RIRs in the current model will dry up, as will the RIR revenue sources, and their much wider contributions to the Internet community. If you think the RIRs and the current model sucks, well, consider the alternatives. For that matter, so to better the RIRs and their constituents. It's funny -- just yesterday, I was telling my class that the Internet's connectivity was not like the pre-deregulation telco model. The latter had O(1) telco/country, with highly regulated interconnections to anywhere else. The Internet grew up under the radar, partly because of the deregulatory climate and partly because especially in the early days, it wasn't facilities-based -- if you wanted an international link to a peer or a branch office, you just leased the circuit. The result was much richer connectivity than in the telco world, and -- in some sense -- less order. Syria wants to roll the clock back. I can't believe that the current model of more dense interconnection, continued disintermediation, and a far more robust IP fabric would evolve to be more resilient and robust from national Internet registry allocation models or the Internet routing system rearchitecting that's sure to follow. Of course, if the ITU-T is serious about this, they should probably be asking for a good chunk of 32-bit ASNs as well, but that's a bit more difficult to do under the auspices of liberating IPv6. -danny
Re: Locations with no good Internet (was ISP in Johannesburg)
On Fri, 2010-02-26 at 18:10 -0500, Paul Bosworth wrote: I think a lot of people often forget that ISPs are actually businesses trying to turn a profit. That sums it up pretty well. In a previous life I operated an ISP in a small town. When I entered the arena there was one other competitor, another independent ISP deploying 2.4GHz wireless. The RBOC and cable company weren't even considering rolling out high speed service but there was a definite demand, especially from the business community. I ended up having some measure of success deploying a mix of 2.4GHz and 900MHz wireless with DSL to fill in a few gaps. Before I sold the business my main competitor folded and the RBOC pushed out DSL. I think the local cable company joined the fray a couple years ago, too. My achilles heel wasn't having to compete with a goliath RBOC, it was all of the marketing. People would see ads on TV and in newspapers from providers who didn't even serve the area. When they were told sorry, no broadband for you from one of these national providers they would often accept that as a final answer. Folks often confused my wireless service with cellular or satellite access. They would have a hard time understanding why I could not provide them service well out of range of my POP where they could get four bars on their cell phone. Toward the end I floated the idea of a co-op but local politics prevailed over common sense and I quietly exited the business. Things are slightly better today but the areas that were underserved four years ago are still underserved. Population density will keep it that way for some time but I think people have better options today than a few years ago. My parents still only have 384k DSL but they are quite satisfied with it. Broadband co-ops will help in areas where local politics don't get in the way, but otherwise it is like Paul said, it's just business. That's my two cents, feel free to give change.
Re: Spamcop Blocks Facebook?
[ This discussion really should be on spam-l, not nanog. ] I'm not affiliated with Spamcop, however, it's well-known among those of us who work in this area that (a) Facebook has been spamming for quite some time and (b) they're not the only social network that's doing so. So it's not especially surprising that one or more DNSBLs/RHSBLs is/are listing them: they've earned it. Point of order, however: Spamcop blocks nothing. Mail system administrators who choose to use their resources may block or score or tag or ignore at their discretion. ---Rsk
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
Nick Hilliard (nick) writes: And the politicians. Yes, they will erupt in hitherto unseen outbursts of self-righteous indignation at the stupid internet engineers who let this problem happen in the first place and who made no provision whatsoever for viable alternatives, Um, not to be the party pooper of your fire-and-brimstone scenario, but IPv6 deployment has taken quite a bit longer than expected. I'm not saying that political incentives (carrot stick) or government regulations in the line of implement IPv6 before X/Y or else... have had any effect, except maybe in Japan: look how long it took for the EU commission to jump on the bandwagon, for instance (or for that matter, how long it took any government to take IP seriously). But if was asked why IPv6 hasn't been deployed earlier, I'd be hard pressed to come up with a simple answer.It wasn't ready is probably not considered good enough for an elected official. BOFH excuse generator anyone ? Oh, it will be fun. Yay.
RE: Spamcop Blocks Facebook?
There's more to it than just that Facebook themselves occasionally fit the profile of a spammer, and so some of the more stringent networks may filter mail from them. Facebook is a major source of drive-by malware, and some of the apps on Facebook tread close to the spyware/adware/parasite line and so other security tools/IP reputation services, depending on how they implement the blocks for the droppers, and other undesirables, may actually filter all traffic to/from the FB servers, as opposed to the dropper redirect or app/adware host. Regardless, for some subset of the world, reachability to various social networking sites is becoming less reliable. -Original Message- From: Rich Kulawiec [mailto:r...@gsp.org] Sent: Friday, February 26, 2010 7:15 PM To: nanog@nanog.org Subject: Re: Spamcop Blocks Facebook? [ This discussion really should be on spam-l, not nanog. ] I'm not affiliated with Spamcop, however, it's well-known among those of us who work in this area that (a) Facebook has been spamming for quite some time and (b) they're not the only social network that's doing so. So it's not especially surprising that one or more DNSBLs/RHSBLs is/are listing them: they've earned it. Point of order, however: Spamcop blocks nothing. Mail system administrators who choose to use their resources may block or score or tag or ignore at their discretion. ---Rsk
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
There is much political froth being stirred up here. I don't see what the big deal is. It was patently unfair not to give every country a one-digit country code like the US and Russia have. So they don't want to make the same mistake with IPv6. R's, John
Hotels in Tampa
I'm going to be in Tampa for two weeks turning up a 4G data center. Any recommendations on good hotels that allow smoking? -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
Re: Hotels in Tampa
tripadvisor.com probably has a lot of hotel reviews for you. carrier hotels that allow smoking (!) might be more on topic on nanog i guess? On Sat, Feb 27, 2010 at 11:40 AM, Joe Hamelin j...@nethead.com wrote: I'm going to be in Tampa for two weeks turning up a 4G data center. Any recommendations on good hotels that allow smoking? -- Suresh Ramasubramanian (ops.li...@gmail.com)
Level3 tonight in Washington/New York
Is anyone else seeing some serious Packet Loss from New York/Washington area within Level3's network tonight? I'm seeing around 5% packet loss.. -S
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
Date: Sat, 27 Feb 2010 12:04:12 +0800 From: Phil Regnauld regna...@nsrc.org Nick Hilliard (nick) writes: And the politicians. Yes, they will erupt in hitherto unseen outbursts of self-righteous indignation at the stupid internet engineers who let this problem happen in the first place and who made no provision whatsoever for viable alternatives, Um, not to be the party pooper of your fire-and-brimstone scenario, but IPv6 deployment has taken quite a bit longer than expected. I'm not saying that political incentives (carrot stick) or government regulations in the line of implement IPv6 before X/Y or else... have had any effect, except maybe in Japan: look how long it took for the EU commission to jump on the bandwagon, for instance (or for that matter, how long it took any government to take IP seriously). But if was asked why IPv6 hasn't been deployed earlier, I'd be hard pressed to come up with a simple answer.It wasn't ready is probably not considered good enough for an elected official. rant I'm sorry, but some people are spending too much time denying history. IPv6 has been largely ready for YEARS. Less than five years ago a lot of engineers were declaring IPv6 dead and telling people that double and triple NAT was the way of the future. It's only been over the past two years that a clear majority of the networks seemed to agree that IPv6 was the way out of the mess. (I know some are still in denial.) Among the mistakes made was the abandonment of NAT-PT as a transition mechanism. The BEHAVE working group has resurrected it and I still have hope of a decent system, but it has not happened as of today and we need it yesterday. Because so many network engineers or their managers decided that IPv6 was either not going to happen or was too far down the line to worry about, vendors got a clear message that there was no need to spend development money adding IPv6 support to products or implement it for their services. I won't go into the mistakes made by the IETF because they were doing something very un-IETF under tremendous time pressure. The standards were developed on paper with almost no working code. This was because the IETF assumed that we would run out of IPv4 long ago since the basics of IPv6 pre-date CIDR. They pre-date NAT. Yes, IPv6 has been around THAT long. At leat one network was running IPv6 on its network, available to users for testing for over 15 years ago. It's been a production service for years. Let's face reality. We have met the enemy and he is us. (Apologies to Walt Kelly.) We, the network engineers simply kept ignoring IPv6 for years after it was available. Almost all operating systems have been IPv6 capable for at least five years and most much longer. Most routers have been IPv6 ready for even longer. But we didn't move IPv6 into services nor offer it to customers. As a result, it just sat there. Code was not exercised and bugs were not found. Reasonable transition mechanisms are nowhere to be seen, and the cost of fixing this (or working around it) has grown to frightening proportions. /rant There is a lot of blame we can spread around, but take moment and look in a mirror while you parcel it out. I think we are more responsible for the situation than anyone else. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Chile (fyi)
Gettingreports of loss of connectivity to parts of chile They had an 8.5 a short while ago. Sent via BlackBerry from T-Mobile
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
On Fri, 2010-02-26 at 22:20 -0800, Kevin Oberman wrote: Let's face reality. We have met the enemy and he is us. (Apologies to Walt Kelly.) We, the network engineers simply kept ignoring IPv6 for years after it was available. Almost all operating systems have been IPv6 capable for at least five years and most much longer. Most routers have been IPv6 ready for even longer. But we didn't move IPv6 into services nor offer it to customers. As a result, it just sat there. Code was not exercised and bugs were not found. Reasonable transition mechanisms are nowhere to be seen, and the cost of fixing this (or working around it) has grown to frightening proportions. Say it brother! The fact of the matter is that by and large, the operator community not only ignored IPv6 but many poo-poo'ed it and diminished any amount of support for it from the small contingent of those who were willing to progress its deployment. In the past there were claims that it was immature and flawed but for the most part no one really wanted to commit themselves to putting up or shutting up. Meanwhile clued and semi-clued users watching from sidelines could do nothing but play in a vacuum and yell in frustration as their providers ignore them as well. I speaking as a demoralised user personally gave up begging my provider for IPv6 connectivity. Yes, there's always tunnels but that's not the answer for real deployment. Remember how well tunnels worked out for multicast? As a result, we are in a situation today where we are now scrambling to do the things that should have evolved naturally. Worse than stale code is stale procedures and the lack of long-term growth and embracement. What this means is that while we once could have taken the chance and deployed a less than perfect technology, gotten early adopters and slowly progressed mass-adoption, we are now in a position that we have to undergo a crash-course in training and operational procedures. Beyond that, the user community will need to be educated and even more effort will need to be made in order to make things user-friendly. And because of the heightened need for more modern features as well as security, I might argue that we are relatively less prepared in our IPv6 development from a software standpoint than during the infancy of the protocol. It is often much easier for everyone involved if you slowly raise the bar rather than suddenly springing an Olympic level high-jump upon them. -- /*=[ Jake Khuon kh...@neebu.net ]=+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==*/
