From swmike at swm.pp.se Sun Aug 1 00:19:45 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 1 Aug 2010 07:19:45 +0200 (CEST) Subject: T-Mobile IPv6 Beta In-Reply-To: References: Message-ID: On Sat, 31 Jul 2010, Stefan wrote: > Nokia N900: http://n900-ipv6.garage.maemo.org/ - worth giving it a shot ... Just as an FYI, the N900 Connection Manager (just like the Ubuntu Linux equivalent) doesn't consider getting an IPv6 address+DNS only (no IPv4) as being "connected", and considers the connection to be down and spews a failure message. The scripts linked above requires dual PDP contexts (one for v4 and one for v6) and this usually requires additional license ($$$) for SGSN and other parts of the mobile network. Some other Nokia phones actually support single IPv6 PDP context and thus work with NAT64 for instance. Ubuntu has no IPv6 focus at all as far as I can discern from reading tickets regarding IPv6, they seem content with what they get for "free" from the kernel and some 3rd party programs one has to install oneself. A lot of people in the support world (irc+forums etc) actively suggests disabling IPv6 for a lot of "slowness problems". We have a long road ahead of us... -- Mikael Abrahamsson email: swmike at swm.pp.se From joshua.klubi at gmail.com Sun Aug 1 00:31:17 2010 From: joshua.klubi at gmail.com (Joshua William Klubi) Date: Sun, 1 Aug 2010 05:31:17 +0000 Subject: T-Mobile IPv6 Beta In-Reply-To: References: Message-ID: Have you considered updating the Nokia n900 to the latest version of OS ie PR2 they fixed ipv6 stack Sent from My Google Nexus 1 > On Sat, 31 Jul 2010, Stefan wrote: > >> Nokia N900: http://n900-ipv6.garage.maemo.org/ - worth giving it a shot ... > > Just as an FYI, the N900 Connection Manager (just like the Ubuntu Linux > equivalent) doesn't consider getting an IPv6 address+DNS only (no IPv4) as > being "connected", and considers the connection to be down and spews a > failure message. The scripts linked above requires dual PDP contexts (one > for v4 and one for v6) and this usually requires additional license ($$$) > for SGSN and other parts of the mobile network. > > Some other Nokia phones actually support single IPv6 PDP context and thus > work with NAT64 for instance. > > Ubuntu has no IPv6 focus at all as far as I can discern from reading > tickets regarding IPv6, they seem content with what they get for "free" > from the kernel and some 3rd party programs one has to install oneself. > A lot of people in the support world (irc+forums etc) actively suggests > disabling IPv6 for a lot of "slowness problems". > > We have a long road ahead of us... > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > From swmike at swm.pp.se Sun Aug 1 00:51:17 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 1 Aug 2010 07:51:17 +0200 (CEST) Subject: T-Mobile IPv6 Beta In-Reply-To: References: Message-ID: On Sun, 1 Aug 2010, Joshua William Klubi wrote: > Have you considered updating the Nokia n900 to the latest version of OS ie > PR2 they fixed ipv6 stack I updated to PR1.2 when it was released (if this is what you mean) and all the tests were done with that. The stock kernel doesn't even have IPv6 as far as I could see, I had to use the power kernel referenced in the url earlier in the thread to get IPv6 at all. -- Mikael Abrahamsson email: swmike at swm.pp.se From kyhwana at gmail.com Sun Aug 1 05:28:55 2010 From: kyhwana at gmail.com (Daniel Richards) Date: Sun, 01 Aug 2010 22:28:55 +1200 Subject: T-Mobile IPv6 Beta In-Reply-To: References: Message-ID: <4C554C67.6070108@gmail.com> I believe Android 2.1 (And reportedly Apples iOS 4) do ipv6. Android 2.1 certainly works out of the box. I have a HTC Desire that just worked with my IPv6 setup at home. (DHCPv6 from my ISP to my Cisco 877 and then over wifi to the Desire.) On 1/08/2010 9:46 a.m., Cameron Byrne wrote: > Folks, > > T-Mobile USA has launched an IPv6 beta service and we are interested > in recruiting some friendly users as part of this trial service. > Right now, the service is only for T-Mobile USA subscribers in > T-Mobile USA coverage (no roaming) and only Nokia phones are > supported. > > For more info and discussion, please visit our group page > > http://groups.google.com/group/tmoipv6beta > > Thanks, > > Cameron > > From cb.list6 at gmail.com Sun Aug 1 09:07:05 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 1 Aug 2010 07:07:05 -0700 Subject: T-Mobile IPv6 Beta In-Reply-To: <4C554C67.6070108@gmail.com> References: <4C554C67.6070108@gmail.com> Message-ID: On Sun, Aug 1, 2010 at 3:28 AM, Daniel Richards wrote: > I believe Android 2.1 (And reportedly Apples iOS 4) do ipv6. > Android 2.1 certainly works out of the box. I have a HTC Desire that > just worked with my IPv6 setup at home. > (DHCPv6 from my ISP to my Cisco 877 and then over wifi to the Desire.) It is also my understanding that the latest Android and and iOS4 support IPv6, but only via the WiFi interface. The Nokia Symbians phones are the only ones that I know of that can do native IPv6-only. As Mikael pointed out, this is important. The Nokia Maemo N900 can do dual-stack, but it is "beta" and requires a fairly easy kernel upgrade .... but more development is going into it all the time and it is generally a very good device for the developer types. I consider the the Symbian phones as well as the applications in their Ovi App store to be real IPv6 production quality, they are mature and stable. You can go to the store and buy these phones off the shelf and ipv6 just works (assuming your carrier did not lock out those features). Nokia is way head of the curve on IPv6 and they should be recognized as such. It's nice to see Android and iOS bring IPv6 to WiFi as a first step, but they need to keep going. Here is a short thread on the Android IPv6 issue, it is really Qualcomm's issue at this point http://tinyurl.com/28nttno Cameron > > On 1/08/2010 9:46 a.m., Cameron Byrne wrote: >> Folks, >> >> T-Mobile USA has launched an IPv6 beta service and we are interested >> in recruiting some friendly users as part of this trial service. >> Right now, the service is only for T-Mobile USA subscribers in >> T-Mobile USA coverage (no roaming) and only Nokia phones are >> supported. >> >> For more info and discussion, please visit our group page >> >> http://groups.google.com/group/tmoipv6beta >> >> Thanks, >> >> Cameron >> >> > > > From feldman at twincreeks.net Mon Aug 2 00:26:14 2010 From: feldman at twincreeks.net (Steve Feldman) Date: Sun, 1 Aug 2010 22:26:14 -0700 Subject: [NANOG-announce] 2010 NANOG election timeline Message-ID: Hello NANOGers! Per the charter, we are approaching the annual NANOG election and appointment time. In addition to the series of "call for nominations" messages at the opening of each period, we thought to send an overview and time line ahead of the actual nominations opening. Hopefully this will get more of the eligible members of the community to consider standing for a role in one of the Committees that helps makes NANOG what it is. All nominations should be sent to nominations at nanog.org. The election timeline is: Aug. 2 - SC Nominations begin Aug. 24 - Charter discussed in Futures Aug. 24 - PC Nominations begin Aug. 30 - SC Candidate information posted/nominations close Sep. 13 - Call for Mailing List Committee nominations Sep. 21 - Ballot approved Oct. 3 - Voting opens at 12:00 EDT Oct. 4 - PC Candidate Information posted/nominations close Oct. 6 - Voting closes at 09:15 EDT, results announced before the close of NANOG 50. NANOG Steering Committee The NANOG Steering Committee works closely with Merit to promote, support and improve NANOG. The Steering Committee is responsible for the selection of the Program Committee and the Comunications Committee, and is the community's instrument for ensuring that the NANOG organization remains open, relevant and useful. Elections for three of the seven positions on the Steering Committee will be held in October 2010. The currently-serving Steering Committee members whose terms are expiring are Patrick Gilmore, Joe Provo, and Rob Seastrom. Joe has served two consecutive terms so per the charter, he cannot be considered for re-election until October 2011. Other than being an eligible voter, there are no restrictions on eligible candidates. Steering Committee members must commit to attending two out of every three annual NANOG meetings per the charter (6.2.6). A good candidate will have experience with Internet engineering, operations, and governance organizations as well as the principles and practices which guide them. Consensus organizing, leadership, outreach and communication skills are prized. NANOG Program Committee The Program Committee is a group of sixteen individuals from the NANOG community who together are responsible for the solicitation and selection of material for NANOG meeting Programs. A new Program Committee will be selected by the Steering Committee after the election in October. Eight positions are to be filled. The currently-serving Program Committee members whose terms are expiring are Nina Bargisen, Tom Daly, Brian Deardorff, Igor Gashinsky, Mike Hughes, David Meyer, Tom Scholl and Richard Steenbergen. Furthermore, Igor, Mike and Richard have all served two consecutive terms so per the charter, they cannot be considered for another Program Committee appointment until October 2011. Per the NANOG charter (6.2.1), eligible candidates are individuals who have attended at least one NANOG meeting in the past 12 months (one or more of NANOG 48, NANOG 49 or NANOG 50). Broad technical knowledge of Internet operations and familiarity with NANOG meetings are useful attributes. Having constructive opinions and ideas about how NANOG meetings might be improved is of high value. NANOG Communications Committee The Communications Committee is a group of five individuals from the NANOG community who together are responsible for the administration and moderation of the NANOG mailing lists. A new Communications Committee will be selected by the Steering Committee after the election in October. Two positions are to be filled. The currently-serving Communications Committee members whose terms are expiring are Randy Epstein and Tim Yocum. The main NANOG mailing list serves an important role in the community by providing a day-to-day forum for network operators. Participating in the CC gives you the opportunity to make a noticeable contribution. The CC is covered under section 7.1.2 of the NANOG charter. Why? If you care about NANOG as a set of fora and think you would like to take a turn at volunteering your time to help make it better, please consider either volunteering yourself or nominating someone else. Also, as NANOG evolves into a fully self-governed organization, these committees will play an increasingly important role in our success. By joining now, you can be an integral part of the process. For more information about the role of any Committee, or to find out more about what's involved in being a Committee member, please do consult the current NANOG charter or contact someone who is already serving and ask them directly. Thanks, Steve Feldman on behalf of the NANOG Steering Committee _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From Steven.Glogger at swisscom.com Mon Aug 2 08:02:33 2010 From: Steven.Glogger at swisscom.com (Steven.Glogger at swisscom.com) Date: Mon, 2 Aug 2010 15:02:33 +0200 Subject: Cisco ASR BGP within the box question Message-ID: <1FC8A0BAFBBD9749BB1F06010D23C8A505BD093AC9@sg000035.corproot.net> hi all just a short question (related to a quite new feature from cisco). with the new cisco ASR software (15.0(1)S - released some days ago) it is able to do BGP on the same box. we need this feature because we use the VASI interfaces to bring and filter traffic from one VRF to another VRF and performing firewalling (ZBF). basically we have on the box: [VRF_A via vasileft1]--[VRF_B via vasiright1] and the box itself speaks BGP on VRF_B with some RR's: [ASRBox] ---- (RR) ---- [anotherbox] the fun part is, if you want to announce (e.g. 0.0.0.0/0) from VRF_B (announced from anotherbox) to VRF_A it should be possible now with that new feature. according to BGP I need to configure the VRF_A peer as route-reflector-client so the routes from the anotherbox get reflected via RR to VRF_B. but, it seems that the router itself needs to be tricked, since he thinks that both peers are in the same route-reflector cluster ("DENIED due to: reflected from the same cluster"): Aug 2 13:35:03: BGP(0): 213.3.246.33 send UPDATE (format) 0.0.0.0/0, next 10.62.112.65, metric 0, path 44038 3303, extended community RT:65501:1702 Aug 2 13:35:03: BGP(0): 213.3.246.34 rcv UPDATE w/ attr: nexthop 10.62.112.65, origin i, localpref 250, metric 0, originator 10.62.112.65, clusterlist 10.62.112.79 10.62.112.17, merged path 44038 3303, AS_PATH , community Aug 2 13:35:03: BGP(0): 213.3.246.34 rcv UPDATE about 0.0.0.0/0 -- DENIED due to: reflected from the same cluster; Aug 2 13:35:03: BGP: 213.3.246.34 Modifying prefix 0.0.0.0/0 from 0 -> 4 address so, this is my config: config: interface vasileft1 ip vrf forwarding VRF_A ip address 10.0.0.1 255.255.255.252 zone-member security VASILEFT ! interface vasiright1 ip vrf forwarding VRF_B ip address 10.0.0.2 255.255.255.252 zone-member security VASIRIGHT ! router bgp 65501 address-family ipv4 vrf IABIP- bgp router-id 10.0.0.1 redistribute connected redistribute static neighbor 10.0.0.2 remote-as 65501 neighbor 10.0.0.2 update-source vasileft1 neighbor 10.0.0.2 activate neighbor 10.0.0.2 send-community both neighbor 10.0.0.2 next-hop-self exit-address-family ! address-family ipv4 vrf IACYP- import path selection multipaths bgp router-id 10.0.0.2 redistribute connected redistribute static route-map SET-PREFIX-SoO neighbor 10.0.0.1 remote-as 65501 neighbor 10.0.0.1 update-source vasiright1 neighbor 10.0.0.1 activate neighbor 10.0.0.1 send-community both neighbor 10.0.0.1 next-hop-self exit-address-family what does not works: - having another AS number on the same box (otherwise eBGP would be possible) - client-to-client reflection - magic stuff in route-map - setting different cluster-id's for different address-families - nothing found in the release notes: http://www.cisco.com/en/US/docs/ios/ios_xe/3/release/notes/asr1k_rn_3s_rel_notes.html so, does anyone knows a nice hidden command to disable this cluster-checking on a per-peer basis or so? -steven From jmaimon at ttec.com Mon Aug 2 10:23:20 2010 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 02 Aug 2010 11:23:20 -0400 Subject: Cisco ASR BGP within the box question In-Reply-To: <1FC8A0BAFBBD9749BB1F06010D23C8A505BD093AC9@sg000035.corproot.net> References: <1FC8A0BAFBBD9749BB1F06010D23C8A505BD093AC9@sg000035.corproot.net> Message-ID: <4C56E2E8.90200@ttec.com> I sure hope you have better luck than I did. http://www.mail-archive.com/cisco-nsp at puck.nether.net/msg20125.html Steven.Glogger at swisscom.com wrote: > hi all > > just a short question (related to a quite new feature from cisco). > with the new cisco ASR software (15.0(1)S - released some days ago) it is able to do BGP on the same box. > we need this feature because we use the VASI interfaces to bring and filter traffic from one VRF to another VRF and performing firewalling (ZBF). > > basically we have on the box: > [VRF_A via vasileft1]--[VRF_B via vasiright1] > > and the box itself speaks BGP on VRF_B with some RR's: > [ASRBox] ---- (RR) ---- [anotherbox] > > the fun part is, if you want to announce (e.g. 0.0.0.0/0) from VRF_B (announced from anotherbox) to VRF_A it should be possible now with that new feature. > > according to BGP I need to configure the VRF_A peer as route-reflector-client so the routes from the anotherbox get reflected via RR to VRF_B. > > but, it seems that the router itself needs to be tricked, since he thinks that both peers are in the same route-reflector cluster ("DENIED due to: reflected from the same cluster"): > > Aug 2 13:35:03: BGP(0): 213.3.246.33 send UPDATE (format) 0.0.0.0/0, next 10.62.112.65, metric 0, path 44038 3303, extended community RT:65501:1702 > > Aug 2 13:35:03: BGP(0): 213.3.246.34 rcv UPDATE w/ attr: nexthop 10.62.112.65, origin i, localpref 250, metric 0, originator 10.62.112.65, clusterlist 10.62.112.79 10.62.112.17, merged path 44038 3303, AS_PATH , community > > Aug 2 13:35:03: BGP(0): 213.3.246.34 rcv UPDATE about 0.0.0.0/0 -- DENIED due to: reflected from the same cluster; > > Aug 2 13:35:03: BGP: 213.3.246.34 Modifying prefix 0.0.0.0/0 from 0 -> 4 address > > > so, this is my config: > > > config: > > interface vasileft1 > ip vrf forwarding VRF_A > ip address 10.0.0.1 255.255.255.252 > zone-member security VASILEFT > ! > interface vasiright1 > ip vrf forwarding VRF_B > ip address 10.0.0.2 255.255.255.252 > zone-member security VASIRIGHT > ! > > router bgp 65501 > address-family ipv4 vrf IABIP- > bgp router-id 10.0.0.1 > redistribute connected > redistribute static > neighbor 10.0.0.2 remote-as 65501 > neighbor 10.0.0.2 update-source vasileft1 > neighbor 10.0.0.2 activate > neighbor 10.0.0.2 send-community both > neighbor 10.0.0.2 next-hop-self > > exit-address-family > ! > address-family ipv4 vrf IACYP- > import path selection multipaths > bgp router-id 10.0.0.2 > redistribute connected > redistribute static route-map SET-PREFIX-SoO > neighbor 10.0.0.1 remote-as 65501 > neighbor 10.0.0.1 update-source vasiright1 > neighbor 10.0.0.1 activate > neighbor 10.0.0.1 send-community both > neighbor 10.0.0.1 next-hop-self > exit-address-family > > > > > > what does not works: > - having another AS number on the same box (otherwise eBGP would be possible) > - client-to-client reflection > - magic stuff in route-map > - setting different cluster-id's for different address-families > - nothing found in the release notes: http://www.cisco.com/en/US/docs/ios/ios_xe/3/release/notes/asr1k_rn_3s_rel_notes.html > > so, does anyone knows a nice hidden command to disable this cluster-checking on a per-peer basis or so? > > > -steven > > > > From mlarson at verisign.com Mon Aug 2 14:30:49 2010 From: mlarson at verisign.com (Matt Larson) Date: Mon, 2 Aug 2010 15:30:49 -0400 Subject: DNSSEC Launched Today by EDUCAUSE and VeriSign Message-ID: <20100802192926.GE1338@dul1mcmlarson-l1.labs.vrsn.com> With Becky Granger's permission, I'm pleased to share the announcement below. Matt ----- Forwarded message from Becky Granger ----- From: Becky Granger Subject: [Dnssec-deployment] DNSSEC Launched Today by EDUCAUSE and VeriSign To: dnssec-deployment at dnssec-deployment.org, DNSSEC at internet2.edu, dnssec at educause.edu Date: Mon, 2 Aug 2010 11:06:01 -0600 Hello all - I wanted to let you know that DNSSEC is now supported in the .edu domain. Please feel free to pass the word! --Becky Becky Granger, CAE Director, Information Technology and Member Services EDUCAUSE - Uncommon Thinking for the Common Good (303) 939-0334 www.educause.edu EDUCAUSE Annual Conference - The best thinking in higher ed IT? October 12-15, 2010? |? Anaheim, CA www.educause.edu/e10 -----Original Message----- From: EDUCAUSE [mailto:educause at educause.edu] Sent: Monday, August 02, 2010 10:32 AM To: Staff Subject: DNSSEC Launched Today by EDUCAUSE and VeriSign FOR IMMEDIATE RELEASE Contact: Greg Jackson Vice President EDUCAUSE gjackson at educause.edu 202-331-5351 *********************************************** DNSSEC Launched Today by EDUCAUSE and VeriSign *********************************************** August 2, 2010, Boulder, Colorado--EDUCAUSE and VeriSign announced the deployment of a security system known as Domain Name Security Extensions (DNSSEC) within the .edu portion of the Internet, which EDUCAUSE manages under a cooperative agreement with the U.S. Department of Commerce. Institutions whose domain names end in .edu will now be able to utilize digital signatures to mitigate certain DNS security vulnerabilities, such as cache poisoning and man-in-the-middle attacks. The Domain Name System (DNS) is the part of the Internet that translates names such as "example.edu" into numeric addresses (for example, 198.59.61.90). All Internet applications-from electronic mail to online banking-depend on the accuracy and integrity of this translation. Over the years, Internet security experts have discovered a variety of ways that DNS translation may be compromised. The DNSSEC security system limits the problem by allowing owners of domain names to use digital signatures to add an extra level of authentication to the translation process. Deploying DNSSEC for .edu furthers the initiative to enhance domain name security throughout the broader scope of the internet. As a precursor to deployment, EDUCAUSE and VeriSign hosted a testbed environment which allowed end-to-end testing by selected .edu domain holders in a non production environment. Brian Voss, vice chancellor for IT and CIO at Louisiana State University and current chair of the joint EDUCAUSE/Internet2 Higher Education Information Security Council, noted, "I am proud that LSU is at the forefront of this exciting development and that our contributions and efforts as a testbed for .edu deployment have laid a foundation for the ubiquitous adoption of DNSSEC, so that the research and education community can eventually realize its full value," Voss also added, "DNSSEC represents an evolution in Internet reliability and security, and I know that my CIO colleagues recognize that our university communities expect our networks to be secure, and improving the security of our root Domain Name System through cryptography is something we all will embrace." EDUCAUSE President and CEO Diana Oblinger said, "EDUCAUSE has appreciated the opportunity to work with VeriSign and the U.S. Department of Commerce to advance the security and integrity of the Internet through early testing and deployment of DNSSEC. Dating from the creation of ARPANET through the present day, the higher education technology community has played a leading role in the development of the Internet as a platform for learning, discovery, and engagement. We have been happy to continue that role by being a lead partner in the launch of DNSSEC." Pat Kane, vice president of VeriSign, stated, "VeriSign's partnership with EDUCAUSE to test and deploy DNSSEC in the .edu domain demonstrates our ongoing commitment to a secure Internet infrastructure. VeriSign appreciates the close collaboration with EDUCAUSE and the U.S. Department of Commerce that allowed for success with this process and the opportunity to generate lessons learned which we are actively sharing with other domain registrars, thereby enhancing overall Internet security." ************************************* About EDUCAUSE EDUCAUSE is a nonprofit association and the foremost community of IT leaders and professionals committed to advancing higher education. EDUCAUSE programs and services are focused on analysis, advocacy, community building, professional development, and knowledge creation because IT plays a transformative role in higher education. EDUCAUSE supports those who lead, manage, and use information technology through a comprehensive range of resources and activities. For more information, visit www.educause.edu. ----- End forwarded message ----- From infolacnog at lacnog.org Mon Aug 2 18:26:51 2010 From: infolacnog at lacnog.org (LACNOG 2010) Date: Mon, 2 Aug 2010 20:26:51 -0300 Subject: LACNOG 2010 - Call for Presentations now available In-Reply-To: References: Message-ID: The Network Operators Group of Latin America and the Caribbean, LACNOG, will have its first conference LACNOG 2010 in Sao Paulo, Brazil, from 19th to 22nd of October jointly with the fourteenth LACNIC meeting (LACNIC XIV) and the PTT Forum organized by NIC.br. For more information on LACNOG 2010, please visit http://www.lacnog.org This is the initial public call for presentations for the event. The schedule for the selection of works will be the following: ? ? ? ?? Deadline for the reception of proposals: Monday, 27 August 2010 ? ? ? ?? Notification of proposal acceptance: Tuesday, 10 September 2010 ? ? ? ?? Deadline for the submission of final versions: Thursday, 30 September 2010 The submission of presentations for the LACNOG 2010 is subject to the following conditions: ? ? ? ?? English, Portuguese and Spanish are the accepted languages. ? ? ? ?? Presentations must be sent in Portable Document Format (PDF). ? ? ? ?? Presentations must not exceed twenty-five (25) minutes. Those interested in presenting their work should send the following data, within the timeframe specified above, to the following address: lacnog2010 at lacnog.org ? ? ? ?? Complete title of the presentation. ? ? ? ?? Extended abstract plus a draft of the slides or the complete article if it were available. ? ? ? ?? Complete name(s), email address(es), biographical data and organization(s) of which the interested parties are a part of or represent. For further information, please don't hesitate to contact the Program Committee at comite_lacnog at lacnog.org. For more information on LACNOG 2010, please visit http://www.lacnog.org From feldman at twincreeks.net Mon Aug 2 19:31:09 2010 From: feldman at twincreeks.net (Steve Feldman) Date: Mon, 2 Aug 2010 17:31:09 -0700 Subject: [NANOG-announce] NANOG Steering Committee nominations now open Message-ID: Elections for three of the six elected positions on the NANOG Steering Committee will be held in October, 2010, for two-year terms ending in October, 2012. The current SC members whose terms are expiring are Patrick Gilmore, Joe Provo, and Robert Seastrom. Joe is finishing his second consecutive term, so per the charter, cannot be considered for reelection until October 2011. If you care about NANOG as a forum, and think you would like to take a turn at volunteering your time to help make it better, please consider either volunteering yourself or nominating someone else. For more information about the role of the Steering Committee, or to find out more about what's involved in being a Steering Committee member, please consult the NANOG charter or contact someone who is already serving and ask them directly. http://www.nanog.org/governance/charter/ http://www.nanog.org/governance/steering/steeringcommittee.php Per the charter, Steering Committee members must attend at least two of three NANOG meetings per year while in office. HOW TO NOMINATE SOMEONE You may nominate someone else, or yourself. There is no limit to the number of nominations that may be submitted by a single person. Individual nominees will be contacted directly to confirm that they are willing to accept the nomination, and so that they can supply a biography for the NANOG web page. To submit a nomination, send the nominee's full name and contact details to nominations at nanog.org. The deadline for nominations is 11:59 PM EDT on Monday, August 30. The candidates will be given an opportunity to make brief comments and/ or accept questions from the community at the NANOG 50 Community Meeting on Sunday, October 3. As a reminder, the full election timeline is: Aug. 2 - SC Nominations begin Aug. 24 - Potential charter amendments discussed in nanog-futures Aug. 24 - PC Nominations begin Aug. 30 - SC Candidate information posted/nominations close Sep. 13 - Call for Mailing List Committee nominations Sep. 21 - Ballot approved Oct. 3 - Voting opens at 12:00 EDT Oct. 4 - PC Candidate Information posted/nominations close Oct. 6 - Voting closes at 09:15 EDT, results announced before the close of NANOG 50. For the SC, Steve Feldman _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From Steven.Glogger at swisscom.com Tue Aug 3 03:13:15 2010 From: Steven.Glogger at swisscom.com (Steven.Glogger at swisscom.com) Date: Tue, 3 Aug 2010 10:13:15 +0200 Subject: [c-nsp] Cisco ASR BGP within the box question In-Reply-To: <6E4D2678AC543844917CA081C9D6B33F0247F8B2@XMB-AMS-103.cisco.com> References: <1FC8A0BAFBBD9749BB1F06010D23C8A505BD093AC9@sg000035.corproot.net> <6E4D2678AC543844917CA081C9D6B33F0247F8B2@XMB-AMS-103.cisco.com> Message-ID: <1FC8A0BAFBBD9749BB1F06010D23C8A505BD093FFA@sg000035.corproot.net> thanks oliver, will try and keep you (and the list) updated. -steven -----Original Message----- From: Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com] Sent: Tuesday, August 03, 2010 8:06 AM To: Glogger Steven, SCS-NIT-NIO-PIO-DNW-NEO; cisco-nsp at puck.nether.net; nanog at nanog.org Subject: RE: [c-nsp] Cisco ASR BGP within the box question Steven, > just a short question (related to a quite new feature from cisco). > with the new cisco ASR software (15.0(1)S - released some days ago) it is > able to do BGP on the same box. > we need this feature because we use the VASI interfaces to bring and filter > traffic from one VRF to another VRF and performing firewalling (ZBF). > > basically we have on the box: > [VRF_A via vasileft1]--[VRF_B via vasiright1] > > and the box itself speaks BGP on VRF_B with some RR's: > [ASRBox] ---- (RR) ---- [anotherbox] > > the fun part is, if you want to announce (e.g. 0.0.0.0/0) from VRF_B > (announced from anotherbox) to VRF_A it should be possible now with that new > feature. > > according to BGP I need to configure the VRF_A peer as route-reflector- > client so the routes from the anotherbox get reflected via RR to VRF_B. > > but, it seems that the router itself needs to be tricked, since he thinks > that both peers are in the same route-reflector cluster ("DENIED due to: > reflected from the same cluster"): >[...] > so, does anyone knows a nice hidden command to disable this cluster-checking > on a per-peer basis or so? I'm not aware of an enhancement to set the cluster-id on a per-vrf basis, it is currently global.. But you could turn this into an eBGP session using local-as, for example router bgp 65501 address-family ipv4 vrf IABIP- neighbor 10.0.0.2 remote-as 65502 neighbor 10.0.0.2 local-as 65503 no-prepend replace-as address-family ipv4 vrf IACYP- neighbor 10.0.0.1 remote-as 65503 neighbor 10.0.0.1 local-as 65502 no-prepend replace-as not sure if this helps.. oli From joe.abley at icann.org Tue Aug 3 11:59:48 2010 From: joe.abley at icann.org (Joe Abley) Date: Tue, 03 Aug 2010 16:59:48 +0000 Subject: IANA DNSSEC Testbed to be Decommissioned Message-ID: Colleagues, ICANN has operated the IANA DNSSEC testbed, serving non-production, signed versions of the root, ARPA, IN-ADDR.ARPA, IP6.ARPA, IRIS.ARPA, URN.ARPA, and INT zones for several years. Following the recent completion of DNSSEC deployment in the root zone, this testbed is scheduled to be decommissioned. For more details on the IANA DNSSEC testbed, see . For more details on DNSSEC deployment in the Root Zone, see . At the time that the service is decommissioned, the nameserver bound to NS.IANA.ORG (208.77.188.32, 2620:0:2d0:1::32) will be shut down and DNS queries to NS.IANA.ORG will fail with ICMP type 3 code 3 (Destination Unreachable, Port Unreachable). We suggest that anybody using the DNSSEC testbed for anything resembling production services make plans to stop doing so at their earliest convenience. ICANN would like to thank Packet Clearing House (PCH) and Dun.com DynTLD for their support and generous donation of global DNS resources to the IANA DNSSEC testbed. DRAFT TIMELINE Wed 2010-08-03 First public notice (this message) Wed 2010-08-25 Second public notice (reminder) Wed 2010-09-01 IANA DNSSEC Testbed is shut down Wed 2010-09-01 Third public notice (confirming work complete) Regards, Joe Abley Director DNS Operations, ICANN From randy at psg.com Tue Aug 3 12:09:16 2010 From: randy at psg.com (Randy Bush) Date: Tue, 03 Aug 2010 19:09:16 +0200 Subject: migration tools Message-ID: know any tools, not methods, tools, to o migrate a network from one igp to another (e.g. ospf to is-is), o merge two networks which have common igp but are currently ebgp, o ... think mergers and acquisitions (no i am not gonna do it again:) randy From joe.abley at icann.org Tue Aug 3 12:29:37 2010 From: joe.abley at icann.org (Joe Abley) Date: Tue, 03 Aug 2010 17:29:37 +0000 Subject: IANA DNSSEC Testbed to be Decommissioned Message-ID: > ICANN would like to thank Packet Clearing House (PCH) and Dun.com > DynTLD for their support and generous donation of global DNS > resources to the IANA DNSSEC testbed. My apologies to the good people at Dyn -- of course, that should be dyn.com, not what I wrote. Joe From ml at kenweb.org Tue Aug 3 18:07:47 2010 From: ml at kenweb.org (ML) Date: Tue, 03 Aug 2010 19:07:47 -0400 Subject: Question of privacy with reassigned resources Message-ID: <4C58A143.3080709@kenweb.org> As an SP in the MDU (multi dwelling unit) market we dutifully SWIP netblocks for each apartment complex/condo/etc. Doing such we publically publish the physical address an IP lives (sans Apt/Unit #). Would anyone feel this is too much information for people to know? Should our SWIPs be more generic, local POP address or local corporate office, just enough for rough geolocation accuracy? I realize what ARIN prefers, this is more of an opinion gathering. -ML From franck at genius.com Tue Aug 3 18:14:27 2010 From: franck at genius.com (Franck Martin) Date: Wed, 4 Aug 2010 11:14:27 +1200 (FJT) Subject: Question of privacy with reassigned resources In-Reply-To: <4C58A143.3080709@kenweb.org> Message-ID: <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> If it is a business, then accurate address does not seem to me an issue, if it is a private address, I think a bit of fuzziness is helpful ----- Original Message ----- From: "ML" To: nanog at nanog.org Sent: Wednesday, 4 August, 2010 11:07:47 AM Subject: Question of privacy with reassigned resources As an SP in the MDU (multi dwelling unit) market we dutifully SWIP netblocks for each apartment complex/condo/etc. Doing such we publically publish the physical address an IP lives (sans Apt/Unit #). Would anyone feel this is too much information for people to know? Should our SWIPs be more generic, local POP address or local corporate office, just enough for rough geolocation accuracy? I realize what ARIN prefers, this is more of an opinion gathering. -ML From bill at herrin.us Tue Aug 3 18:35:17 2010 From: bill at herrin.us (William Herrin) Date: Tue, 3 Aug 2010 19:35:17 -0400 Subject: Question of privacy with reassigned resources In-Reply-To: <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> References: <4C58A143.3080709@kenweb.org> <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Tue, Aug 3, 2010 at 7:14 PM, Franck Martin wrote: > If it is a business, then accurate address does not seem to me an > issue, if it is a private address, I think a bit of fuzziness is helpful An apartment complex/condo/etc is a business which contains private addresses. Do you sell to the residents directly or do you sell to the apartment complex which then resells to individual residents? If the former then you're basically off the hook for anybody who doesn't get a /29 or larger. For the latter, you're providing significant amounts of a public resource (IP addresses) to a business whose contact information you're contractually and ethically obligated to reveal. If a particular complex is worried about publishing their location, they can always rent a P.O. box. If you're the only one doing the worrying, don't. IMO. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tglassey at earthlink.net Tue Aug 3 18:40:36 2010 From: tglassey at earthlink.net (todd glassey) Date: Tue, 03 Aug 2010 16:40:36 -0700 Subject: Question of privacy with reassigned resources In-Reply-To: <4C58A143.3080709@kenweb.org> References: <4C58A143.3080709@kenweb.org> Message-ID: <4C58A8F4.9090307@earthlink.net> On 8/3/2010 4:07 PM, ML wrote: > As an SP in the MDU (multi dwelling unit) market we dutifully SWIP > netblocks for each apartment complex/condo/etc. Doing such we > publically publish the physical address an IP lives (sans Apt/Unit #). > > Would anyone feel this is too much information for people to know? > Should our SWIPs be more generic, local POP address or local corporate > office, just enough for rough geolocation accuracy? > > I realize what ARIN prefers, this is more of an opinion gathering. > -ML > > > > CALEA may come into play there meaning that there is no privacy per se. Todd From mrp at mrp.net Tue Aug 3 19:45:51 2010 From: mrp at mrp.net (Mark Prior) Date: Wed, 04 Aug 2010 10:15:51 +0930 Subject: Fwd: [AusNOG] AusNOG 04 Reminder, 6 weeks to go! Message-ID: <4C58B83F.70709@mrp.net> FYI. Mark. -------- Original Message -------- Subject: [AusNOG] AusNOG 04 Reminder, 6 weeks to go! Date: Mon, 2 Aug 2010 19:08:18 +1000 From: Terry Manderson To: ausnog at ausnog.net Dear Colleagues, Just reminding you that AusNOG 04 is just 6 weeks away on the 16th and 17th of September at the Four Seasons, Sydney. We'd like to take a moment to highlight that AusNOG 04 *IS* the premier networking event for our industry in Australia for 2010. Apart from the fantastic opportunities you will have for (people) networking with national and international technology experts, we have a wonderful set of speakers for this year. In Sydney at AusNOG 04 you will have to opportunity to hear presentations from such industry luminaries as: Vijay Gill, Google Joe Abley, ICANN Marty Gauvin, Tier 5 and Roland Dobbins, Arbor Networks These speakers will cover such topics as warehouse scale computing, the DNS root signing, data centre design, and the security implications of the NBN. Along with the opportunity to listen to a host of other quality speakers, let us not forget the AusNOG dinner where many friendships and good memories are made! As you may be aware AusNOG 04 is now accepting registrations at: https://secure.ausnog.net/signup We are looking forward to seeing you at AusNOG 04! Kind Regards Terry Manderson (For the AusNOG Board) _______________________________________________ AusNOG mailing list AusNOG at lists.ausnog.net http://lists.ausnog.net/mailman/listinfo/ausnog From morrowc.lists at gmail.com Tue Aug 3 20:48:02 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 3 Aug 2010 21:48:02 -0400 Subject: Question of privacy with reassigned resources In-Reply-To: <4C58A8F4.9090307@earthlink.net> References: <4C58A143.3080709@kenweb.org> <4C58A8F4.9090307@earthlink.net> Message-ID: On Tue, Aug 3, 2010 at 7:40 PM, todd glassey wrote: > ?On 8/3/2010 4:07 PM, ML wrote: >> As an SP in the MDU (multi dwelling unit) market we dutifully SWIP >> netblocks for each apartment complex/condo/etc. ?Doing such we >> publically publish the physical address an IP lives (sans Apt/Unit #). >> >> Would anyone feel this is too much information for people to know? >> Should our SWIPs be more generic, local POP address or local corporate >> office, just enough for rough geolocation accuracy? >> >> I realize what ARIN prefers, this is more of an opinion gathering. >> -ML >> >> >> >> > CALEA may come into play there meaning that there is no privacy per se. calea != ARIN policies... the above comment is a red-herring/fud. reading the policies (roughly paraphrased) I'd say you need to (depending where you line up with william's questions) A swip the block the building uses (postal address probably fine) - presumes +/29 to a building, of course B swip as 'residential' anything larger than a /29 that lands at a single dwelling being used for residential things C swip as a normal record anything larger than a /29 that lands at a single dwelling but considered a 'business' as examples of these: A - 1515 Connecticut Ave, Washington DC - The Regency Towers Apartments (fictitious apartment building) B - Private customer - Verizon Internet Services Inc. FTTP (Joe Plumber Apartment #5 inside The Regency Towers Apartments) C - Joes Plumbing and Handyman services - Apt #5 1515 Connecticut Ave (the business address at that apartment location) -chris From mirkomaffioli at gmail.com Wed Aug 4 08:14:28 2010 From: mirkomaffioli at gmail.com (Mirko Maffioli) Date: Wed, 4 Aug 2010 15:14:28 +0200 Subject: Appliance Vs Software based routers In-Reply-To: <4C4C873B.4010209@daemon.be> References: <20100725082137.GV28859@skywalker.creative.net.au> <4C4C873B.4010209@daemon.be> Message-ID: 2010/7/25 Laurens Vets : > > Cisco PIX: no, Cisco ASA: yes. It even runs under VMware... ?It's however > very hackish... :) Cisco ASA under VMware?? :| -- Ciao Mirko From kiwi at oav.net Wed Aug 4 08:53:57 2010 From: kiwi at oav.net (Xavier Beaudouin) Date: Wed, 4 Aug 2010 15:53:57 +0200 Subject: Appliance Vs Software based routers In-Reply-To: References: <20100725082137.GV28859@skywalker.creative.net.au> <4C4C873B.4010209@daemon.be> Message-ID: <2E43B2DA-0094-4530-83E2-8B351974471A@oav.net> Le 4 ao?t 2010 ? 15:14, Mirko Maffioli a ?crit : > 2010/7/25 Laurens Vets : >> >> Cisco PIX: no, Cisco ASA: yes. It even runs under VMware... It's however >> very hackish... :) > > Cisco ASA under VMware?? :| CiscoASA is based on x86, there is no reasons you cannot run this into VMWare or Xen... Xavier From daryl at introspect.net Wed Aug 4 09:53:34 2010 From: daryl at introspect.net (Daryl G. Jurbala) Date: Wed, 4 Aug 2010 10:53:34 -0400 Subject: Appliance Vs Software based routers In-Reply-To: <2E43B2DA-0094-4530-83E2-8B351974471A@oav.net> References: <20100725082137.GV28859@skywalker.creative.net.au> <4C4C873B.4010209@daemon.be> <2E43B2DA-0094-4530-83E2-8B351974471A@oav.net> Message-ID: <880D6793-00B5-428E-B484-471A406F2FA4@introspect.net> On Aug 4, 2010, at 9:53 AM, Xavier Beaudouin wrote: > > Le 4 ao?t 2010 ? 15:14, Mirko Maffioli a ?crit : > >> 2010/7/25 Laurens Vets : >>> >>> Cisco PIX: no, Cisco ASA: yes. It even runs under VMware... It's however >>> very hackish... :) >> >> Cisco ASA under VMware?? :| > > CiscoASA is based on x86, there is no reasons you cannot run this into VMWare or Xen... If that were the only qualification, PIX builds for the 515s would run under VMWare or XEN as well. Maybe they do, but I've never seen it. From Vinny_Abello at dell.com Wed Aug 4 09:54:22 2010 From: Vinny_Abello at dell.com (Abello, Vinny) Date: Wed, 4 Aug 2010 09:54:22 -0500 Subject: Recommended 1Gb SFP for ~115km? Message-ID: Hello, Any pointers on real world experience on this topic would greatly be appreciated. What are people using successfully out there as far as third party SFP's go to hit a distance of approximately 115km? This would be for a Catalyst 6506. Cisco's solution was a much more costly EDFA solution, but I see plenty of vendors that make SFP's for Gigabit Ethernet that range from 115km to 150km and more. I know these are not supported by Cisco and TAC won't troubleshoot if they are in the switch. I'm willing to work around that should I need TAC assistance on the switch. What works well for a single wavelength solution at this distance without having to switch to DWDM? This circuit will have duplex fibers. Thanks! -Vinny -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5187 bytes Desc: not available URL: From mwalter at 3z.net Wed Aug 4 09:56:54 2010 From: mwalter at 3z.net (Mike Walter) Date: Wed, 4 Aug 2010 10:56:54 -0400 Subject: Appliance Vs Software based routers In-Reply-To: <880D6793-00B5-428E-B484-471A406F2FA4@introspect.net> References: <20100725082137.GV28859@skywalker.creative.net.au><4C4C873B.4010209@daemon.be><2E43B2DA-0094-4530-83E2-8B351974471A@oav.net> <880D6793-00B5-428E-B484-471A406F2FA4@introspect.net> Message-ID: I assume the ASA's don't run natively on VMware or Xen, I assume you have to use something like GNS3. I think that would be fine for testing, but in real world production running an ASA on GNS3 under an another OS seems like a bad idea. I hope Cisco will come out with Virtual Appliances for some of their products like they did for the Nexus 1000V. -Mike -----Original Message----- From: Daryl G. Jurbala [mailto:daryl at introspect.net] Sent: Wednesday, August 04, 2010 10:54 AM To: Xavier Beaudouin Cc: nanog Subject: Re: Appliance Vs Software based routers On Aug 4, 2010, at 9:53 AM, Xavier Beaudouin wrote: > > Le 4 ao?t 2010 ? 15:14, Mirko Maffioli a ?crit : > >> 2010/7/25 Laurens Vets : >>> >>> Cisco PIX: no, Cisco ASA: yes. It even runs under VMware... It's however >>> very hackish... :) >> >> Cisco ASA under VMware?? :| > > CiscoASA is based on x86, there is no reasons you cannot run this into VMWare or Xen... If that were the only qualification, PIX builds for the 515s would run under VMWare or XEN as well. Maybe they do, but I've never seen it. From Greg.Whynott at oicr.on.ca Wed Aug 4 10:06:22 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Wed, 4 Aug 2010 11:06:22 -0400 Subject: Appliance Vs Software based routers In-Reply-To: <2E43B2DA-0094-4530-83E2-8B351974471A@oav.net> References: <20100725082137.GV28859@skywalker.creative.net.au> <4C4C873B.4010209@daemon.be> <2E43B2DA-0094-4530-83E2-8B351974471A@oav.net> Message-ID: it works, i see folks creating networks of hosts under ESXi protected by an ASA instance.. not for production. I'm sure its not legal but Cisco doesn't seem to have a strong stand on it, I'd think as long as you are using it for educational use and not commercial, they may not care a whole bunch. What you can not do while emulating ASA is use encryption, no VPNs or otherwise. this is due to the fact the ASA units use hardware encryption, when the OS makes calls to the controller, it isn't there.. -g On Aug 4, 2010, at 9:53 AM, Xavier Beaudouin wrote: > > Le 4 ao?t 2010 ? 15:14, Mirko Maffioli a ?crit : > >> 2010/7/25 Laurens Vets : >>> >>> Cisco PIX: no, Cisco ASA: yes. It even runs under VMware... It's however >>> very hackish... :) >> >> Cisco ASA under VMware?? :| > > CiscoASA is based on x86, there is no reasons you cannot run this into VMWare or Xen... > > Xavier From streiner at cluebyfour.org Wed Aug 4 06:45:37 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 4 Aug 2010 07:45:37 -0400 (EDT) Subject: Recommended 1Gb SFP for ~115km? In-Reply-To: References: Message-ID: On Wed, 4 Aug 2010, Abello, Vinny wrote: > Any pointers on real world experience on this topic would greatly be > appreciated. What are people using successfully out there as far as third > party SFP's go to hit a distance of approximately 115km? This would be for a > Catalyst 6506. Cisco's solution was a much more costly EDFA solution, but I > see plenty of vendors that make SFP's for Gigabit Ethernet that range from > 115km to 150km and more. I know these are not supported by Cisco and TAC > won't troubleshoot if they are in the switch. I'm willing to work around > that should I need TAC assistance on the switch. What works well for a > single wavelength solution at this distance without having to switch to > DWDM? This circuit will have duplex fibers. I just lit a ~110km fiber span with gigabit gear in the last few weeks, and I ended up going with an external line driver because the native Cisco options wouldn't work, for a variety of reasons. I would have preferred to plug directly into the 6509s I have at each end, but it wasn't feasible. I ended up going with gear from Transition Networks. Pricing was pretty reasonable and their customer service has been great so far. There are some things with the management interface that I'm not too crazy about, but nothing that was a show-stopper. The driver has a 2-port SFP module that takes the LX12 long-haul signal in one side we drop it out the other side as 1000baseSX to drop into the 6509s. Works like a charm. I also looked at kit from MRV and Metrobility. The MRV stuff looked good too. Having said all that, you need to take into account the engineering characteristics of the fiber span, to make sure you choose gear that will live within the attenuation and dispersion limits that physics, fiber quality, splice quality, etc will impose upon you. On the 110km span I just lit, I used the G.652 spec as a guide and figured for 0.2 dB/km of attenuation at 1550 nm and 0.5 dB of loss for each connector, which got me an estimated loss budget of about 23 db, and the span tested out better than that. With an additional cross-connect at the one end I'm still at about 22.5 dB end to end. The LX12 optics I used from Transition have a link budget of 32 dB, so we have a bit of headroom. jms From cmaurand at xyonet.com Wed Aug 4 10:43:43 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Wed, 04 Aug 2010 11:43:43 -0400 Subject: Appliance Vs Software based routers In-Reply-To: <2E43B2DA-0094-4530-83E2-8B351974471A@oav.net> References: <20100725082137.GV28859@skywalker.creative.net.au> <4C4C873B.4010209@daemon.be> <2E43B2DA-0094-4530-83E2-8B351974471A@oav.net> Message-ID: <4C598AAF.7060908@xyonet.com> On 8/4/2010 9:53 AM, Xavier Beaudouin wrote: > Le 4 ao?t 2010 ? 15:14, Mirko Maffioli a ?crit : > > >> 2010/7/25 Laurens Vets: >> >>> Cisco PIX: no, Cisco ASA: yes. It even runs under VMware... It's however >>> very hackish... :) >>> >> Cisco ASA under VMware?? :| >> > CiscoASA is based on x86, there is no reasons you cannot run this into VMWare or Xen... > > Xavier > As long as VMWare's hardware (NIC , storage, etc.) line up with Cisco's. You still have to have drivers. --Curtis From Greg.Whynott at oicr.on.ca Wed Aug 4 10:44:19 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Wed, 4 Aug 2010 11:44:19 -0400 Subject: Appliance Vs Software based routers In-Reply-To: References: <20100725082137.GV28859@skywalker.creative.net.au><4C4C873B.4010209@daemon.be><2E43B2DA-0094-4530-83E2-8B351974471A@oav.net> <880D6793-00B5-428E-B484-471A406F2FA4@introspect.net> Message-ID: <13513615-BC64-4523-881B-01581470BBE4@oicr.on.ca> GNS is just a front end for dynamips/qemu. ASA will run under qemu without the use of extra wrappers/tools. it will run natively under vmware too. ASA is basically an application running above a linux kernel. I forget what the internal name is, lisa or similar? -g On Aug 4, 2010, at 10:56 AM, Mike Walter wrote: > I assume the ASA's don't run natively on VMware or Xen, I assume you have to use something like GNS3. I think that would be fine for testing, but in real world production running an ASA on GNS3 under an another OS seems like a bad idea. I hope Cisco will come out with Virtual Appliances for some of their products like they did for the Nexus 1000V. > > -Mike > > > -----Original Message----- > From: Daryl G. Jurbala [mailto:daryl at introspect.net] > Sent: Wednesday, August 04, 2010 10:54 AM > To: Xavier Beaudouin > Cc: nanog > Subject: Re: Appliance Vs Software based routers > > On Aug 4, 2010, at 9:53 AM, Xavier Beaudouin wrote: > >> >> Le 4 ao?t 2010 ? 15:14, Mirko Maffioli a ?crit : >> >>> 2010/7/25 Laurens Vets : >>>> >>>> Cisco PIX: no, Cisco ASA: yes. It even runs under VMware... It's however >>>> very hackish... :) >>> >>> Cisco ASA under VMware?? :| >> >> CiscoASA is based on x86, there is no reasons you cannot run this into VMWare or Xen... > > If that were the only qualification, PIX builds for the 515s would run under VMWare or XEN as well. Maybe they do, but I've never seen it. > From Vinny_Abello at dell.com Wed Aug 4 11:27:25 2010 From: Vinny_Abello at dell.com (Abello, Vinny) Date: Wed, 4 Aug 2010 11:27:25 -0500 Subject: Recommended 1Gb SFP for ~115km? In-Reply-To: References: Message-ID: Thanks for the input, Justin. I'm familiar with Transition Networks and have used their solutions in other scenarios (as well as MRV). I'm aware of the fiber characteristics being a major factor of the link budget and dispersion, etc. I am waiting on measurements from the company who is finishing the splicing of the fiber for us so I know what I have to work with. Thanks again! -Vinny -----Original Message----- From: Justin M. Streiner [mailto:streiner at cluebyfour.org] Sent: Wednesday, August 04, 2010 7:46 AM To: Abello, Vinny Cc: nanog at nanog.org Subject: Re: Recommended 1Gb SFP for ~115km? On Wed, 4 Aug 2010, Abello, Vinny wrote: > Any pointers on real world experience on this topic would greatly be > appreciated. What are people using successfully out there as far as third > party SFP's go to hit a distance of approximately 115km? This would be for a > Catalyst 6506. Cisco's solution was a much more costly EDFA solution, but I > see plenty of vendors that make SFP's for Gigabit Ethernet that range from > 115km to 150km and more. I know these are not supported by Cisco and TAC > won't troubleshoot if they are in the switch. I'm willing to work around > that should I need TAC assistance on the switch. What works well for a > single wavelength solution at this distance without having to switch to > DWDM? This circuit will have duplex fibers. I just lit a ~110km fiber span with gigabit gear in the last few weeks, and I ended up going with an external line driver because the native Cisco options wouldn't work, for a variety of reasons. I would have preferred to plug directly into the 6509s I have at each end, but it wasn't feasible. I ended up going with gear from Transition Networks. Pricing was pretty reasonable and their customer service has been great so far. There are some things with the management interface that I'm not too crazy about, but nothing that was a show-stopper. The driver has a 2-port SFP module that takes the LX12 long-haul signal in one side we drop it out the other side as 1000baseSX to drop into the 6509s. Works like a charm. I also looked at kit from MRV and Metrobility. The MRV stuff looked good too. Having said all that, you need to take into account the engineering characteristics of the fiber span, to make sure you choose gear that will live within the attenuation and dispersion limits that physics, fiber quality, splice quality, etc will impose upon you. On the 110km span I just lit, I used the G.652 spec as a guide and figured for 0.2 dB/km of attenuation at 1550 nm and 0.5 dB of loss for each connector, which got me an estimated loss budget of about 23 db, and the span tested out better than that. With an additional cross-connect at the one end I'm still at about 22.5 dB end to end. The LX12 optics I used from Transition have a link budget of 32 dB, so we have a bit of headroom. jms -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5187 bytes Desc: not available URL: From Thomas.Weible at flexoptix.net Wed Aug 4 11:58:51 2010 From: Thomas.Weible at flexoptix.net (Thomas Weible) Date: Wed, 4 Aug 2010 18:58:51 +0200 Subject: AW: Recommended 1Gb SFP for ~115km? In-Reply-To: References: Message-ID: Hi, the setup with two media-converters works but has a major drawback. If you want to see the overall line (digital diagnostic) you always have to take into consideration that there are actually 3 physical links involved in the overall link. Looking from your routers you only see the SX link (basically 2 meters via patchcord). The potential trouble making long distance link is hidden - or you have to look on the media-converters (if management is implemented). Cisco did a quite good job on implementing the DDM characteristics of the optics. So why not to take a 32dB or even 41dB power budget SFP and make it workable in the switch / router. Works like charm in some setups and you see straight the actual line. cheers Thomas PS: hello to NANOG from my site. I just got invited to the list because of this topic here. My field are the fibre optic networks based on pluggable technology. -----Urspr?ngliche Nachricht----- Von: Abello, Vinny [mailto:Vinny_Abello at dell.com] Gesendet: Mittwoch, 4. August 2010 18:27 An: Justin M. Streiner Cc: nanog at nanog.org Betreff: RE: Recommended 1Gb SFP for ~115km? Thanks for the input, Justin. I'm familiar with Transition Networks and have used their solutions in other scenarios (as well as MRV). I'm aware of the fiber characteristics being a major factor of the link budget and dispersion, etc. I am waiting on measurements from the company who is finishing the splicing of the fiber for us so I know what I have to work with. Thanks again! -Vinny -----Original Message----- From: Justin M. Streiner [mailto:streiner at cluebyfour.org] Sent: Wednesday, August 04, 2010 7:46 AM To: Abello, Vinny Cc: nanog at nanog.org Subject: Re: Recommended 1Gb SFP for ~115km? On Wed, 4 Aug 2010, Abello, Vinny wrote: > Any pointers on real world experience on this topic would greatly be > appreciated. What are people using successfully out there as far as > third party SFP's go to hit a distance of approximately 115km? This > would be for a > Catalyst 6506. Cisco's solution was a much more costly EDFA solution, > but I > see plenty of vendors that make SFP's for Gigabit Ethernet that range > from 115km to 150km and more. I know these are not supported by Cisco > and TAC won't troubleshoot if they are in the switch. I'm willing to > work around that should I need TAC assistance on the switch. What > works well for a single wavelength solution at this distance without > having to switch to DWDM? This circuit will have duplex fibers. I just lit a ~110km fiber span with gigabit gear in the last few weeks, and I ended up going with an external line driver because the native Cisco options wouldn't work, for a variety of reasons. I would have preferred to plug directly into the 6509s I have at each end, but it wasn't feasible. I ended up going with gear from Transition Networks. Pricing was pretty reasonable and their customer service has been great so far. There are some things with the management interface that I'm not too crazy about, but nothing that was a show-stopper. The driver has a 2-port SFP module that takes the LX12 long-haul signal in one side we drop it out the other side as 1000baseSX to drop into the 6509s. Works like a charm. I also looked at kit from MRV and Metrobility. The MRV stuff looked good too. Having said all that, you need to take into account the engineering characteristics of the fiber span, to make sure you choose gear that will live within the attenuation and dispersion limits that physics, fiber quality, splice quality, etc will impose upon you. On the 110km span I just lit, I used the G.652 spec as a guide and figured for 0.2 dB/km of attenuation at 1550 nm and 0.5 dB of loss for each connector, which got me an estimated loss budget of about 23 db, and the span tested out better than that. With an additional cross-connect at the one end I'm still at about 22.5 dB end to end. The LX12 optics I used from Transition have a link budget of 32 dB, so we have a bit of headroom. jms From streiner at cluebyfour.org Wed Aug 4 08:18:42 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 4 Aug 2010 09:18:42 -0400 (EDT) Subject: AW: Recommended 1Gb SFP for ~115km? In-Reply-To: References: Message-ID: On Wed, 4 Aug 2010, Thomas Weible wrote: > the setup with two media-converters works but has a major drawback. If > you want to see the overall line (digital diagnostic) you always have to > take into consideration that there are actually 3 physical links > involved in the overall link. Looking from your routers you only see > the SX link (basically 2 meters via patchcord). The potential trouble > making long distance link is hidden - or you have to look on the > media-converters (if management is implemented). I agree on the point that external media converters do have drawbacks (additional failure points, etc), but the drivers I used for the link I just lit show me details about link health, in terms of transmit/receive power, etc, that a "show interface" would not tell me. I considered Cisco's position re: using 3rd-party optics in their switches to be a show-stopper for a direct-plug solution. I would have preferred to go that route if it was viable. That's not to say that FlexOptix SFPs wouldn't work in the OP's case (or my case for that matter) - it will just take some time and experience to sell my management on the upside of buying optics from someone other than Cisco/Juniper/F5/etc :) jms From smb at cs.columbia.edu Wed Aug 4 14:42:02 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 4 Aug 2010 21:42:02 +0200 Subject: Question of privacy with reassigned resources In-Reply-To: References: <4C58A143.3080709@kenweb.org> <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Aug 4, 2010, at 1:35 17AM, William Herrin wrote: > On Tue, Aug 3, 2010 at 7:14 PM, Franck Martin wrote: >> If it is a business, then accurate address does not seem to me an >> issue, if it is a private address, I think a bit of fuzziness is helpful > > An apartment complex/condo/etc is a business which contains private addresses. > > Do you sell to the residents directly or do you sell to the apartment > complex which then resells to individual residents? > > If the former then you're basically off the hook for anybody who > doesn't get a /29 or larger. > > For the latter, you're providing significant amounts of a public > resource (IP addresses) to a business whose contact information you're > contractually and ethically obligated to reveal. If a particular > complex is worried about publishing their location, they can always > rent a P.O. box. If you're the only one doing the worrying, don't. I strongly disagree -- you're revealing the precise address of any tenant in those buildings. Don't do that... --Steve Bellovin, http://www.cs.columbia.edu/~smb From fergdawgster at gmail.com Wed Aug 4 14:46:01 2010 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 4 Aug 2010 12:46:01 -0700 Subject: Question of privacy with reassigned resources In-Reply-To: References: <4C58A143.3080709@kenweb.org> <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Aug 4, 2010 at 12:42 PM, Steven Bellovin wrote: > > On Aug 4, 2010, at 1:35 17AM, William Herrin wrote: > >> On Tue, Aug 3, 2010 at 7:14 PM, Franck Martin wrote: >>> If it is a business, then accurate address does not seem to me an >>> issue, if it is a private address, I think a bit of fuzziness is >>> helpful >> >> An apartment complex/condo/etc is a business which contains private >> addresses. >> >> Do you sell to the residents directly or do you sell to the apartment >> complex which then resells to individual residents? >> >> If the former then you're basically off the hook for anybody who >> doesn't get a /29 or larger. >> >> For the latter, you're providing significant amounts of a public >> resource (IP addresses) to a business whose contact information you're >> contractually and ethically obligated to reveal. If a particular >> complex is worried about publishing their location, they can always >> rent a P.O. box. If you're the only one doing the worrying, don't. > > I strongly disagree -- you're revealing the precise address of any tenant > in those buildings. Don't do that... > > Chiming in: I would tend to agree with smb on this particular issue -- that's a bit *too* precise. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMWcNoq1pz9mNUZTMRArbvAJ9ymAZzgf/hlOVPWQtTj3GcGCFKaACff7Hy bMw7Gg6uZObU4cPmoDU9TK4= =mrQI -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From brunner at nic-naa.net Wed Aug 4 15:08:50 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 04 Aug 2010 16:08:50 -0400 Subject: Question of privacy with reassigned resources In-Reply-To: References: <4C58A143.3080709@kenweb.org> <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4C59C8D2.3040007@nic-naa.net> +1 During the P3P too-and-fro on what constituted PII I lost the argument that masking off the last bits constituted acceptable non-disclosure of PII. Additionally, viewing the long/lat of a property where b/w and addresses are provisioned as the legal entity which owns the building seems odd. Eric On 8/4/10 3:46 PM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, Aug 4, 2010 at 12:42 PM, Steven Bellovin > wrote: > >> >> On Aug 4, 2010, at 1:35 17AM, William Herrin wrote: >> >>> On Tue, Aug 3, 2010 at 7:14 PM, Franck Martin wrote: >>>> If it is a business, then accurate address does not seem to me an >>>> issue, if it is a private address, I think a bit of fuzziness is >>>> helpful >>> >>> An apartment complex/condo/etc is a business which contains private >>> addresses. >>> >>> Do you sell to the residents directly or do you sell to the apartment >>> complex which then resells to individual residents? >>> >>> If the former then you're basically off the hook for anybody who >>> doesn't get a /29 or larger. >>> >>> For the latter, you're providing significant amounts of a public >>> resource (IP addresses) to a business whose contact information you're >>> contractually and ethically obligated to reveal. If a particular >>> complex is worried about publishing their location, they can always >>> rent a P.O. box. If you're the only one doing the worrying, don't. >> >> I strongly disagree -- you're revealing the precise address of any tenant >> in those buildings. Don't do that... >> >> > > Chiming in: I would tend to agree with smb on this particular issue -- > that's a bit *too* precise. > > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.5.3 (Build 5003) > > wj8DBQFMWcNoq1pz9mNUZTMRArbvAJ9ymAZzgf/hlOVPWQtTj3GcGCFKaACff7Hy > bMw7Gg6uZObU4cPmoDU9TK4= > =mrQI > -----END PGP SIGNATURE----- > > > > From bill at herrin.us Wed Aug 4 16:49:42 2010 From: bill at herrin.us (William Herrin) Date: Wed, 4 Aug 2010 17:49:42 -0400 Subject: Question of privacy with reassigned resources In-Reply-To: References: <4C58A143.3080709@kenweb.org> <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Wed, Aug 4, 2010 at 3:42 PM, Steven Bellovin wrote: > On Aug 4, 2010, at 1:35 17AM, William Herrin wrote: >> For the latter, you're providing significant amounts of a public >> resource (IP addresses) to a business whose contact information you're >> contractually and ethically obligated to reveal. If a particular >> complex is worried about publishing their location, they can always >> rent a P.O. box. If you're the only one doing the worrying, don't. > > I strongly disagree -- you're revealing the precise address of any > tenant in those buildings. ?Don't do that... Then discuss it with the apartment complex, Steven, and encourage them to get a PO box to use in place of their physical address. Or just buy a box from mail boxes etc. yourself and set up mail forwarding each time you set up a new apartment complex. The main point of the exercise is that the address consumer (the apartment management company, a for-profit business) be identifiable and directly reachable by phone, email and postal mail, not that they provide accurate coordinates for targeting the nukes. Plenty of reasonable ways to meet the spirit of the rules. The letter too. On Wed, Aug 4, 2010 at 4:08 PM, Eric Brunner-Williams wrote: > During the P3P too-and-fro on what constituted PII I lost the argument that > masking off the last bits constituted acceptable non-disclosure of PII. Whole other ball game, Eric. In the platform for privacy preferences (P3P) one participant in a data flow asserts that he will keep the other participant's behavior confidential. P3P examines what knowledge the asserter may glean and publish from that data flow without violating that confidentiality. You rightly lost the argument because the subnet, plus other information that doesn't by itself identify a user, can often be combined to identify a specific user and his behavior with a relatively high level of confidence. So can algorithmic one-way hashes of the address and most other variants on the meme that could reasonably facilitate reconstructing a particular user's data flow. No such agreement exists with respect to the public permitting for-profit businesses the exclusive use of a portion of the public's IP addresses. Quite the contrary, that public (as it expressed itself to ARIN repeatedly for a decade and a half and as recently as ARIN's public meeting earlier this year) insists that for-profit businesses granted the exclusive use of 8 or more of the public's IP addresses publicly reveal who they are and how to directly contact them. Public. Get it? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From adam.lafountain at googlemail.com Thu Aug 5 02:06:27 2010 From: adam.lafountain at googlemail.com (Adam LaFountain) Date: Thu, 5 Aug 2010 00:06:27 -0700 Subject: SingTel (AS7473) is only announcing ConnectPlus (AS9911) routes to Level3 (AS3356) in SJC? Message-ID: > Date: Fri, 30 Jul 2010 17:38:55 +0200 > From: Martin Barry > Subject: SingTel (AS7473) is only announcing ConnectPlus (AS9911) > ? ? ? ?routes to ? ? ? Level3 (AS3356) in SJC? > To:?nanog at nanog.org > > Anyone on the list who can offer an explanation about the following > scenario? We have taken this up with providers at either end but it > will take awhile to filter up to the ASes in question. > > We were seeing a London to Singapore connection go via San Jose > causing a 50%+ increase in latency. > > It appears that SingTel (AS7473) is only announcing ConnectPlus > (AS9911) routes to Level3 (AS3356) in SJC. > > However they have many adjacencies in many countries and other routes > of both AS7473 and it's other downstreams don't appear to be affected > (although I haven't tested them all). > > Traceroutes are appended at the end but to see for yourself use > 202.176.222.0 as a BGP or traceroute query in the Level3 looking glass > for both London and any other location, then compare with 167.172.93.0 > > Checking another large AS at random, they see AS7473 announcing AS9911 > routes in London. > > thanks > Marty At first I wanted to say this looks like a policy move on 7473's part but on further investigation I'm not sure if they're punishing themselves or doing some very specific traffic routing possible for balancing purposes. Noticing in Leve'3 bgp output they're a customer ?Show Level 3 (London, England) BGP routes for 202.176.222.212 BGP routing table entry for 202.176.222.0/24 Paths: (2 available, best #1) 7473 9911 AS-path translation: { APNIC-AS-2-BLOCK APNIC-AS-3-BLOCK } car2.SanJose1 (metric 44128) Origin IGP, metric 100, localpref 100, valid, internal, best Community: North_America Lclprf_100 Level3_Customer United_States San_Jose 7473:10000 7473:20000 7473:41101 Prepend_2_to_AS1668 Prepend_2_to_AS13680 Originator: car2.SanJose1 7473 9911 AS-path translation: { APNIC-AS-2-BLOCK APNIC-AS-3-BLOCK } car2.SanJose1 (metric 44128) Origin IGP, metric 100, localpref 100, valid, internal Community: North_America Lclprf_100 Level3_Customer United_States San_Jose 7473:10000 7473:20000 7473:41101 Prepend_2_to_AS1668 Prepend_2_to_AS13680 Originator: car2.SanJose1 I was inclined to believe it was related to cost, especially seeing the prepend for AOL (1668), but began to dimiss that as I saw two known _peers_ haul the traffic to the west coast as well: Router: gin-l78-mcore3 Site: GB, London - L78, VSNL LONTX01 STRATFORD Command: show ip bgp 202.176.222.212 BGP routing table entry for 202.176.222.0/24 Bestpath Modifiers: deterministic-med Paths: (3 available, best #2) 13 16 7473 9911 laa-icore1. (metric 3100) from laa-mcore3. (laa-mcore3.) Origin IGP, valid, internal Community: Peer route North America West Coast Los Angeles (LAA, LMR) Originator: laa-icore1. 7473 9911 pdi-icore1. (metric 3095) from pdi-mcore4. (pdi-mcore4.) Origin IGP, valid, internal, best Community: Peer route North America West Coast Palo Alto (PDI) Originator: pdi-icore1. and- 1 74 ms 75 ms 75 ms 10gigabitethernet2-3.core1.nyc4.he.net (72.52.92.77) 2 130 ms 149 ms 147 ms 10gigabitethernet5-3.core1.lax1.he.net (72.52.92.226) 3 131 ms 130 ms 139 ms laxeq-ds2-peer1.singtel.com (206.223.123.120) 4 131 ms 130 ms 139 ms ge-1-0-0-0.laxow-cr2.ix.singtel.com (203.208.149.118) In terms of figuring it out for sure I dont think L3 will tell you anything as they probably don't know. SingTel's your best bet but good luck with that unless you become a customer. I'm going to vote backbone traffic balancing by SingTel. From smb at cs.columbia.edu Thu Aug 5 03:25:00 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 5 Aug 2010 10:25:00 +0200 Subject: Question of privacy with reassigned resources In-Reply-To: References: <4C58A143.3080709@kenweb.org> <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <18E841A3-EA3E-4B9D-9F54-0551B82AAA91@cs.columbia.edu> On Aug 4, 2010, at 11:49 42PM, William Herrin wrote: > On Wed, Aug 4, 2010 at 3:42 PM, Steven Bellovin wrote: >> On Aug 4, 2010, at 1:35 17AM, William Herrin wrote: >>> For the latter, you're providing significant amounts of a public >>> resource (IP addresses) to a business whose contact information you're >>> contractually and ethically obligated to reveal. If a particular >>> complex is worried about publishing their location, they can always >>> rent a P.O. box. If you're the only one doing the worrying, don't. >> >> I strongly disagree -- you're revealing the precise address of any >> tenant in those buildings. Don't do that... > > Then discuss it with the apartment complex, Steven, and encourage them > to get a PO box to use in place of their physical address. Or just buy > a box from mail boxes etc. yourself and set up mail forwarding each > time you set up a new apartment complex. The main point of the > exercise is that the address consumer (the apartment management > company, a for-profit business) be identifiable and directly reachable > by phone, email and postal mail, not that they provide accurate > coordinates for targeting the nukes. Plenty of reasonable ways to meet > the spirit of the rules. The letter too. > Clearly, the apartment complex owners could do that if they so choose. I'm not sure who you suggest should "buy a box from mail boxes etc. yourself and set up mail forwarding each time you set up a new apartment complex" -- the ISP? How does that help? This is, as you say, a way to contact the apartment complex owners, right? The issues have to do with knowledge and expenditure. For the most part, consumers and apartment complex owners have no knowledge of IP geolocation or SWIP. It is consumer privacy at risk here, but consumers have no opportunity to opt out of this scheme even if they knew about it. "Discuss it with the apartment complex" is generally null advice; apart from the fact that consumers have exactly zero leverage in many markets, the apartment managers (a) don't know about it, either, and (b) can't be bothered to get a PO box and collect the (rare) mail from it. --Steve Bellovin, http://www.cs.columbia.edu/~smb From marty at supine.com Thu Aug 5 05:47:32 2010 From: marty at supine.com (Martin Barry) Date: Thu, 5 Aug 2010 12:47:32 +0200 Subject: SingTel (AS7473) is only announcing ConnectPlus (AS9911) routes to Level3 (AS3356) in SJC? In-Reply-To: References: Message-ID: <20100805104732.GA16511@merboo.mamista.net> $quoted_author = "Adam LaFountain" ; > > At first I wanted to say this looks like a policy move on 7473's part > but on further investigation I'm not sure if they're punishing > themselves or doing some very specific traffic routing possible for > balancing purposes. > I was inclined to believe it was related to cost, especially seeing > the prepend for AOL (1668), but began to dimiss that as I saw two > known _peers_ haul the traffic to the west coast as well: Hence our confusion, too. The only thing we could come up with was some reason (capacity, cost, etc.etc.) to prefer the Singapore to SJC path. But then why peer at LINX with other large ASes? > In terms of figuring it out for sure I dont think L3 will tell you > anything as they probably don't know. SingTel's your best bet but > good luck with that unless you become a customer. I'm going to vote > backbone traffic balancing by SingTel. We have a customer who is a customer. Ticket lodged. SingTel NOC are aware of it but no feedback or changes, yet. cheers Marty From bill at herrin.us Thu Aug 5 07:04:47 2010 From: bill at herrin.us (William Herrin) Date: Thu, 5 Aug 2010 08:04:47 -0400 Subject: Question of privacy with reassigned resources In-Reply-To: <18E841A3-EA3E-4B9D-9F54-0551B82AAA91@cs.columbia.edu> References: <4C58A143.3080709@kenweb.org> <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> <18E841A3-EA3E-4B9D-9F54-0551B82AAA91@cs.columbia.edu> Message-ID: On Thu, Aug 5, 2010 at 4:25 AM, Steven Bellovin wrote: > Clearly, the apartment complex owners could do that if >they so choose. ?I'm not sure who you suggest should >"buy a box from mail boxes etc. yourself and set up >mail forwarding each time you set up a new apartment >complex" -- the ISP? ?How does that help? ?This is, as >you say, a way to contact the apartment complex owners, right? Steven, Getting a post office box is a standard and widely accepted way to receive mail when for any reason you don't want the mail addressed to your physical location. Companies like Mail Boxes Etc. take the service one step further - they'll repackage the received mail and send it to your physical address so you don't have to stop by and check the box. Essentially, they provide a second postal address for the recipient unbound from the recipient's physical address. That's what you wanted, right? To avoid revealing the resource consumer's physical address? > The issues have to do with knowledge and expenditure. >For the most part, consumers and apartment complex >owners have no knowledge of IP geolocation or SWIP. >It is consumer privacy at risk here, but consumers have >no opportunity to opt out of this scheme even if they >knew about it. ?"Discuss it with the apartment complex" >is generally null advice; apart from the fact that consumers >have exactly zero leverage in many markets, the apartment >managers (a) don't know about it, either, and (b) can't be >bothered to get a PO box and collect the (rare) mail from it. If you feel that way, I suggest you take the issue up on the ARIN public policy mailing list. Solicit public consensus for a change in handling for SWIPs for "apartment complexes as ISP resellers." Absent such a change, redacting identity and contact info for the apartment management company remains simple fraud. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Valdis.Kletnieks at vt.edu Thu Aug 5 07:49:56 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 05 Aug 2010 08:49:56 -0400 Subject: Question of privacy with reassigned resources In-Reply-To: Your message of "Thu, 05 Aug 2010 08:04:47 EDT." References: <4C58A143.3080709@kenweb.org> <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> <18E841A3-EA3E-4B9D-9F54-0551B82AAA91@cs.columbia.edu> Message-ID: <61966.1281012596@localhost> On Thu, 05 Aug 2010 08:04:47 EDT, William Herrin said: > If you feel that way, I suggest you take the issue up on the ARIN > public policy mailing list. Solicit public consensus for a change in > handling for SWIPs for "apartment complexes as ISP resellers." Absent > such a change, redacting identity and contact info for the apartment > management company remains simple fraud. I'm not at all convinced that mere redaction qualifies as fraud. It certainly qualifies as *deceptive* - but does it rise to "fraudulent"? Is the fact that I use a Mail Boxes Etc-type service and don't accept mail at my home address because it's a very physically insecure mailbox fraudulent? Yes, it's somewhat deceptive, because it's not my actual home address. But unless you stretch "deception for personal gain" to the point where "gain" is "I don't want mail stolen from my mailbox", I don't think it's actual fraud. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ml at kenweb.org Thu Aug 5 07:54:34 2010 From: ml at kenweb.org (ML) Date: Thu, 05 Aug 2010 08:54:34 -0400 Subject: Question of privacy with reassigned resources In-Reply-To: References: <4C58A143.3080709@kenweb.org> <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> <18E841A3-EA3E-4B9D-9F54-0551B82AAA91@cs.columbia.edu> Message-ID: <4C5AB48A.5050806@kenweb.org> On 8/5/2010 8:04 AM, William Herrin wrote: > On Thu, Aug 5, 2010 at 4:25 AM, Steven Bellovin wrote: >> Clearly, the apartment complex owners could do that if >> they so choose. I'm not sure who you suggest should >> "buy a box from mail boxes etc. yourself and set up >> mail forwarding each time you set up a new apartment >> complex" -- the ISP? How does that help? This is, as >> you say, a way to contact the apartment complex owners, right? > > Steven, > > Getting a post office box is a standard and widely accepted way to > receive mail when for any reason you don't want the mail addressed to > your physical location. Companies like Mail Boxes Etc. take the > service one step further - they'll repackage the received mail and > send it to your physical address so you don't have to stop by and > check the box. Essentially, they provide a second postal address for > the recipient unbound from the recipient's physical address. > > That's what you wanted, right? To avoid revealing the resource > consumer's physical address? > > >> The issues have to do with knowledge and expenditure. >> For the most part, consumers and apartment complex >> owners have no knowledge of IP geolocation or SWIP. >> It is consumer privacy at risk here, but consumers have >> no opportunity to opt out of this scheme even if they >> knew about it. "Discuss it with the apartment complex" >> is generally null advice; apart from the fact that consumers >> have exactly zero leverage in many markets, the apartment >> managers (a) don't know about it, either, and (b) can't be >> bothered to get a PO box and collect the (rare) mail from it. > > If you feel that way, I suggest you take the issue up on the ARIN > public policy mailing list. Solicit public consensus for a change in > handling for SWIPs for "apartment complexes as ISP resellers." Absent > such a change, redacting identity and contact info for the apartment > management company remains simple fraud. > > Regards, > Bill Herrin There's usually a 50/50 split between the HOA (Home Owners Association) and the individual that are our customers. In the case of a HOA it's not that the HOA is reselling it's that we are contracted to service every member of the HOA and the HOA gives us one check for everyone. From bill at herrin.us Thu Aug 5 07:58:48 2010 From: bill at herrin.us (William Herrin) Date: Thu, 5 Aug 2010 08:58:48 -0400 Subject: Question of privacy with reassigned resources In-Reply-To: <61966.1281012596@localhost> References: <4C58A143.3080709@kenweb.org> <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> <18E841A3-EA3E-4B9D-9F54-0551B82AAA91@cs.columbia.edu> <61966.1281012596@localhost> Message-ID: On Thu, Aug 5, 2010 at 8:49 AM, wrote: > On Thu, 05 Aug 2010 08:04:47 EDT, William Herrin said: >> If you feel that way, I suggest you take the issue up on the ARIN >> public policy mailing list. Solicit public consensus for a change in >> handling for SWIPs for "apartment complexes as ISP resellers." Absent >> such a change, redacting identity and contact info for the apartment >> management company remains simple fraud. > > I'm not at all convinced that mere redaction qualifies as fraud. It certainly > qualifies as *deceptive* - but does it rise to "fraudulent"? ? Is the fact that > I use a Mail Boxes Etc-type service and don't accept mail at my home address > because it's a very physically insecure mailbox fraudulent? ?Yes, it's somewhat > deceptive, because it's not my actual home address. ?But unless you stretch > "deception for personal gain" to the point where "gain" is "I don't want mail > stolen from my mailbox", I don't think it's actual fraud. Valdis, It takes some creative reading to think I claimed using an alternate but still correct address (e.g. supplied by mailboxes etc.) constituted fraud. Alternate != redacted. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Thu Aug 5 08:16:49 2010 From: bill at herrin.us (William Herrin) Date: Thu, 5 Aug 2010 09:16:49 -0400 Subject: Question of privacy with reassigned resources In-Reply-To: <4C5AB48A.5050806@kenweb.org> References: <4C58A143.3080709@kenweb.org> <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> <18E841A3-EA3E-4B9D-9F54-0551B82AAA91@cs.columbia.edu> <4C5AB48A.5050806@kenweb.org> Message-ID: On Thu, Aug 5, 2010 at 8:54 AM, ML wrote: > There's usually a 50/50 split between the HOA (Home Owners Association) > and the individual that are our customers. ?In the case of a HOA it's > not that the HOA is reselling it's that we are contracted to service > every member of the HOA and the HOA gives us one check for everyone. Hi ML, For individuals, you get significant privacy: https://www.arin.net/policy/nrpm.html#six551 Home owners' associations seem like a gray area to me. You're talking about a non-profit organization whose sole purpose is to represent a group of residences collectively. I think I'd err on the side of listing the HOA's legal name along with the postal address at which the HOA prefers to be contacted but I also think it would be worth bringing up the question on the ARIN PPML. ARIN public policy is a dynamic thing -- it changes and clarifies when good reasons are presented and frankly I think you've hit on a good reason. Apartment management companies, where the entity is unambiguously for-profit, are really past the gray area. Their customers are residential, but they themselves are a commercial entity vending services. Their customers may be entitled to privacy but they aren't. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Valdis.Kletnieks at vt.edu Thu Aug 5 08:17:17 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 05 Aug 2010 09:17:17 -0400 Subject: Question of privacy with reassigned resources In-Reply-To: Your message of "Thu, 05 Aug 2010 08:58:48 EDT." References: <4C58A143.3080709@kenweb.org> <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> <18E841A3-EA3E-4B9D-9F54-0551B82AAA91@cs.columbia.edu> <61966.1281012596@localhost> Message-ID: <62914.1281014237@localhost> On Thu, 05 Aug 2010 08:58:48 EDT, William Herrin said: > It takes some creative reading to think I claimed using an alternate > but still correct address (e.g. supplied by mailboxes etc.) > constituted fraud. Alternate != redacted. Right. The point is that by the same "what is the personal gain" standard, it isn't obvious that redacted == fraud by definition. If I have an alternate physical mailbox and a redacted electronic address for the exact same reason (privacy and security), how is one fraudulent and the other not? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bill at herrin.us Thu Aug 5 08:23:12 2010 From: bill at herrin.us (William Herrin) Date: Thu, 5 Aug 2010 09:23:12 -0400 Subject: Question of privacy with reassigned resources In-Reply-To: <62914.1281014237@localhost> References: <4C58A143.3080709@kenweb.org> <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> <18E841A3-EA3E-4B9D-9F54-0551B82AAA91@cs.columbia.edu> <61966.1281012596@localhost> <62914.1281014237@localhost> Message-ID: On Thu, Aug 5, 2010 at 9:17 AM, wrote: > On Thu, 05 Aug 2010 08:58:48 EDT, William Herrin said: > >> It takes some creative reading to think I claimed using an alternate >> but still correct address (e.g. supplied by mailboxes etc.) >> constituted fraud. Alternate != redacted. > > Right. ?The point is that by the same "what is the personal gain" standard, it > isn't obvious that redacted == fraud by definition. What personal gain standard? I certainly didn't advocate one, and I don't find anything like that in ARIN's rules. As far as I can tell, anyone can pick an alternate postal address, a hotmail email address and a vonage phone number for their SWIP information if they so choose, quite regardless of whether any personal gain is involved. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Valdis.Kletnieks at vt.edu Thu Aug 5 08:37:28 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 05 Aug 2010 09:37:28 -0400 Subject: Question of privacy with reassigned resources In-Reply-To: Your message of "Thu, 05 Aug 2010 09:23:12 EDT." References: <4C58A143.3080709@kenweb.org> <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> <18E841A3-EA3E-4B9D-9F54-0551B82AAA91@cs.columbia.edu> <61966.1281012596@localhost> <62914.1281014237@localhost> Message-ID: <63659.1281015448@localhost> On Thu, 05 Aug 2010 09:23:12 EDT, William Herrin said: > What personal gain standard? I certainly didn't advocate one, and I > don't find anything like that in ARIN's rules. What you said: > Absent such a change, redacting identity and contact info for the apartment > management company remains simple fraud. "fraud" is usually defined as "deception with intent for personal gain". *That* standard. My point is that redation does not *in and of itself* rise to the level of fraud. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bill at herrin.us Thu Aug 5 09:30:45 2010 From: bill at herrin.us (William Herrin) Date: Thu, 5 Aug 2010 10:30:45 -0400 Subject: Question of privacy with reassigned resources In-Reply-To: <63659.1281015448@localhost> References: <4C58A143.3080709@kenweb.org> <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> <18E841A3-EA3E-4B9D-9F54-0551B82AAA91@cs.columbia.edu> <61966.1281012596@localhost> <62914.1281014237@localhost> <63659.1281015448@localhost> Message-ID: On Thu, Aug 5, 2010 at 9:37 AM, wrote: > On Thu, 05 Aug 2010 09:23:12 EDT, William Herrin said: >> Absent such a change, redacting identity and contact info for the apartment >> management company remains simple fraud. > > "fraud" is usually defined as "deception with intent for personal gain". ?*That* > standard. ?My point is that reda[c]tion does not *in and of itself* rise to the level of fraud. Valdis, Nitpicking someone's word choice can straddle the border between debate and trolling but if you insist then I suggest you first learn the meaning of the word. "Fraud" is about loss, not gain, and there's nothing "personal" about it. http://legal-dictionary.thefreedictionary.com/fraud "A false representation of a matter of fact?whether by words or by conduct, by false or misleading allegations, or by concealment of what should have been disclosed?that deceives and is intended to deceive another so that the individual will act upon it to her or his legal injury." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Valdis.Kletnieks at vt.edu Thu Aug 5 10:00:35 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 05 Aug 2010 11:00:35 -0400 Subject: Question of privacy with reassigned resources In-Reply-To: Your message of "Thu, 05 Aug 2010 10:30:45 EDT." References: <4C58A143.3080709@kenweb.org> <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> <18E841A3-EA3E-4B9D-9F54-0551B82AAA91@cs.columbia.edu> <61966.1281012596@localhost> <62914.1281014237@localhost> <63659.1281015448@localhost> Message-ID: <5097.1281020435@localhost> On Thu, 05 Aug 2010 10:30:45 EDT, William Herrin said: > "A false representation of a matter of fact whether by words or by > conduct, by false or misleading allegations, or by concealment of what > should have been disclosed that deceives and is intended to deceive > another so that the individual will act upon it to her or his legal > injury." And the mere fact that an address is redacted has the intent to decieve so that another will act on it to legal injury is where, exactly? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bill at herrin.us Thu Aug 5 11:05:18 2010 From: bill at herrin.us (William Herrin) Date: Thu, 5 Aug 2010 12:05:18 -0400 Subject: Question of privacy with reassigned resources In-Reply-To: <5097.1281020435@localhost> References: <4C58A143.3080709@kenweb.org> <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> <18E841A3-EA3E-4B9D-9F54-0551B82AAA91@cs.columbia.edu> <61966.1281012596@localhost> <62914.1281014237@localhost> <63659.1281015448@localhost> <5097.1281020435@localhost> Message-ID: On Thu, Aug 5, 2010 at 11:00 AM, wrote: > On Thu, 05 Aug 2010 10:30:45 EDT, William Herrin said: > >> "A false representation of a matter of fact whether by words or by >> conduct, by false or misleading allegations, or by concealment of what >> should have been disclosed that deceives and is intended to deceive >> another so that the individual will act upon it to her or his legal >> injury." > > And the mere fact that an address is redacted has the intent to decieve so that > another will act on it to legal injury is where, exactly? You've deprived everyone else of the use of that block of IP addresses in violation with your contract with ARIN which requires disclosure. Then, based on the claim that block is in use and properly registered, you've acquired additional blocks from ARIN, depriving everyone else of their use as well. You've deprived ARIN of the ability to audit your consumption of addresses without first notifying you. You've muddied the waters between clearly legitimate and clearly illegitimate use, damaging ARIN's tools and processes for detecting others' fraud. You've made it costlier for the antivirus folks to contact the infected. You've made it costlier for law enforcement to localize offenders and damaged their ability to keep investigations secret. Shall I go on? Regardless of what you may think about whether those injured folks should be entitled to the information, the fact is that they are entitled to it under ARIN policy developed based on public consensus. Which means you injure them by denying it. Which when denied deceptively (by quietly redacting information as opposed to repudiating the contract that requires its disclosure with the specific intent of depriving the entitled of that information) rises to the definition of fraud. BTW, I apologize for my prior comments about trolling. Reviewing the thread, I think I read some intent into your words that wasn't there. Nevertheless, I think we've reached the end of what can be usefully said on the subject of "is redacting business SWIP information fraud or something that's close to but not quite fraud." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From joshua.klubi at gmail.com Thu Aug 5 11:24:17 2010 From: joshua.klubi at gmail.com (Joshua William Klubi) Date: Thu, 5 Aug 2010 16:24:17 +0000 Subject: migration tools In-Reply-To: References: Message-ID: Hi, Is there any one with an idea of an open source packeteer or bandwidth management solution like Allot NetEnforcer Bandwidth Management. We currently have Microsoft TMG 2010 with GFI Web monitor 2009 installed on it, we are looking for a solution possible from open source.Which can replace it. Joshua (Ghana) From joshua.klubi at gmail.com Thu Aug 5 11:40:45 2010 From: joshua.klubi at gmail.com (Joshua William Klubi) Date: Thu, 5 Aug 2010 16:40:45 +0000 Subject: migration tools In-Reply-To: <20100805162741.GF14681@blend.twistedpair.ca> References: <20100805162741.GF14681@blend.twistedpair.ca> Message-ID: I actually want it as a proxy server and use it to shape, allocate and restrict access to certain websites of our staff. On Thu, Aug 5, 2010 at 4:27 PM, Michael 'Moose' Dinn < michael.dinn at airfire.ca> wrote: > > > Is there any one with an idea of an open source packeteer or bandwidth > > management > > solution like Allot NetEnforcer Bandwidth Management. > > We currently have Microsoft TMG 2010 with GFI Web monitor 2009 installed > on > > it, we are looking for a solution possible from open source.Which can > > replace it. > > Linux will do this nicely with traffic shaping. > > What feature set do you need? > > From joshua.klubi at gmail.com Thu Aug 5 11:43:54 2010 From: joshua.klubi at gmail.com (Joshua William Klubi) Date: Thu, 5 Aug 2010 16:43:54 +0000 Subject: migration tools In-Reply-To: <20100805164013.GG14681@blend.twistedpair.ca> References: <20100805162741.GF14681@blend.twistedpair.ca> <20100805164013.GG14681@blend.twistedpair.ca> Message-ID: Well thanx i wish i could get a full blown solution Joshua On Thu, Aug 5, 2010 at 4:40 PM, Michael 'Moose' Dinn < michael.dinn at airfire.ca> wrote: > > > I actually want it as a proxy server and use it to shape, allocate and > > restrict access to certain websites of our staff. > > Linux and Squid will do that happily, with a little traffic shaping as > well. > > From kompella at cs.purdue.edu Thu Aug 5 13:05:23 2010 From: kompella at cs.purdue.edu (Ramana Kompella) Date: Thu, 5 Aug 2010 14:05:23 -0400 Subject: CFP: COMSNETS 2011 Message-ID: <20100805180523.GA17513@tirupati> *** Apologies if you received multiple copies of this CFP *** COMSNETS 2011 January 4-8, 2011, Bangalore, India http://www.comsnets.org (In Co-operation with ACM SIGMOBILE) (Technically Co-Sponsored by IEEE COMSOC) The Third International Conference on COMmunication Systems and NETworkS (COMSNETS) will be held in Bangalore, India, from 4 January 2011 to 8 January 2011. COMSNETS is a premier international conference dedicated to addressing advances in Networking and Communications Systems, and Telecommunications services. The goal of the conference is to create a world-class gathering of researchers from academia and industry, practitioners, business leaders, intellectual property experts, and venture capitalists, providing a forum for discussing cutting edge research, and directions for new innovative business and technology. The conference will include a highly selective technical program consisting of parallel tracks of submitted papers, a small set of invited papers on important and timely topics from well-known leaders in the field, and poster sessions of work in progress. Focused workshops and panel discussions will be held on emerging topics to allow for a lively exchange of ideas. International business and government leaders will be invited to share their perspectives, thus complementing the technical program. Papers describing original research work and practical experiences/experimental results are solicited on topics including, but not limited to: Topics of Interest ------------------ * Internet Architecture and Protocols * Network-based Applications * Video Distribution (IPTV, Mobile Video, Video on Demand) * Network Operations and Management * Broadband and Cellular Networks (3G/4G, WiMAX/LTE) * Mesh, Sensor and PAN Networks * Communication Software (Cognitive Radios, DSA, SDR) * Wireless Operating Systems and Mobile Platforms * Peer-to-peer Networking * Cognitive Radio and White Space Networking * Optical Networks * Network Security & Cyber Security Technologies * Cloud and Utility computing * Storage Area Networks * Next Generation Web Architectures * Vehicular Networking * Energy-Efficient Networking * Network Science and Emergent Behavior in Socio-Technical Networks * Social Networking Analysis, Middleware and Applications * Networking Technologies for Smart Energy Grids * Disruption/Delay Tolerant Networking Conference Highlights --------------------- Conference Inaugural Speaker: Prof. Pravin Varaiya, U. C. Berkeley, USA Keynote Speakers: * Prof. Don Towsley, U. Mass Amherst, USA * Dr. Pravin Bhagwat, AirTight Networks, India * Dr. Jean Bolot, Sprint, USA Workshops * WISARD (4, 5 Jan) * NetHealth (4 Jan) * IAMCOM (5 Jan) * Mobile India 2011 (7 Jan) Technical Paper and Poster Sessions Ph.D Forum Panel Discussions Demos & Exhibits Important Deadlines ------------------- Paper submission: September 13, 2010 at 11:59 pm EDT (Sept 14, 9:29 am IST) Notification of Acceptance: November 8, 2010 Camera-Ready Submission: December 8, 2010 Detailed conference information and paper submission guidelines will soon be available on the conference web site. Please see http://www.comsnets.org for detailed information from time to time. The conference email address is: comsnets2011 at gmail.com General Co-Chairs ----------------- David B. Johnson, Rice University, USA Anurag Kumar, IISc Bangalore, India Technical Program Co-Chairs --------------------------- Jon Crowcroft, U. of Cambridge, UK D. Manjunath, IIT Bombay, India Archan Misra, Telcordia Tech., USA Steering Committee Co-Chairs ---------------------------- Uday Desai, IIT Hyderabad, India Giridhar Mandyam, Qualcomm, USA Sanjoy Paul, Infosys, India Rajeev Shorey, NIIT University, India G. Venkatesh, SASKEN, India Panel Co-Chairs --------------- Aditya Akella, U. of Wisconsin, USA Venkat Padmanabhan, MSR, India Ph.D Forum Chair ---------------- Bhaskaran Raman, IIT Bombay, India Publications Chair ------------------ Varsha Apte, IIT Bombay, India Demos and Exhibits Co-Chairs ---------------------------- Aaditeshwar Seth, IIT Delhi, India Ajay Bakre, Netapps, India Sponsorship Chair ----------------- Sudipta Maitra, Delhi, india Workshop Chairs --------------- Sharad Jaiswal, Alcatel-Lucent, India Ravindran Kaliappa, CUNY, USA Neelesh Mehta, IISc Bangalore, India Mobile India 2011 Co-Chairs --------------------------- Gulzar Azad, Google, India Gene Landy, Ruperto-Israel & Weiner, USA Rajaraghavan Setlur, SASKEN, India Sridhar Varadharajan, SASKEN, India Publicity Co-Chair ------------------ Augustin Chaintreau, TTL, France Kameswari Chebrolu, IIT Bombay, India Song Chong, KAIST, Korea Ramana Kompella, Purdue Univ, USA Nishanth Sastry, U. of Cambridge, UK Web Co-Chairs ------------- Santhana Krishnan, IIT Bombay, India Vinay Veerappa, SASKEN, India International Advisory Committee -------------------------------- K. K. Ramakrishnan, AT&T, USA Victor Bahl, Microsoft Research, USA Sunghyun Choi, Seoul National U., Korea Sajal Das, U. Texas at Arlington, USA B. N. Jain, IIT Delhi, India Anurag Kumar, IISc, Bangalore, India L. M. Patnaik, IISc, Bangalore, India Krithi Ramamritham, IIT Bombay, India Parmesh Ramanathan, U. Wisconsin, USA Krishan Sabnani, Alcatel-Lucent, USA Kang Shin, U. Michigan, USA Nitin Vaidya, U. Illinois, USA University Partners: -------------------- IIT Bombay, IIT Delhi, IISc Bangalore, IIT Hyderabad, NIIT University, IIIT Bangalore Patrons: -------- Mobile Monday Bangalore, Sasken, IBM Research, Alcatel Lucent From lowen at pari.edu Thu Aug 5 13:32:25 2010 From: lowen at pari.edu (Lamar Owen) Date: Thu, 5 Aug 2010 14:32:25 -0400 Subject: Appliance Vs Software based routers In-Reply-To: References: Message-ID: <201008051432.25741.lowen@pari.edu> On Wednesday, August 04, 2010 11:06:22 am Greg Whynott wrote: > it works, i see folks creating networks of hosts under ESXi protected by an ASA instance.. not for production. I'm sure its not legal but Cisco doesn't seem to have a strong stand on it, I'd think as long as you are using it for educational use and not commercial, they may not care a whole bunch. Much like Juniper's stance on Olive, perhaps? > What you can not do while emulating ASA is use encryption, no VPNs or otherwise. this is due to the fact the ASA units use hardware encryption, when the OS makes calls to the controller, it isn't there.. ASA, yes, but older PIX doesn't; google for 'frankenpix' to see more. Cisco used lots of embedded x86 where it made sense to do so (lots of places: LocalDirector, Content/Cache Engines, PIX, SwitchProbe, IPTV, MCS, and others). From odlyzko at umn.edu Thu Aug 5 13:38:38 2010 From: odlyzko at umn.edu (Andrew Odlyzko) Date: Thu, 5 Aug 2010 13:38:38 -0500 (CDT) Subject: off-topic: historical query concerning the Internet bubble Message-ID: Apologies for intruding with this question, but I can't think of any group that might have more concrete information relevant to my current research. Enclosed below is an announcement of a paper on technology bubbles. It is based largely on the Internet bubble of a decade ago, and concentrates on the "Internet traffic doubling every 100 days" tale. As the paper shows, this myth was perceived in very different ways by different people, and this by itself helps undermine the foundations of much of modern economics and economic policy making. To get a better understanding of the dynamics of that bubble, to assist in the preparation of a book about that incident, I am soliciting information from anyone who was active in telecom during that period. I would particularly like to know what you and your colleagues estimated Internet traffic growth to be, and what your reaction was to the O'Dell/Sidgmore/WorldCom/UUNet myth. If you were involved in the industry, and never heard of it, that would be extremely useful to know, too. Ideally, I would like concrete information, backed up by dates, and possibly even emails, and a permission to quote this information. However, I will settle for more informal comments, and promise confidentiality to anyone who requests it. Andrew Odlyzko odlyzko at umn.edu http://www.dtc.umn.edu/~odlyzko/doc/mania03.pdf Bubbles, gullibility, and other challenges for economics, psychology, sociology, and information sciences Andrew Odlyzko School of Mathematics and Digital Technology Center University of Minnesota odlyzko at umn.edu http://www.dtc.umn.edu/~odlyzko Preliminary version, August 5, 2010 ABSTRACT Gullibility is the principal cause of bubbles. Investors and the general public get snared by a "beautiful illusion" and throw caution to the wind. Attempts to identify and control bubbles are complicated by the fact that the authorities who might naturally be expected to take action have often (especially in recent years) been among the most gullible, and were cheerleaders for the exuberant behavior. Hence what is needed is an objective measure of gullibility. This paper argues that it should be possible to develop such a measure. Examples demonstrate, contrary to the efficient market dogma, that in some manias, even top-level business and technology leaders do fall prey to collective hallucinations and become irrational in objective terms. During the Internet bubble, for example, large classes of them first became unable to comprehend compound interest, and then lost even the ability to do simple arithmetic, to the point of not being able to distinguish 2 from 10. This phenomenon, together with advances in analysis of social networks and related areas, points to possible ways to develop objective and quantitative tools for measuring gullibility and other aspects of human behavior implicated in bubbles. It cannot be expected to infallibly detect all destructive bubbles, and may trigger false alarms, but it ought to alert observers to periods where collective investment behavior is becoming irrational. The proposed gullibility index might help in developing realistic economic models. It should also assist in illuminating and guiding decision making. ----------------------------------------------------------------------------- If you would like to be on the mailing list for notifications of future papers on technology bubbles, please send me a note at odlyzko at umn.edu The previous three papers in this series are available at: 1. Collective hallucinations and inefficient markets: The British Railway Mania of the 1840s http://www.dtc.umn.edu/~odlyzko/doc/hallucinations.pdf 2. This time is different: An example of a giant, wildly speculative, and successful investment mania, B.E. Journal of Economic Analysis & Policy, vol. 10, issue 1, 2010, article 60 (registration required) http://www.bepress.com/bejeap/vol10/iss1/art60 preprint available at: http://www.dtc.umn.edu/~odlyzko/doc/mania01.pdf 3. The collapse of the Railway Mania, the development of capital markets, and Robert Lucas Nash, a forgotten pioneer of accounting and financial analysis http://www.dtc.umn.edu/~odlyzko/doc/mania02.pdf ----------------------------------------------------------------------------- Source materials for the Railway Mania and the Internet bubble are available at the web pages http://www.dtc.umn.edu/~odlyzko/rrsources/ and http://www.dtc.umn.edu/~odlyzko/isources/ From joshua.klubi at gmail.com Thu Aug 5 13:45:25 2010 From: joshua.klubi at gmail.com (Joshua William Klubi) Date: Thu, 5 Aug 2010 18:45:25 +0000 Subject: Proxy Server Message-ID: Hi, Is there any one with an idea of an open source packeteer or bandwidth management solution like Allot NetEnforcer Bandwidth Management Appliance. Which can do proxy services and also allocate bandwidth to certain websites and staff, prevent them from viewing certain websites We currently have Microsoft TMG 2010 with GFI Web monitor 2009 installed on it, we are looking for a solution possible from open source.Which can replace it. I actually want it as a proxy server and use it to shape, allocate and restrict access to certain websites of our staff. Joshua (Ghana) From Valdis.Kletnieks at vt.edu Thu Aug 5 13:46:16 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 05 Aug 2010 14:46:16 -0400 Subject: Question of privacy with reassigned resources In-Reply-To: Your message of "Thu, 05 Aug 2010 12:05:18 EDT." References: <4C58A143.3080709@kenweb.org> <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> <18E841A3-EA3E-4B9D-9F54-0551B82AAA91@cs.columbia.edu> <61966.1281012596@localhost> <62914.1281014237@localhost> <63659.1281015448@localhost> <5097.1281020435@localhost> Message-ID: <13299.1281033976@localhost> On Thu, 05 Aug 2010 12:05:18 EDT, William Herrin said: > You've deprived everyone else of the use of that block of IP addresses > in violation with your contract with ARIN which requires disclosure. > Then, based on the claim that block is in use and properly registered, > you've acquired additional blocks from ARIN, depriving everyone else > of their use as well. OK. Now I see where you're coming from - looking at the one *providing* the address block, not the end-user recipient. I may not agree, but at least I understand now, thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From morrowc.lists at gmail.com Thu Aug 5 13:58:20 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 5 Aug 2010 14:58:20 -0400 Subject: Proxy Server In-Reply-To: References: Message-ID: squid? On Thu, Aug 5, 2010 at 2:45 PM, Joshua William Klubi wrote: > Hi, > > Is there any one with an idea of an open source packeteer or bandwidth > management solution like Allot NetEnforcer Bandwidth Management Appliance. > Which can do proxy services and also allocate bandwidth to certain websites > and staff, prevent them from viewing certain websites > We currently have Microsoft TMG 2010 with GFI Web monitor 2009 installed on > it, we are looking for a solution possible from open source.Which can > replace it. > > I actually ?want it as a proxy server and use it to shape, allocate and > restrict access to certain websites of our staff. > Joshua > (Ghana) > From Greg.Whynott at oicr.on.ca Thu Aug 5 14:03:27 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Thu, 5 Aug 2010 15:03:27 -0400 Subject: Proxy Server In-Reply-To: References: Message-ID: I am fairly sure Squid has the concept of bandwidth pools which you can apply via ACLs within the squid conf. That may meet your proxy requirements but would not help with traffic not being proxied. Squid will also allow you to define access to the inet based on ACLs which can use various things to determine which policy will be applied to the connection. eg, client src IP, client username, time of day, regx? you may find it here: http://www.squid-cache.org/ -g On Aug 5, 2010, at 2:45 PM, Joshua William Klubi wrote: > Hi, > > Is there any one with an idea of an open source packeteer or bandwidth > management solution like Allot NetEnforcer Bandwidth Management Appliance. > Which can do proxy services and also allocate bandwidth to certain websites > and staff, prevent them from viewing certain websites > We currently have Microsoft TMG 2010 with GFI Web monitor 2009 installed on > it, we are looking for a solution possible from open source.Which can > replace it. > > I actually want it as a proxy server and use it to shape, allocate and > restrict access to certain websites of our staff. > Joshua > (Ghana) From deepak at ai.net Thu Aug 5 14:19:44 2010 From: deepak at ai.net (Deepak Jain) Date: Thu, 5 Aug 2010 15:19:44 -0400 Subject: Proxy Server In-Reply-To: References: Message-ID: ---- > > I am fairly sure Squid has the concept of bandwidth pools which you can > apply via ACLs within the squid conf. > That may meet your proxy requirements but would not help with traffic > not being proxied. > > Squid will also allow you to define access to the inet based on ACLs > which can use various things to determine which policy will be applied > to the connection. eg, client src IP, client username, time of day, > regx... > > you may find it here: > > http://www.squid-cache.org/ > --- Squid plus bandwidth management (ala dummynet or similar) could go a long way to addressing all of those functions. Deepak Jain AiNET From brandon.galbraith at gmail.com Thu Aug 5 14:21:01 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 5 Aug 2010 14:21:01 -0500 Subject: Colocation in Belize Message-ID: I'm looking for colocation in Belize for some equipment, but am having a bit of trouble finding anyone with significant carrier-neutral space there. Has anyone had any success in finding such space there? Off-list replies preferred. -- Brandon Galbraith Voice: 630.492.0464 From rmacharia at gmail.com Thu Aug 5 14:51:54 2010 From: rmacharia at gmail.com (Raymond Macharia) Date: Thu, 5 Aug 2010 22:51:54 +0300 Subject: Proxy Server In-Reply-To: References: Message-ID: www.etinc.com. Built out of open source but you pay for a license fee but not as steep as for an Allot unit. you can get the hardware or download the software and pay for a key. Has the same functionalities that you are looking for as an Allot box. I happen to have used both and I liked the ETINC product. Stable and relaible. Raymond Macharia On Thu, Aug 5, 2010 at 10:19 PM, Deepak Jain wrote: > ---- > > > > I am fairly sure Squid has the concept of bandwidth pools which you can > > apply via ACLs within the squid conf. > > That may meet your proxy requirements but would not help with traffic > > not being proxied. > > > > Squid will also allow you to define access to the inet based on ACLs > > which can use various things to determine which policy will be applied > > to the connection. eg, client src IP, client username, time of day, > > regx... > > > > you may find it here: > > > > http://www.squid-cache.org/ > > > --- > > Squid plus bandwidth management (ala dummynet or similar) could go a long > way to addressing all of those functions. > > Deepak Jain > AiNET > > From patrick at ianai.net Thu Aug 5 16:00:06 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 5 Aug 2010 17:00:06 -0400 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: References: Message-ID: <5AC3E79A-392B-4D1B-BFC7-2700942FDC3C@ianai.net> Ask on the Internet History list. Although, as someone active in 2000, I can tell you that traffic did not grow 12.55 times per year (doubling every 100 days), or anything even close to that. -- TTFN, patrick On Aug 5, 2010, at 2:38 PM, Andrew Odlyzko wrote: > Apologies for intruding with this question, but I can't think > of any group that might have more concrete information relevant > to my current research. > > > > Enclosed below is an announcement of a paper on technology bubbles. > It is based largely on the Internet bubble of a decade ago, and > concentrates on the "Internet traffic doubling every 100 days" tale. > As the paper shows, this myth was perceived in very different ways > by different people, and this by itself helps undermine the foundations > of much of modern economics and economic policy making. > > To get a better understanding of the dynamics of that bubble, to assist > in the preparation of a book about that incident, I am soliciting information from anyone who was active in telecom during that period. I would particularly like to know what you and your colleagues estimated Internet traffic growth to be, and what your reaction was to the O'Dell/Sidgmore/WorldCom/UUNet myth. If you were involved in the industry, > and never heard of it, that would be extremely useful to know, too. > > Ideally, I would like concrete information, backed up by dates, and possibly > even emails, and a permission to quote this information. However, I will > settle for more informal comments, and promise confidentiality to anyone > who requests it. > > Andrew Odlyzko > odlyzko at umn.edu > > > > > http://www.dtc.umn.edu/~odlyzko/doc/mania03.pdf > > > Bubbles, gullibility, and other challenges for economics, > psychology, sociology, and information sciences > > Andrew Odlyzko > > School of Mathematics > and Digital Technology Center > University of Minnesota > > odlyzko at umn.edu > http://www.dtc.umn.edu/~odlyzko > > Preliminary version, August 5, 2010 > > > ABSTRACT > > Gullibility is the principal cause of bubbles. Investors and the general public get snared by a "beautiful illusion" and throw caution to the wind. Attempts to identify and control bubbles are complicated by the fact that the authorities who might naturally be expected to take action have often (especially in recent years) been among the most gullible, and were cheerleaders for the exuberant behavior. Hence what is needed is an objective measure of gullibility. > > This paper argues that it should be possible to develop such a measure. Examples demonstrate, contrary to the efficient market dogma, that in some manias, even top-level business and technology leaders do fall prey to collective hallucinations and become irrational in objective terms. During the Internet bubble, for example, large classes of them first became unable to comprehend compound interest, and then lost even the ability to do simple arithmetic, to the point of not being able to distinguish 2 from 10. This phenomenon, together with advances in analysis of social networks and related areas, points to possible ways to develop objective and quantitative tools for measuring gullibility and other aspects of human behavior implicated in bubbles. It cannot be expected to infallibly detect all destructive bubbles, and may trigger false alarms, but it ought to alert observers to periods where collective investment behavior is becoming irrational. > > The proposed gullibility index might help in developing realistic economic models. It should also assist in illuminating and guiding decision making. > > > > ----------------------------------------------------------------------------- > > If you would like to be on the mailing list for notifications of future > papers on technology bubbles, please send me a note at odlyzko at umn.edu > > > The previous three papers in this series are available at: > > 1. Collective hallucinations and inefficient markets: The British Railway Mania of the 1840s > > http://www.dtc.umn.edu/~odlyzko/doc/hallucinations.pdf > > > 2. This time is different: An example of a giant, wildly speculative, and successful investment mania, B.E. Journal of Economic Analysis & Policy, vol. 10, issue 1, 2010, article 60 (registration required) > > http://www.bepress.com/bejeap/vol10/iss1/art60 > > preprint available at: > > http://www.dtc.umn.edu/~odlyzko/doc/mania01.pdf > > > 3. The collapse of the Railway Mania, the development of capital markets, and Robert Lucas Nash, a forgotten pioneer of accounting and financial analysis > > http://www.dtc.umn.edu/~odlyzko/doc/mania02.pdf > > ----------------------------------------------------------------------------- > > Source materials for the Railway Mania and the Internet bubble are available > at the web pages > > http://www.dtc.umn.edu/~odlyzko/rrsources/ > > and > > http://www.dtc.umn.edu/~odlyzko/isources/ > > > From joe at nethead.com Thu Aug 5 16:55:56 2010 From: joe at nethead.com (Joe Hamelin) Date: Thu, 5 Aug 2010 14:55:56 -0700 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: References: Message-ID: On Thu, Aug 5, 2010 at 11:38 AM, Andrew Odlyzko wrote: > To get a better understanding of the dynamics of that bubble, to assist > in the preparation of a book about that incident, I am soliciting > information from anyone who was active in telecom during that period. We saw that or better growth at Flying Crocodile (aka sextracker.com) during that period. I don't have access to the stats anymore (if they even exist) but in two years we went from 1Mb/s to over 1Gb/s in outbound traffic. This was 1998 to 2000ish. It was "fun" to try to keep enough pipe and cards in the GSR12000s even being in the Westin. Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From dorian at blackrose.org Thu Aug 5 17:27:06 2010 From: dorian at blackrose.org (Dorian Kim) Date: Thu, 5 Aug 2010 18:27:06 -0400 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: References: Message-ID: <20100805222706.GJ63440@blackrose.org> On Thu, Aug 05, 2010 at 01:38:38PM -0500, Andrew Odlyzko wrote: > Apologies for intruding with this question, but I can't think > of any group that might have more concrete information relevant > to my current research. > > > > Enclosed below is an announcement of a paper on technology bubbles. > It is based largely on the Internet bubble of a decade ago, and > concentrates on the "Internet traffic doubling every 100 days" tale. > As the paper shows, this myth was perceived in very different ways > by different people, and this by itself helps undermine the foundations > of much of modern economics and economic policy making. > > To get a better understanding of the dynamics of that bubble, to assist > in the preparation of a book about that incident, I am soliciting > information from anyone who was active in telecom during that period. I > would particularly like to know what you and your colleagues estimated > Internet traffic growth to be, and what your reaction was to the > O'Dell/Sidgmore/WorldCom/UUNet myth. If you were involved in the industry, > and never heard of it, that would be extremely useful to know, too. > > Ideally, I would like concrete information, backed up by dates, and > possibly > even emails, and a permission to quote this information. However, I will > settle for more informal comments, and promise confidentiality to anyone > who requests it. The doubling rate from various parts of the tier 1 world I've seen since mid 90s until now has been pretty consistent. It's been ranging around 9-14 months or so with the shorter end of the doubling number coming mostly during the 1996-2000 years, modulo specific fortunes of the tier 1 in question. Was Mike O'Dell's famous doubling every 100 days just a myth? Like any good tale, there most likely was an element of truth behind it. It wouldn't surprise me if there was a 6-12 month span during 96-98 when the Internet traffic as a whole did grow by ~10x especially as backbones made the painful and much delayed leap past DS3 and the back pressure was finally relieved. The problem is, the relevant data are spread out all over and probably not obtainable. I seem to remember thinking that those numbers seemed a bit high, but mostly shrugging at it at the time I heard Mike and other UUNet folks say it since it wasn't off by more than an order of magnitude and back then we tended to ignore things that were that close, and UUNet was well known for their "forward looking statements" anyway. Btw, just so we can at least put some real world scale to these traffic doubling rates tales, a non-descript tier 1 network that's not particularly any more or less successful than others have had an average doubling rate of roughly 13.1 months from 2000 to 2010 for their transpacific traffic. -dorian From jay at west.net Thu Aug 5 18:10:08 2010 From: jay at west.net (Jay Hennigan) Date: Thu, 05 Aug 2010 16:10:08 -0700 Subject: Strange Cox issues in California Message-ID: <4C5B44D0.5070306@west.net> I haven't been able to reach anyone with clue at Cox to resolve this, but over the last two days we have seen breakage of applications requiring UDP reported by Cox cable modem customers. ICMP ping also fails but web surfing works. Was a huge problem yesterday, came back for some customers but some are still affected. Most of our affected customers are in Santa Barbara. SIP and VPN customers are the most obviously affected. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From packetgrrl at gmail.com Thu Aug 5 20:32:28 2010 From: packetgrrl at gmail.com (cja@daydream.com) Date: Thu, 5 Aug 2010 19:32:28 -0600 Subject: paypal contact Message-ID: Can someone from Paypal contact me offline? I am in need of some assistance Thanks! From hrlinneweh at sbcglobal.net Fri Aug 6 03:46:01 2010 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Fri, 6 Aug 2010 01:46:01 -0700 (PDT) Subject: VPN device mapping software or auto-discovery scripts Message-ID: <188161.62556.qm@web180310.mail.gq1.yahoo.com> I am looking for a solution on this, at this time -henry From adrian.minta at gmail.com Fri Aug 6 05:01:16 2010 From: adrian.minta at gmail.com (Adrian M) Date: Fri, 6 Aug 2010 13:01:16 +0300 Subject: Proxy Server In-Reply-To: References: Message-ID: pfSense has everything: proxy (squid), firewall, bw-management, captive portal and a very nice web interface for management: www.pfsense.org From joshua.klubi at gmail.com Fri Aug 6 05:42:28 2010 From: joshua.klubi at gmail.com (Joshua William Klubi) Date: Fri, 6 Aug 2010 10:42:28 +0000 Subject: Proxy Server In-Reply-To: References: Message-ID: Thnax very much , it is wht i need On Fri, Aug 6, 2010 at 10:01 AM, Adrian M wrote: > pfSense has everything: proxy (squid), firewall, bw-management, > captive portal and a very nice web interface for management: > www.pfsense.org > From jmamodio at gmail.com Fri Aug 6 07:23:44 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 6 Aug 2010 07:23:44 -0500 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: <20100805222706.GJ63440@blackrose.org> References: <20100805222706.GJ63440@blackrose.org> Message-ID: As you may recall (because you have been part of it) the 1995-2000 was a period of major consolidation in the ISP industry, metrics were hard to obtain and the ones available were hard to believe. Due to the consolidation of many small networks from various ISPs (I remember that in my former life we engulfed several of the surviving post NSFNet regionals), almost all the big pipes of those ISPs were up to the choking point, then when the time came to move all those pipes to a better backbone and exchange points, and in the process make them bigger, traffic started to increase dramatically, accompanied as well by a decrease in packet loss and delays. The consolidation also helped to move mom & pop configuration of stacked us robitics modems to much modern, efficient and reliable aggregation technologies and architectures on the access side, add ISDN, DSL, cable, etc. Not sure how to include it as a variable, but at least in the US the Telecom Act of 1996 also changed the playing field, CLECs and other new telecom companies were born. On top of that, in that period there was also a big increase in international capacity, some connections (particularly south and central america) were switching from satellite to fiber, many developing countries (some of them were just coming out of highly monopolized and regulated telecom services) were able to have access to better international connections, plus all the traffic growth driven from the application side, plus the contribution of dramatic growth in shared and dedicated hosting services. I don't recall or have at hand at this time the exact figure, but I'd agree with you that at some time it looked like a ~10x thing whit some spurts of much higher growth. Cheers Jorge From jmamodio at gmail.com Fri Aug 6 07:45:05 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 6 Aug 2010 07:45:05 -0500 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: References: Message-ID: BTW, in the context of Andrew's paper (very interesting indeed) I believe that one of the issues is that many executives took that "spurt growth" I was referring to in my previous message, as organic growth and used it to make unrealistic projections which in turn led to unrealistic valuations, and so on. In some cases we "wasted" tons of money over building capacity, particularly during the datacenter frenzy, later to find that we had a lot of empty hi-tech real state. I like how you characterized the investment waste in your paper. Regards Jorge From odlyzko at umn.edu Fri Aug 6 08:13:35 2010 From: odlyzko at umn.edu (Andrew Odlyzko) Date: Fri, 6 Aug 2010 08:13:35 -0500 (CDT) Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: References: Message-ID: Jorge, Many thanks for the comments. To the entire NANOG list: I have received many comments, a few through the list, most off-list. I greatly appreciate all, and will be responding to them all off-list, since this is not an operational matter. If there is interest, I can summarize for the list in a few days. In the meantime, please keep sending in more data! Best regards, Andrew On Fri, 6 Aug 2010, Jorge Amodio wrote: > BTW, in the context of Andrew's paper (very interesting indeed) I > believe that one of the issues is that many executives took that > "spurt growth" I was referring to in my previous message, as organic > growth and used it to make unrealistic projections which in turn led > to unrealistic valuations, and so on. > > In some cases we "wasted" tons of money over building capacity, > particularly during the datacenter frenzy, later to find that we had a > lot of empty hi-tech real state. > > I like how you characterized the investment waste in your paper. > > Regards > Jorge > From lists at internetpolicyagency.com Fri Aug 6 11:13:28 2010 From: lists at internetpolicyagency.com (Roland Perry) Date: Fri, 6 Aug 2010 17:13:28 +0100 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: <5AC3E79A-392B-4D1B-BFC7-2700942FDC3C@ianai.net> References: <5AC3E79A-392B-4D1B-BFC7-2700942FDC3C@ianai.net> Message-ID: <$4h4hQNoSDXMFA3R@perry.co.uk> In article <5AC3E79A-392B-4D1B-BFC7-2700942FDC3C at ianai.net>, Patrick W. Gilmore writes >Although, as someone active in 2000, I can tell you that traffic did >not grow 12.55 times per year (doubling every 100 days), or anything >even close to that. Keeping it in the family a little, Mike was quoted as saying this - see p2: https://www.linx.net/files/hotlinx/hotlinx-3.pdf Although there were two factors here as far as LINX itself was concerned - growth in members as well as growth in traffic from each individual member. -- Roland Perry From patrick at ianai.net Fri Aug 6 11:50:48 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 6 Aug 2010 12:50:48 -0400 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: <$4h4hQNoSDXMFA3R@perry.co.uk> References: <5AC3E79A-392B-4D1B-BFC7-2700942FDC3C@ianai.net> <$4h4hQNoSDXMFA3R@perry.co.uk> Message-ID: On Aug 6, 2010, at 12:13 PM, Roland Perry wrote: > In article <5AC3E79A-392B-4D1B-BFC7-2700942FDC3C at ianai.net>, Patrick W. Gilmore writes >> Although, as someone active in 2000, I can tell you that traffic did >> not grow 12.55 times per year (doubling every 100 days), or anything >> even close to that. > > Keeping it in the family a little, Mike was quoted as saying this - see p2: https://www.linx.net/files/hotlinx/hotlinx-3.pdf > > Although there were two factors here as far as LINX itself was concerned - growth in members as well as growth in traffic from each individual member. Even ignore the fact this is overestimating growth, it still is not 12.55 times in one year. Or even double in 100 days. -- TTFN, patrick From rblayzor.bulk at inoc.net Fri Aug 6 12:52:17 2010 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Fri, 6 Aug 2010 13:52:17 -0400 Subject: Recommended 1Gb SFP for ~115km? In-Reply-To: References: Message-ID: <5746599E-E439-4D98-AC4B-B459F51122CF@inoc.net> On Aug 4, 2010, at 12:27 PM, Abello, Vinny wrote: > Thanks for the input, Justin. I'm familiar with Transition Networks and have > used their solutions in other scenarios (as well as MRV). I'm aware of the > fiber characteristics being a major factor of the link budget and > dispersion, etc. I am waiting on measurements from the company who is > finishing the splicing of the fiber for us so I know what I have to work > with. If you're fine with 3rd party optics, FluxLight has BIDI SFP's that will reach up to 120km. http://www.fluxlightinc.com/prod.php?id=309 They show up as Cisco SFP's right in the switch/router. I've had good luck with the 40 & 80km ones in the past. -- Robert Blayzor INOC, LLC rblayzor at inoc.net http://www.inoc.net/~rblayzor/ From cscora at apnic.net Fri Aug 6 13:11:58 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 7 Aug 2010 04:11:58 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201008061811.o76IBw6d007427@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 07 Aug, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 327570 Prefixes after maximum aggregation: 150699 Deaggregation factor: 2.17 Unique aggregates announced to Internet: 160252 Total ASes present in the Internet Routing Table: 34482 Prefixes per ASN: 9.50 Origin-only ASes present in the Internet Routing Table: 29935 Origin ASes announcing only one prefix: 14513 Transit ASes present in the Internet Routing Table: 4547 Transit-only ASes present in the Internet Routing Table: 99 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (41664) 21 Prefixes from unregistered ASNs in the Routing Table: 486 Unregistered ASNs in the Routing Table: 210 Number of 32-bit ASNs allocated by the RIRs: 155 Prefixes from 32-bit ASNs in the Routing Table: 893 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 61843 Number of addresses announced to Internet: 2251423360 Equivalent to 134 /8s, 49 /16s and 254 /24s Percentage of available address space announced: 60.7 Percentage of allocated address space announced: 65.5 Percentage of available address space allocated: 92.8 Percentage of address space in use by end-sites: 69.2 Total number of prefixes smaller than registry allocations: 132801 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 79486 Total APNIC prefixes after maximum aggregation: 27320 APNIC Deaggregation factor: 2.91 Prefixes being announced from the APNIC address blocks: 76404 Unique aggregates announced from the APNIC address blocks: 33692 APNIC Region origin ASes present in the Internet Routing Table: 4152 APNIC Prefixes per ASN: 18.40 APNIC Region origin ASes announcing only one prefix: 1160 APNIC Region transit ASes present in the Internet Routing Table: 635 Average APNIC Region AS path length visible: 3.7 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 538001952 Equivalent to 32 /8s, 17 /16s and 66 /24s Percentage of available APNIC address space announced: 80.2 APNIC AS Blocks 4608-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, 14/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 134936 Total ARIN prefixes after maximum aggregation: 69682 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 107823 Unique aggregates announced from the ARIN address blocks: 42279 ARIN Region origin ASes present in the Internet Routing Table: 13814 ARIN Prefixes per ASN: 7.81 ARIN Region origin ASes announcing only one prefix: 5292 ARIN Region transit ASes present in the Internet Routing Table: 1355 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 730821152 Equivalent to 43 /8s, 143 /16s and 114 /24s Percentage of available ARIN address space announced: 62.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 75200 Total RIPE prefixes after maximum aggregation: 43599 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 6738 Unique aggregates announced from the RIPE address blocks: 3805 RIPE Region origin ASes present in the Internet Routing Table: 14634 RIPE Prefixes per ASN: 0.46 RIPE Region origin ASes announcing only one prefix: 7528 RIPE Region transit ASes present in the Internet Routing Table: 2193 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 24 Number of RIPE addresses announced to Internet: 64040704 Equivalent to 3 /8s, 209 /16s and 47 /24s Percentage of available RIPE address space announced: 11.2 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 29487 Total LACNIC prefixes after maximum aggregation: 7006 LACNIC Deaggregation factor: 4.21 Prefixes being announced from the LACNIC address blocks: 27982 Unique aggregates announced from the LACNIC address blocks: 14984 LACNIC Region origin ASes present in the Internet Routing Table: 1322 LACNIC Prefixes per ASN: 21.17 LACNIC Region origin ASes announcing only one prefix: 410 LACNIC Region transit ASes present in the Internet Routing Table: 235 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 20 Number of LACNIC addresses announced to Internet: 76265984 Equivalent to 4 /8s, 139 /16s and 186 /24s Percentage of available LACNIC address space announced: 56.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7316 Total AfriNIC prefixes after maximum aggregation: 1874 AfriNIC Deaggregation factor: 3.90 Prefixes being announced from the AfriNIC address blocks: 5640 Unique aggregates announced from the AfriNIC address blocks: 1653 AfriNIC Region origin ASes present in the Internet Routing Table: 390 AfriNIC Prefixes per ASN: 14.46 AfriNIC Region origin ASes announcing only one prefix: 123 AfriNIC Region transit ASes present in the Internet Routing Table: 85 Average AfriNIC Region AS path length visible: 3.7 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 19917568 Equivalent to 1 /8s, 47 /16s and 235 /24s Percentage of available AfriNIC address space announced: 59.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1857 8409 490 Korea Telecom (KIX) 4755 1479 298 162 TATA Communications formerly 7545 1374 234 87 TPG Internet Pty Ltd 17488 1343 149 127 Hathway IP Over Cable Interne 17974 1188 288 64 PT TELEKOMUNIKASI INDONESIA 9583 1004 74 487 Sify Limited 24560 997 303 182 Bharti Airtel Ltd., Telemedia 4808 900 1670 244 CNCGROUP IP network: China169 9829 817 686 33 BSNL National Internet Backbo 4134 786 22092 414 CHINANET-BACKBONE Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3867 3716 281 bellsouth.net, inc. 4323 2732 1100 394 Time Warner Telecom 19262 1944 4597 278 Verizon Global Networks 1785 1786 698 128 PaeTec Communications, Inc. 20115 1491 1526 652 Charter Communications 7018 1476 5733 949 AT&T WorldNet Services 2386 1277 553 902 AT&T Data Communications Serv 6478 1274 254 155 AT&T Worldnet Services 22773 1177 2858 61 Cox Communications, Inc. 3356 1164 10876 397 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 35805 656 56 6 United Telecom of Georgia 9198 499 202 13 Kazakhtelecom Data Network Ad 3292 449 2026 390 TDC Tele Danmark 30890 444 111 206 Evolva Telecom 702 414 1870 326 UUNET - Commercial IP service 8866 403 117 18 Bulgarian Telecommunication C 8551 401 353 46 Bezeq International 3320 374 7328 325 Deutsche Telekom AG 3301 372 1414 327 TeliaNet Sweden 34984 365 89 183 BILISIM TELEKOM Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1527 3049 248 UniNet S.A. de C.V. 10620 1089 244 149 TVCABLE BOGOTA 28573 1020 818 100 NET Servicos de Comunicao S.A 7303 786 408 101 Telecom Argentina Stet-France 6503 720 178 222 AVANTEL, S.A. 22047 553 310 15 VTR PUNTO NET S.A. 14420 536 34 75 CORPORACION NACIONAL DE TELEC 7738 477 922 30 Telecomunicacoes da Bahia S.A 3816 475 197 95 Empresa Nacional de Telecomun 11172 447 99 76 Servicios Alestra S.A de C.V Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1169 445 10 TEDATA 24863 726 147 39 LINKdotNET AS number 36992 647 278 187 Etisalat MISR 3741 270 898 232 The Internet Solution 33776 206 12 12 Starcomms Nigeria Limited 2018 197 277 64 Tertiary Education Network 6713 195 186 16 Itissalat Al-MAGHRIB 29571 192 19 11 Ci Telecom Autonomous system 24835 189 78 9 RAYA Telecom - Egypt 16637 140 440 95 MTN Network Solutions Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3867 3716 281 bellsouth.net, inc. 4323 2732 1100 394 Time Warner Telecom 19262 1944 4597 278 Verizon Global Networks 4766 1857 8409 490 Korea Telecom (KIX) 1785 1786 698 128 PaeTec Communications, Inc. 8151 1527 3049 248 UniNet S.A. de C.V. 20115 1491 1526 652 Charter Communications 4755 1479 298 162 TATA Communications formerly 7018 1476 5733 949 AT&T WorldNet Services 7545 1374 234 87 TPG Internet Pty Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2732 2338 Time Warner Telecom 19262 1944 1666 Verizon Global Networks 1785 1786 1658 PaeTec Communications, Inc. 4766 1857 1367 Korea Telecom (KIX) 4755 1479 1317 TATA Communications formerly 7545 1374 1287 TPG Internet Pty Ltd 8151 1527 1279 UniNet S.A. de C.V. 17488 1343 1216 Hathway IP Over Cable Interne 8452 1169 1159 TEDATA 17974 1188 1124 PT TELEKOMUNIKASI INDONESIA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 36178 UNALLOCATED 12.20.60.0/23 6128 Cablevision Systems 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 6453 Teleglobe Inc. 41.223.196.0/24 36990 Alkan Telecom Ltd 41.223.197.0/24 36990 Alkan Telecom Ltd 41.223.198.0/24 36990 Alkan Telecom Ltd Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:25 /11:67 /12:198 /13:410 /14:717 /15:1299 /16:11183 /17:5376 /18:9216 /19:18523 /20:23234 /21:23225 /22:30226 /23:29701 /24:170990 /25:1048 /26:1192 /27:733 /28:118 /29:47 /30:6 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2471 3867 bellsouth.net, inc. 4766 1486 1857 Korea Telecom (KIX) 4323 1394 2732 Time Warner Telecom 1785 1245 1786 PaeTec Communications, Inc. 17488 1086 1343 Hathway IP Over Cable Interne 18566 1068 1087 Covad Communications 8452 1057 1169 TEDATA 11492 1048 1139 Cable One 10620 1003 1089 TVCABLE BOGOTA 19262 913 1944 Verizon Global Networks Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:39 2:2 4:13 8:293 12:2014 13:7 14:1 15:21 16:3 17:9 20:6 24:1433 27:277 31:1 32:59 33:22 38:688 40:98 41:2474 44:3 46:20 47:16 52:9 55:7 56:2 57:28 58:779 59:509 60:462 61:1069 62:1035 63:1968 64:3721 65:2336 66:4038 67:1827 68:1098 69:2760 70:741 71:444 72:1939 73:2 74:2302 75:253 76:324 77:906 78:619 79:435 80:986 81:778 82:505 83:452 84:694 85:1045 86:461 87:688 88:332 89:1557 90:97 91:2914 92:513 93:1006 94:1415 95:671 96:530 97:212 98:625 99:33 108:105 109:601 110:432 111:532 112:273 113:315 114:434 115:567 116:1092 117:653 118:482 119:899 120:137 121:724 122:1519 123:952 124:1128 125:1242 128:226 129:162 130:198 131:555 132:247 133:16 134:196 135:45 136:240 137:136 138:267 139:104 140:480 141:197 142:341 143:376 144:472 145:52 146:433 147:172 148:676 149:269 150:145 151:228 152:297 153:168 154:3 155:357 156:160 157:325 158:111 159:361 160:314 161:183 162:256 163:174 164:411 165:366 166:463 167:412 168:646 169:157 170:721 171:59 172:2 173:961 174:530 175:168 176:1 178:351 180:508 182:169 183:239 184:140 186:542 187:412 188:1045 189:737 190:3878 192:5753 193:4727 194:3401 195:2823 196:1179 198:3565 199:3513 200:5358 201:1582 202:7996 203:8273 204:4021 205:2400 206:2492 207:3071 208:3884 209:3468 210:2546 211:1311 212:1714 213:1664 214:660 215:69 216:4689 217:1514 218:503 219:380 220:1139 221:402 222:317 223:3 End of report From nathan at atlasnetworks.us Fri Aug 6 15:15:07 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Fri, 6 Aug 2010 20:15:07 +0000 Subject: Proxy Server In-Reply-To: References: Message-ID: <8C26A4FDAE599041A13EB499117D3C2816470D07@ex-mb-1.corp.atlasnetworks.us> > pfSense has everything: proxy (squid), firewall, bw-management, > captive portal and a very nice web interface for management: > www.pfsense.org The only thing it doesn't have is IPv6 support (yet). :( Best Regards, Nathan Eisenberg From paveldimow at gmail.com Fri Aug 6 15:35:31 2010 From: paveldimow at gmail.com (Pavel Dimow) Date: Fri, 6 Aug 2010 22:35:31 +0200 Subject: Per IP Subscriber DHCP Triggered RADIUS Accounting Message-ID: Hello, I work at small cable operator, and we are using Cisco CNR as DHCP server. Now, we want to offer some VAS to our customers. The problem is that we are using CNR as dhcp server, and VAS server need to know the ip address of every subscriber (static is not an option). DHCP lease query is not an option (something Cisco SCE is using) simply because VAS server does not support it. The closest thing that comes to my mind is that we use DDNS on CNR to send DNS updateds to our custom written daemon that will extract ip and A record (this will be the mac address of CPE). Any other options? Has anyone from cable world come to this or anyother solution? From paveldimow at gmail.com Fri Aug 6 15:37:26 2010 From: paveldimow at gmail.com (Pavel Dimow) Date: Fri, 6 Aug 2010 22:37:26 +0200 Subject: Per IP Subscriber DHCP Triggered RADIUS Accounting In-Reply-To: References: Message-ID: ok, subject is a little missliding as that would be an option if we can use Cisco router as DHCP which is not possible at the moment in our network. On Fri, Aug 6, 2010 at 10:35 PM, Pavel Dimow wrote: > Hello, > > I work at small cable operator, and we are using Cisco CNR as DHCP > server. Now, we want to offer > some VAS to our customers. The problem is that we are using CNR as > dhcp server, and VAS server need to know > the ip address of every subscriber (static is not an option). DHCP > lease query is not an option > (something Cisco SCE is using) ?simply because VAS server does not support it. > The closest thing that comes to my mind is that we use DDNS on CNR to > send DNS updateds to our custom > written daemon that will extract ip and A record (this will be the mac > address of CPE). > Any other options? Has anyone from cable world come to this or > anyother solution? > From graham at apolix.co.za Fri Aug 6 15:49:20 2010 From: graham at apolix.co.za (Graham Beneke) Date: Fri, 06 Aug 2010 22:49:20 +0200 Subject: Proxy Server In-Reply-To: <8C26A4FDAE599041A13EB499117D3C2816470D07@ex-mb-1.corp.atlasnetworks.us> References: <8C26A4FDAE599041A13EB499117D3C2816470D07@ex-mb-1.corp.atlasnetworks.us> Message-ID: <4C5C7550.6020301@apolix.co.za> On 06/08/2010 22:15, Nathan Eisenberg wrote: > The only thing it doesn't have is IPv6 support (yet). :( I was a huge fan of pfSense and I really enjoyed the interface, packaging and integration. The lack of IPv6 caused the end of that relationship. -- Graham Beneke From owen at delong.com Fri Aug 6 16:04:53 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 6 Aug 2010 14:04:53 -0700 Subject: Proxy Server In-Reply-To: <8C26A4FDAE599041A13EB499117D3C2816470D07@ex-mb-1.corp.atlasnetworks.us> References: <8C26A4FDAE599041A13EB499117D3C2816470D07@ex-mb-1.corp.atlasnetworks.us> Message-ID: On Aug 6, 2010, at 1:15 PM, Nathan Eisenberg wrote: > >> pfSense has everything: proxy (squid), firewall, bw-management, >> captive portal and a very nice web interface for management: >> www.pfsense.org > > The only thing it doesn't have is IPv6 support (yet). :( > > Best Regards, > Nathan Eisenberg > > > > Apparently it can be made to work: http://remcobressers.nl/2009/08/configuring-native-ipv6-pfsense/ Owen From strizhov at cs.colostate.edu Fri Aug 6 16:15:47 2010 From: strizhov at cs.colostate.edu (Mikhail Strizhov) Date: Fri, 06 Aug 2010 15:15:47 -0600 Subject: AS0 in AS path Message-ID: <4C5C7B83.307@cs.colostate.edu> hi nanog, Does anybody have\had experience with BGP announces containing AS 0 in AS path? I know that AS 0 is reserved by IANA, but still, is it possible to receive such announce messages? Thanks. -- Sincerely, Mikhail Strizhov Email: strizhov at cs.colostate.edu From kameron-lists at gasso.org Fri Aug 6 16:47:36 2010 From: kameron-lists at gasso.org (Kameron Gasso) Date: Fri, 06 Aug 2010 14:47:36 -0700 Subject: AS0 in AS path In-Reply-To: <4C5C7B83.307@cs.colostate.edu> References: <4C5C7B83.307@cs.colostate.edu> Message-ID: <4C5C82F8.9030004@gasso.org> On 08/06/2010 02:15 PM, Mikhail Strizhov wrote: > Does anybody have\had experience with BGP announces containing AS 0 in > AS path? > I know that AS 0 is reserved by IANA, but still, is it possible to > receive such announce messages? eBGP or iBGP? What type of device and/or software are you using to speak BGP? As far as I know, most devices should NOT let you set your ASN to 0 or let you add it to the AS path. My guess is it's probably going to be filtered by the BGP scanner, but I don't have any gear laying around that I can play with at the moment to confirm. :) -- Kameron Gasso | kameron at gasso.org From Valdis.Kletnieks at vt.edu Fri Aug 6 16:48:08 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 06 Aug 2010 17:48:08 -0400 Subject: AS0 in AS path In-Reply-To: Your message of "Fri, 06 Aug 2010 15:15:47 MDT." <4C5C7B83.307@cs.colostate.edu> References: <4C5C7B83.307@cs.colostate.edu> Message-ID: <20852.1281131288@localhost> On Fri, 06 Aug 2010 15:15:47 MDT, Mikhail Strizhov said: > Does anybody have\had experience with BGP announces containing AS 0 in > AS path? > I know that AS 0 is reserved by IANA, but still, is it possible to > receive such announce messages? After 3 decades in this business, I can make two predictions: 1) Somebody has managed to fat-finger something and announced AS0 at some point. 2) At least one vendor's gear promptly committed seppuku *after* passing the broken announcement on to its neighbors. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jyy_99 at yahoo.com Fri Aug 6 16:52:11 2010 From: jyy_99 at yahoo.com (Jessica Yu) Date: Fri, 6 Aug 2010 14:52:11 -0700 (PDT) Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: References: Message-ID: <604794.12749.qm@web53002.mail.re2.yahoo.com> I have a concern that your posting and your paper mix UUNet traffic with the Internet traffic.? I personally was very much involved in the ISP world (was working for Tier1?ISPs) during the period and I?d like to point out the following: UUNet?s (or any other individual network?s) traffic does NOT equal to the Internet traffic, even at that time! I was working at ANSnet and later UUnet due to a three party acquisition deal between AOL, WorldCom and CompuServe during that time period.? I did hear presentations about network traffic being doubling every 100 days by O?Dell but my understanding was that he was referring to UUnet?s traffic not the Internet traffic.? At the time, the Tier 1 ISPs included UUNet, MCI Network, Sprint Network, ANSnet, etc.? Each ISP could only collect network traffic stats on its own backbone and there was no one entity could collect the entire Internet traffic.? For this reason, the prediction by O?Dell could only be based on UUNet?s traffic stats.? ?I really doubt that O?Dell would say the Internet traffic doubling every 100 days rather than saying that of UUNet?s traffic.? ?I?d encourage you to do some research to find out?if he was really referring to the Internet traffic or just UUNet traffic.? The reference listed by your paper showed that he was saying ?network traffic? not ?Internet traffic.?? I do not know if making such distinction would alter the conclusion of your paper.? But, to me, there is a difference between one to predict the growth of one particular network based on the stats collected than?one to predict?the growth of the entire Internet with no solid data. Thanks!--Jessica ________________________________ From: Andrew Odlyzko To: nanog at nanog.org Sent: Thu, August 5, 2010 11:38:38 AM Subject: off-topic: historical query concerning the Internet bubble Apologies for intruding with this question, but I can't think of any group that might have more concrete information relevant to my current research. Enclosed below is an announcement of a paper on technology bubbles. It is based largely on the Internet bubble of a decade ago, and concentrates on the "Internet traffic doubling every 100 days" tale. As the paper shows, this myth was perceived in very different ways by different people, and this by itself helps undermine the foundations of much of modern economics and economic policy making. To get a better understanding of the dynamics of that bubble, to assist in the preparation of a book about that incident, I am soliciting information from anyone who was active in telecom during that period. I would particularly like to know what you and your colleagues estimated Internet traffic growth to be, and what your reaction was to the O'Dell/Sidgmore/WorldCom/UUNet myth.? If you were involved in the industry, and never heard of it, that would be extremely useful to know, too. Ideally, I would like concrete information, backed up by dates, and possibly even emails, and a permission to quote this information.? However, I will settle for more informal comments, and promise confidentiality to anyone who requests it. Andrew Odlyzko odlyzko at umn.edu ??? ? ? http://www.dtc.umn.edu/~odlyzko/doc/mania03.pdf ? ? ? ? ? Bubbles, gullibility, and other challenges for economics, ? ? ? ? ? ? psychology, sociology, and information sciences ? ? ? ? ? ? ? ? ? ? ? ? ? ? Andrew Odlyzko ? ? ? ? ? ? ? ? ? ? ? ? School of Mathematics ? ? ? ? ? ? ? ? ? ? and Digital Technology Center ? ? ? ? ? ? ? ? ? ? ? University of Minnesota ? ? ? ? ? ? ? ? ? ? ? ? ? ? odlyzko at umn.edu ? ? ? ? ? ? ? ? ? ? http://www.dtc.umn.edu/~odlyzko ? ? ? ? ? ? ? ? ? Preliminary version, August 5, 2010 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ABSTRACT ? Gullibility is the principal cause of bubbles.? Investors and the general public get snared by a "beautiful illusion" and throw caution to the wind. Attempts to identify and control bubbles are complicated by the fact that the authorities who might naturally be expected to take action have often (especially in recent years) been among the most gullible, and were cheerleaders for the exuberant behavior.? Hence what is needed is an objective measure of gullibility. ? This paper argues that it should be possible to develop such a measure. Examples demonstrate, contrary to the efficient market dogma, that in some manias, even top-level business and technology leaders do fall prey to collective hallucinations and become irrational in objective terms.? During the Internet bubble, for example, large classes of them first became unable to comprehend compound interest, and then lost even the ability to do simple arithmetic, to the point of not being able to distinguish 2 from 10.? This phenomenon, together with advances in analysis of social networks and related areas, points to possible ways to develop objective and quantitative tools for measuring gullibility and other aspects of human behavior implicated in bubbles.? It cannot be expected to infallibly detect all destructive bubbles, and may trigger false alarms, but it ought to alert observers to periods where collective investment behavior is becoming irrational. ? The proposed gullibility index might help in developing realistic economic models.? It should also assist in illuminating and guiding decision making. ----------------------------------------------------------------------------- If you would like to be on the mailing list for notifications of future papers on technology bubbles, please send me a note at odlyzko at umn.edu The previous three papers in this series are available at: 1.? Collective hallucinations and inefficient markets: The British Railway Mania of the 1840s ??? http://www.dtc.umn.edu/~odlyzko/doc/hallucinations.pdf 2.? This time is different: An example of a giant, wildly speculative, and successful investment mania, B.E. Journal of Economic Analysis & Policy, vol. 10, issue 1, 2010, article 60 (registration required) ??? http://www.bepress.com/bejeap/vol10/iss1/art60 ? preprint available at: ? ? ? ? http://www.dtc.umn.edu/~odlyzko/doc/mania01.pdf 3.? The collapse of the Railway Mania, the development of capital markets, and Robert Lucas Nash, a forgotten pioneer of accounting and financial analysis ??? http://www.dtc.umn.edu/~odlyzko/doc/mania02.pdf ----------------------------------------------------------------------------- Source materials for the Railway Mania and the Internet bubble are available at the web pages ? ? ??? http://www.dtc.umn.edu/~odlyzko/rrsources/ and ??? http://www.dtc.umn.edu/~odlyzko/isources/ From drc at virtualized.org Fri Aug 6 16:52:09 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 6 Aug 2010 11:52:09 -1000 Subject: AS0 in AS path In-Reply-To: <20852.1281131288@localhost> References: <4C5C7B83.307@cs.colostate.edu> <20852.1281131288@localhost> Message-ID: <40A42010-A679-4BF3-A481-9D72D034B258@virtualized.org> On Aug 6, 2010, at 11:48 AM, Valdis.Kletnieks at vt.edu wrote: > On Fri, 06 Aug 2010 15:15:47 MDT, Mikhail Strizhov said: >> Does anybody have\had experience with BGP announces containing AS 0 in >> AS path? >> I know that AS 0 is reserved by IANA, but still, is it possible to >> receive such announce messages? > > After 3 decades in this business, I can make two predictions: > > 1) Somebody has managed to fat-finger something and announced AS0 at some point. > > 2) At least one vendor's gear promptly committed seppuku *after* passing the > broken announcement on to its neighbors. Those aren't predictions, they're statistically certain observations. :-) Regards, -drc From cidr-report at potaroo.net Fri Aug 6 17:00:06 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Aug 2010 22:00:06 GMT Subject: BGP Update Report Message-ID: <201008062200.o76M06Lu045570@wattle.apnic.net> BGP Update Report Interval: 29-Jul-10 -to- 05-Aug-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS3464 26784 2.5% 6696.0 -- ASC-NET - Alabama Supercomputer Network 2 - AS14420 20508 1.9% 37.4 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 3 - AS35931 15633 1.5% 5211.0 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - AS5536 15520 1.5% 152.2 -- Internet-Egypt 5 - AS8452 14012 1.3% 17.4 -- TEDATA TEDATA 6 - AS48754 11048 1.1% 11048.0 -- SOBIS-AS SOBIS SOLUTIONS SRL 7 - AS25620 10953 1.0% 75.0 -- COTAS LTDA. 8 - AS45464 10527 1.0% 244.8 -- NEXTWEB-AS-AP Room 201, TGU Bldg 9 - AS35805 10374 1.0% 14.7 -- SILKNET-AS SILKNET AS 10 - AS31204 10209 1.0% 392.7 -- SUNCOMMUNICATIONS-AS JV "Sun Communications" Autonomous System 11 - AS2018 9790 0.9% 46.2 -- TENET-1 12 - AS5800 9781 0.9% 48.2 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 13 - AS32528 9487 0.9% 3162.3 -- ABBOTT Abbot Labs 14 - AS9829 8799 0.8% 41.5 -- BSNL-NIB National Internet Backbone 15 - AS37204 8143 0.8% 1163.3 -- TELONE 16 - AS36992 7638 0.7% 19.6 -- ETISALAT-MISR 17 - AS8151 7153 0.7% 38.0 -- Uninet S.A. de C.V. 18 - AS27738 7094 0.7% 33.8 -- Ecuadortelecom S.A. 19 - AS24560 6873 0.7% 10.3 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 20 - AS21017 6784 0.6% 357.1 -- VSI-AS VSI AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS48754 11048 1.1% 11048.0 -- SOBIS-AS SOBIS SOLUTIONS SRL 2 - AS3464 26784 2.5% 6696.0 -- ASC-NET - Alabama Supercomputer Network 3 - AS35931 15633 1.5% 5211.0 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - AS25090 3168 0.3% 3168.0 -- EOS-AS Energie Ouest Suisse Autonomous System 5 - AS32528 9487 0.9% 3162.3 -- ABBOTT Abbot Labs 6 - AS53532 1775 0.2% 1775.0 -- KINGMETALS - King Architectural Metals 7 - AS38784 1629 0.1% 1629.0 -- ORBICOMNET-AS-ID PT. Global Inti Corporatama 8 - AS37204 8143 0.8% 1163.3 -- TELONE 9 - AS16906 2198 0.2% 1099.0 -- El Salvador Network, S. A. 10 - AS523 2677 0.2% 892.3 -- REDSTONE-AS - Headquarters, USAISC 11 - AS27027 863 0.1% 863.0 -- ANBELL ASN-ANBELL 12 - AS47593 784 0.1% 784.0 -- ATELECOM A-Telcom Ltd 13 - AS11196 696 0.1% 696.0 -- NESTLE-USA - Nestle USA 14 - AS11613 577 0.1% 577.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 15 - AS26383 3966 0.4% 566.6 -- CHILITECH - CHILITECH INTERNET SOLUTIONS, INC. 16 - AS11032 464 0.0% 464.0 -- UQ - Universite du Quebec 17 - AS45034 461 0.0% 461.0 -- NORDSEE-AS Nordsee Gesellschaft m.b.H. 18 - AS9556 1709 0.2% 427.2 -- ADAM-AS-AP Adam Internet Pty Ltd 19 - AS50158 421 0.0% 421.0 -- CONNECT-LLC-AS Connect LLC 20 - AS10445 2440 0.2% 406.7 -- HTG - Huntleigh Telcom TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 129.66.0.0/17 13390 1.2% AS3464 -- ASC-NET - Alabama Supercomputer Network 2 - 129.66.128.0/17 13388 1.2% AS3464 -- ASC-NET - Alabama Supercomputer Network 3 - 91.212.23.0/24 11048 1.0% AS48754 -- SOBIS-AS SOBIS SOLUTIONS SRL 4 - 63.211.68.0/22 7872 0.7% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - 198.140.43.0/24 7747 0.7% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - 190.65.228.0/22 5751 0.5% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 7 - 130.36.35.0/24 4698 0.4% AS32528 -- ABBOTT Abbot Labs 8 - 130.36.34.0/24 4696 0.4% AS32528 -- ABBOTT Abbot Labs 9 - 41.34.29.0/24 3995 0.3% AS8452 -- TEDATA TEDATA 10 - 95.32.128.0/18 3265 0.3% AS21017 -- VSI-AS VSI AS 11 - 95.32.192.0/18 3260 0.3% AS21017 -- VSI-AS VSI AS 12 - 193.8.222.0/24 3168 0.3% AS25090 -- EOS-AS Energie Ouest Suisse Autonomous System 13 - 206.184.16.0/24 3085 0.3% AS174 -- COGENT Cogent/PSI 14 - 202.92.235.0/24 2828 0.2% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 15 - 117.20.0.0/24 2601 0.2% AS23670 -- OZSERVERS-AU Oz Servers, Data Centres, Australia Wide 16 - 208.51.46.0/24 1775 0.2% AS53532 -- KINGMETALS - King Architectural Metals 17 - 143.138.107.0/24 1698 0.1% AS747 -- TAEGU-AS - Headquarters, USAISC 18 - 72.20.248.0/21 1651 0.1% AS26383 -- CHILITECH - CHILITECH INTERNET SOLUTIONS, INC. 19 - 202.75.17.0/24 1629 0.1% AS38784 -- ORBICOMNET-AS-ID PT. Global Inti Corporatama 20 - 64.86.26.0/23 1555 0.1% AS37204 -- TELONE Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Aug 6 17:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Aug 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201008062200.o76M00bD045541@wattle.apnic.net> This report has been generated at Fri Aug 6 21:11:36 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 Prefixes CIDR Agg 30-07-10 330809 203447 31-07-10 330957 203376 01-08-10 330953 203451 02-08-10 331084 203492 03-08-10 331158 203792 04-08-10 331218 203836 05-08-10 331107 203907 06-08-10 330860 204157 AS Summary 35018 Number of ASes in routing system 14873 Number of ASes announcing only one prefix 4488 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 95690560 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'). --- 06Aug10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 331326 204069 127257 38.4% All ASes AS6389 3867 286 3581 92.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4488 1834 2654 59.1% TWTC - tw telecom holdings, inc. AS19262 1950 282 1668 85.5% VZGNI-TRANSIT - Verizon Internet Services Inc. AS4766 1857 504 1353 72.9% KIXS-AS-KR Korea Telecom AS22773 1177 66 1111 94.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1479 395 1084 73.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS5668 1128 89 1039 92.1% AS-5668 - CenturyTel Internet Holdings, Inc. AS18566 1087 63 1024 94.2% COVAD - Covad Communications Co. AS17488 1343 320 1023 76.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1527 623 904 59.2% Uninet S.A. de C.V. AS6478 1274 374 900 70.6% ATT-INTERNET3 - AT&T WorldNet Services AS10620 1089 288 801 73.6% Telmex Colombia S.A. AS8452 1169 422 747 63.9% TEDATA TEDATA AS7545 1392 713 679 48.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS7303 790 119 671 84.9% Telecom Argentina S.A. AS4808 900 278 622 69.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 677 72 605 89.4% MPX-AS Microplex PTY LTD AS35805 658 113 545 82.8% SILKNET-AS SILKNET AS AS7552 652 120 532 81.6% VIETEL-AS-AP Vietel Corporation AS7018 1477 952 525 35.5% ATT-INTERNET4 - AT&T WorldNet Services AS4780 684 164 520 76.0% SEEDNET Digital United Inc. AS24560 997 487 510 51.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17676 582 80 502 86.3% GIGAINFRA Softbank BB Corp. AS3356 1164 664 500 43.0% LEVEL3 Level 3 Communications AS9443 572 76 496 86.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7011 1139 656 483 42.4% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS1785 1786 1309 477 26.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS22047 553 81 472 85.4% VTR BANDA ANCHA S.A. AS14420 537 77 460 85.7% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS9198 499 40 459 92.0% KAZTELECOM-AS JSC Kazakhtelecom Total 38494 11547 26947 70.0% Top 30 total Possible Bogus Routes 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS6453 GLOBEINTERNET TATA Communications 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 78.41.160.0/21 AS8487 PHIBEE Phibee& Phibee Telecom AS 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 100.100.100.0/24 AS3549 GBLX Global Crossing Ltd. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 116.68.136.0/21 AS28045 Pantel Communications 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.51.100.0/24 AS16953 ASCENT-MEDIA-GROUP-LLC - Ascent Media Group, LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.72.224.0/21 AS24013 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 204.238.70.0/24 AS36826 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.196.24.0/22 AS33724 BIZNESSHOSTING - VOLICO 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.72.192.0/23 AS27375 IDS-TELECOM - IDS Telecom 206.72.194.0/23 AS27375 IDS-TELECOM - IDS Telecom 206.72.196.0/23 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 206.72.208.0/24 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.209.0/24 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 208.84.76.0/22 AS18561 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From strizhov at cs.colostate.edu Fri Aug 6 17:10:36 2010 From: strizhov at cs.colostate.edu (Mikhail Strizhov) Date: Fri, 06 Aug 2010 16:10:36 -0600 Subject: AS0 in AS path In-Reply-To: <4C5C82F8.9030004@gasso.org> References: <4C5C7B83.307@cs.colostate.edu> <4C5C82F8.9030004@gasso.org> Message-ID: <4C5C885C.3050700@cs.colostate.edu> Thanks everyone. Answer is simple - 4byte ASN's. I was parsing Route Views RIB-IN tables, and found that, by default, Quagga is using 4byte AS length field to store 2-byte and 4-byte AS Numbers. So, using 2 bytes length in parser, I had wierd output like "0 3549 0 1239" and so on. -- Sincerely, Mikhail Strizhov Email: strizhov at cs.colostate.edu On 08/06/2010 03:47 PM, Kameron Gasso wrote: > On 08/06/2010 02:15 PM, Mikhail Strizhov wrote: >> Does anybody have\had experience with BGP announces containing AS 0 in >> AS path? >> I know that AS 0 is reserved by IANA, but still, is it possible to >> receive such announce messages? > eBGP or iBGP? What type of device and/or software are you using to > speak BGP? > > As far as I know, most devices should NOT let you set your ASN to 0 or > let you add it to the AS path. > > My guess is it's probably going to be filtered by the BGP scanner, but I > don't have any gear laying around that I can play with at the moment to > confirm. :) From odlyzko at umn.edu Fri Aug 6 21:13:42 2010 From: odlyzko at umn.edu (Andrew Odlyzko) Date: Fri, 06 Aug 2010 21:13:42 -0500 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: <604794.12749.qm@web53002.mail.re2.yahoo.com> References: <604794.12749.qm@web53002.mail.re2.yahoo.com> Message-ID: <4c5cc156.O6lz14hZ9YHbrdjO%odlyzko@umn.edu> To entire list: I have received several requests to post a summary of the comments that are flowing in, so I will do so in a couple of days, say by Tuesday of next week, to allow for vacations, ... In the meantime, I encourage further contributions. To Jessica: If my posting or my paper mix UUNet traffic with that of the entire Internet, I apologize for not being clear enough. O'Dell and Sidgmore always, as far as I know (although I only have a transcript of the O'Dell presentation at Stanford in May 2000, http://www.dtc.umn.edu/~odlyzko/isources/odell-transcript.txt) spoke just about UUNet capacity. However, the myth was that the traffic on the Internet as a whole was "doubling every 100 days." The puzzle of how people could confuse traffic and capacity is considered in some detail in Section 5 of the paper. From the O'Dell presentation it is possible to guess that the intended implication was that UUNet was growing much faster than the rest of the Internet, but in any case I have not seen any references where either O'Dell or In the presentations that you heard by O'Dell (was that internal to WorldCom, and if so when), are you sure he was talking of traffic, and not capacity? It makes a difference in evaluting his claims. Which of my references has O'Dell saying ?network traffic?? I cannot find it. The only similar quote I can find is in Section 5, where Joe Cook of WorldCom is talking of ?network traffic,' but there it is clear it is just WorldCom traffic he has in mind. Andrew Jessica Yu wrote: > I have a concern that your posting and your paper mix UUNet traffic with the > Internet traffic.? I personally was very much involved in the ISP world (was > working for Tier1?ISPs) during the period and I?d like to point out the > following: > UUNet?s (or any other individual network?s) traffic does NOT equal to the > Internet traffic, even at that time! > I was working at ANSnet and later UUnet due to a three party acquisition deal > between AOL, WorldCom and CompuServe during that time period.? I did hear > presentations about network traffic being doubling every 100 days by O?Dell but > my understanding was that he was referring to UUnet?s traffic not the Internet > traffic.? > > At the time, the Tier 1 ISPs included UUNet, MCI Network, Sprint Network, > ANSnet, etc.? Each ISP could only collect network traffic stats on its own > backbone and there was no one entity could collect the entire Internet traffic.? > For this reason, the prediction by O?Dell could only be based on UUNet?s traffic > stats.? ?I really doubt that O?Dell would say the Internet traffic doubling > every 100 days rather than saying that of UUNet?s traffic.? ?I?d encourage you > to do some research to find out?if he was really referring to the Internet > traffic or just UUNet traffic.? The reference listed by your paper showed that > he was saying ?network traffic? not ?Internet traffic.?? > > I do not know if making such distinction would alter the conclusion of your > paper.? But, to me, there is a difference between one to predict the growth of > one particular network based on the stats collected than?one to predict?the > growth of the entire Internet with no solid data. > Thanks!--Jessica > > > > > ________________________________ > From: Andrew Odlyzko > To: nanog at nanog.org > Sent: Thu, August 5, 2010 11:38:38 AM > Subject: off-topic: historical query concerning the Internet bubble > > Apologies for intruding with this question, but I can't think > of any group that might have more concrete information relevant > to my current research. > > > > Enclosed below is an announcement of a paper on technology bubbles. > It is based largely on the Internet bubble of a decade ago, and > concentrates on the "Internet traffic doubling every 100 days" tale. > As the paper shows, this myth was perceived in very different ways > by different people, and this by itself helps undermine the foundations > of much of modern economics and economic policy making. > > To get a better understanding of the dynamics of that bubble, to assist > in the preparation of a book about that incident, I am soliciting information > from anyone who was active in telecom during that period. I would particularly > like to know what you and your colleagues estimated Internet traffic growth to > be, and what your reaction was to the O'Dell/Sidgmore/WorldCom/UUNet myth.? If > you were involved in the industry, > and never heard of it, that would be extremely useful to know, too. > > Ideally, I would like concrete information, backed up by dates, and possibly > even emails, and a permission to quote this information.? However, I will > settle for more informal comments, and promise confidentiality to anyone > who requests it. > > Andrew Odlyzko > odlyzko at umn.edu > > > > > ??? ? ? http://www.dtc.umn.edu/~odlyzko/doc/mania03.pdf > > > ? ? ? ? ? Bubbles, gullibility, and other challenges for economics, > ? ? ? ? ? ? psychology, sociology, and information sciences > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? Andrew Odlyzko > > ? ? ? ? ? ? ? ? ? ? ? ? School of Mathematics > ? ? ? ? ? ? ? ? ? ? and Digital Technology Center > ? ? ? ? ? ? ? ? ? ? ? University of Minnesota > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? odlyzko at umn.edu > ? ? ? ? ? ? ? ? ? ? http://www.dtc.umn.edu/~odlyzko > > ? ? ? ? ? ? ? ? ? Preliminary version, August 5, 2010 > > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ABSTRACT > > ? Gullibility is the principal cause of bubbles.? Investors and the general > public get snared by a "beautiful illusion" and throw caution to the wind. > Attempts to identify and control bubbles are complicated by the fact that the > authorities who might naturally be expected to take action have often > (especially in recent years) been among the most gullible, and were cheerleaders > for the exuberant behavior.? Hence what is needed is an objective measure of > gullibility. > > ? This paper argues that it should be possible to develop such a measure. > Examples demonstrate, contrary to the efficient market dogma, that in some > manias, even top-level business and technology leaders do fall prey to > collective hallucinations and become irrational in objective terms.? During the > Internet bubble, for example, large classes of them first became unable to > comprehend compound interest, and then lost even the ability to do simple > arithmetic, to the point of not being able to distinguish 2 from 10.? This > phenomenon, together with advances in analysis of social networks and related > areas, points to possible ways to develop objective and quantitative tools for > measuring gullibility and other aspects of human behavior implicated in > bubbles.? It cannot be expected to infallibly detect all destructive bubbles, > and may trigger false alarms, but it ought to alert observers to periods where > collective investment behavior is becoming irrational. > > ? The proposed gullibility index might help in developing realistic economic > models.? It should also assist in illuminating and guiding decision making. > > > > ----------------------------------------------------------------------------- > > If you would like to be on the mailing list for notifications of future > papers on technology bubbles, please send me a note at odlyzko at umn.edu > > > The previous three papers in this series are available at: > > 1.? Collective hallucinations and inefficient markets: The British Railway Mania > of the 1840s > > ??? http://www.dtc.umn.edu/~odlyzko/doc/hallucinations.pdf > > > 2.? This time is different: An example of a giant, wildly speculative, and > successful investment mania, B.E. Journal of Economic Analysis & Policy, vol. > 10, issue 1, 2010, article 60 (registration required) > > ??? http://www.bepress.com/bejeap/vol10/iss1/art60 > > ? preprint available at: > > ? ? ? ? http://www.dtc.umn.edu/~odlyzko/doc/mania01.pdf > > > 3.? The collapse of the Railway Mania, the development of capital markets, and > Robert Lucas Nash, a forgotten pioneer of accounting and financial analysis > > ??? http://www.dtc.umn.edu/~odlyzko/doc/mania02.pdf > > ----------------------------------------------------------------------------- > > Source materials for the Railway Mania and the Internet bubble are available > at the web pages > > ? ? ??? http://www.dtc.umn.edu/~odlyzko/rrsources/ > > and > > ??? http://www.dtc.umn.edu/~odlyzko/isources/ > > > From qiu.min98 at gmail.com Fri Aug 6 21:47:40 2010 From: qiu.min98 at gmail.com (Min) Date: Fri, 6 Aug 2010 22:47:40 -0400 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: <604794.12749.qm@web53002.mail.re2.yahoo.com> References: <604794.12749.qm@web53002.mail.re2.yahoo.com> Message-ID: They were private peering stats (aggregated) from UUNET which show 3.5 x for roughly two years, right before the MPLS conference in GMU. The stats included 15% or whatever% ATM cell tax. ANS was not included;-) There was also another dimension. In addition to the vertical growth. The backbone also expanded horizontally (coverage/millage), in a very rapid pace. I guess this was the reason some said the growth rate was double digits. I'm not sure simplify the math can explain the complexity of the network growth. Of cause, this is another topic. Min On Fri, Aug 6, 2010 at 5:52 PM, Jessica Yu wrote: > I have a concern that your posting and your paper mix UUNet traffic with > the > Internet traffic. I personally was very much involved in the ISP world > (was > working for Tier1 ISPs) during the period and I?d like to point out the > following: > UUNet?s (or any other individual network?s) traffic does NOT equal to the > Internet traffic, even at that time! > I was working at ANSnet and later UUnet due to a three party acquisition > deal > between AOL, WorldCom and CompuServe during that time period. I did hear > presentations about network traffic being doubling every 100 days by O?Dell > but > my understanding was that he was referring to UUnet?s traffic not the > Internet > traffic. > > At the time, the Tier 1 ISPs included UUNet, MCI Network, Sprint Network, > ANSnet, etc. Each ISP could only collect network traffic stats on its own > backbone and there was no one entity could collect the entire Internet > traffic. > For this reason, the prediction by O?Dell could only be based on UUNet?s > traffic > stats. I really doubt that O?Dell would say the Internet traffic doubling > every 100 days rather than saying that of UUNet?s traffic. I?d encourage > you > to do some research to find out if he was really referring to the Internet > traffic or just UUNet traffic. The reference listed by your paper showed > that > he was saying ?network traffic? not ?Internet traffic.? > > I do not know if making such distinction would alter the conclusion of your > paper. But, to me, there is a difference between one to predict the growth > of > one particular network based on the stats collected than one to predict the > growth of the entire Internet with no solid data. > Thanks!--Jessica > > > > > ________________________________ > From: Andrew Odlyzko > To: nanog at nanog.org > Sent: Thu, August 5, 2010 11:38:38 AM > Subject: off-topic: historical query concerning the Internet bubble > > Apologies for intruding with this question, but I can't think > of any group that might have more concrete information relevant > to my current research. > > > > Enclosed below is an announcement of a paper on technology bubbles. > It is based largely on the Internet bubble of a decade ago, and > concentrates on the "Internet traffic doubling every 100 days" tale. > As the paper shows, this myth was perceived in very different ways > by different people, and this by itself helps undermine the foundations > of much of modern economics and economic policy making. > > To get a better understanding of the dynamics of that bubble, to assist > in the preparation of a book about that incident, I am soliciting > information > from anyone who was active in telecom during that period. I would > particularly > like to know what you and your colleagues estimated Internet traffic growth > to > be, and what your reaction was to the O'Dell/Sidgmore/WorldCom/UUNet myth. > If > you were involved in the industry, > and never heard of it, that would be extremely useful to know, too. > > Ideally, I would like concrete information, backed up by dates, and > possibly > even emails, and a permission to quote this information. However, I will > settle for more informal comments, and promise confidentiality to anyone > who requests it. > > Andrew Odlyzko > odlyzko at umn.edu > > > > > http://www.dtc.umn.edu/~odlyzko/doc/mania03.pdf > > > Bubbles, gullibility, and other challenges for economics, > psychology, sociology, and information sciences > > Andrew Odlyzko > > School of Mathematics > and Digital Technology Center > University of Minnesota > > odlyzko at umn.edu > http://www.dtc.umn.edu/~odlyzko > > Preliminary version, August 5, 2010 > > > ABSTRACT > > Gullibility is the principal cause of bubbles. Investors and the general > public get snared by a "beautiful illusion" and throw caution to the wind. > Attempts to identify and control bubbles are complicated by the fact that > the > authorities who might naturally be expected to take action have often > (especially in recent years) been among the most gullible, and were > cheerleaders > for the exuberant behavior. Hence what is needed is an objective measure > of > gullibility. > > This paper argues that it should be possible to develop such a measure. > Examples demonstrate, contrary to the efficient market dogma, that in some > manias, even top-level business and technology leaders do fall prey to > collective hallucinations and become irrational in objective terms. During > the > Internet bubble, for example, large classes of them first became unable to > comprehend compound interest, and then lost even the ability to do simple > arithmetic, to the point of not being able to distinguish 2 from 10. This > phenomenon, together with advances in analysis of social networks and > related > areas, points to possible ways to develop objective and quantitative tools > for > measuring gullibility and other aspects of human behavior implicated in > bubbles. It cannot be expected to infallibly detect all destructive > bubbles, > and may trigger false alarms, but it ought to alert observers to periods > where > collective investment behavior is becoming irrational. > > The proposed gullibility index might help in developing realistic > economic > models. It should also assist in illuminating and guiding decision making. > > > > > ----------------------------------------------------------------------------- > > If you would like to be on the mailing list for notifications of future > papers on technology bubbles, please send me a note at odlyzko at umn.edu > > > The previous three papers in this series are available at: > > 1. Collective hallucinations and inefficient markets: The British Railway > Mania > of the 1840s > > http://www.dtc.umn.edu/~odlyzko/doc/hallucinations.pdf > > > 2. This time is different: An example of a giant, wildly speculative, and > successful investment mania, B.E. Journal of Economic Analysis & Policy, > vol. > 10, issue 1, 2010, article 60 (registration required) > > http://www.bepress.com/bejeap/vol10/iss1/art60 > > preprint available at: > > http://www.dtc.umn.edu/~odlyzko/doc/mania01.pdf > > > 3. The collapse of the Railway Mania, the development of capital markets, > and > Robert Lucas Nash, a forgotten pioneer of accounting and financial analysis > > http://www.dtc.umn.edu/~odlyzko/doc/mania02.pdf > > > ----------------------------------------------------------------------------- > > Source materials for the Railway Mania and the Internet bubble are > available > at the web pages > > http://www.dtc.umn.edu/~odlyzko/rrsources/ > > and > > http://www.dtc.umn.edu/~odlyzko/isources/ > > > > From hrlinneweh at sbcglobal.net Fri Aug 6 23:44:20 2010 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Fri, 6 Aug 2010 21:44:20 -0700 (PDT) Subject: Recommended 1Gb SFP for ~115km? In-Reply-To: <5746599E-E439-4D98-AC4B-B459F51122CF@inoc.net> References: <5746599E-E439-4D98-AC4B-B459F51122CF@inoc.net> Message-ID: <196052.79322.qm@web180309.mail.gq1.yahoo.com> Finisar can accommodate you http://www.sanspot.com/Finisar-SFP-Transceiver-p/finisar-sfp.htm -henry ________________________________ From: Robert Blayzor To: "Abello, Vinny" Cc: nanog at nanog.org Sent: Fri, August 6, 2010 10:52:17 AM Subject: Re: Recommended 1Gb SFP for ~115km? On Aug 4, 2010, at 12:27 PM, Abello, Vinny wrote: > Thanks for the input, Justin. I'm familiar with Transition Networks and have > used their solutions in other scenarios (as well as MRV). I'm aware of the > fiber characteristics being a major factor of the link budget and > dispersion, etc. I am waiting on measurements from the company who is > finishing the splicing of the fiber for us so I know what I have to work > with. If you're fine with 3rd party optics, FluxLight has BIDI SFP's that will reach up to 120km. http://www.fluxlightinc.com/prod.php?id=309 They show up as Cisco SFP's right in the switch/router. I've had good luck with the 40 & 80km ones in the past. -- Robert Blayzor INOC, LLC rblayzor at inoc.net http://www.inoc.net/~rblayzor/ From jmamodio at gmail.com Sat Aug 7 08:12:54 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sat, 7 Aug 2010 08:12:54 -0500 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: <4c5cc156.O6lz14hZ9YHbrdjO%odlyzko@umn.edu> References: <604794.12749.qm@web53002.mail.re2.yahoo.com> <4c5cc156.O6lz14hZ9YHbrdjO%odlyzko@umn.edu> Message-ID: Andrew, don't know if you want to research a little bit about this topic and add something to your paper but IMHO there is another Internet related bubble that keeps growing and may end exploding someday. The governance, speculation and commercialization of the Domain Name System. If you are interested I can give you some pointers off-list. Regards Jorge From lists at internetpolicyagency.com Sat Aug 7 12:09:31 2010 From: lists at internetpolicyagency.com (Roland Perry) Date: Sat, 7 Aug 2010 18:09:31 +0100 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: References: <5AC3E79A-392B-4D1B-BFC7-2700942FDC3C@ianai.net> <$4h4hQNoSDXMFA3R@perry.co.uk> Message-ID: In article , Patrick W. Gilmore writes >> Keeping it in the family a little, Mike was quoted as saying this - >>see p2: https://www.linx.net/files/hotlinx/hotlinx-3.pdf >> >> Although there were two factors here as far as LINX itself was >>concerned - growth in members as well as growth in traffic from >>each individual member. > >Even ignore the fact this is overestimating growth, it still is >not 12.55 times in one year. Or even double in 100 days. I wasn't suggesting LINX traffic was doubling every 100 days (it was tripling annually), simply pointing out that in 2001 Mike said that "a good rule of thumb during the late 1990's was that traffic doubled every 100 days", and going into print with that shows it was an accepted meme at the time. -- Roland Perry From randy at psg.com Sat Aug 7 15:42:36 2010 From: randy at psg.com (Randy Bush) Date: Sat, 07 Aug 2010 13:42:36 -0700 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: References: <5AC3E79A-392B-4D1B-BFC7-2700942FDC3C@ianai.net> <$4h4hQNoSDXMFA3R@perry.co.uk> Message-ID: > I wasn't suggesting LINX traffic was doubling every 100 days (it was > tripling annually), simply pointing out that in 2001 Mike said that "a > good rule of thumb during the late 1990's was that traffic doubled > every 100 days", and going into print with that shows it was an > accepted meme at the time. actually, my altzheimer's device says that it is a meme today that mo said that then. my memory is that he said doubling every nine months. randy From ospfisisis at gmail.com Sat Aug 7 20:21:05 2010 From: ospfisisis at gmail.com (Mark Wall) Date: Sat, 7 Aug 2010 21:21:05 -0400 Subject: SOS: Cogent NOC Conact Message-ID: if there's a Cogent NOC admin here, can you please contact meoff the list. thanks. -mw From ethan.l.whitt at gmail.com Sat Aug 7 22:04:00 2010 From: ethan.l.whitt at gmail.com (Ethan Whitt) Date: Sat, 7 Aug 2010 20:04:00 -0700 Subject: Provisioning and managing TE and L2/L3 vpns Message-ID: We operate a dual vendor network and am looking for recommendations on provisioning and managing TE, layer 2 vpns, and layer 3 vpns for Juniper routers. ?Today we use Cisco IP solution center for these functions on our Cisco routers. ?We have had mixed experiences with ISC, so we would consider a dual vendor tool. ?Any lessons learned from real world experiences on either topic would be appreciated. thanks. ~elw From jcdill.lists at gmail.com Sat Aug 7 22:52:51 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Sat, 07 Aug 2010 20:52:51 -0700 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: References: <5AC3E79A-392B-4D1B-BFC7-2700942FDC3C@ianai.net> <$4h4hQNoSDXMFA3R@perry.co.uk> Message-ID: <4C5E2A13.6000509@gmail.com> Randy Bush wrote: > my memory is that he said doubling every nine months. Mine too. jc From randy at psg.com Sun Aug 8 07:22:29 2010 From: randy at psg.com (Randy Bush) Date: Sun, 08 Aug 2010 05:22:29 -0700 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: <4C5E2A13.6000509@gmail.com> References: <5AC3E79A-392B-4D1B-BFC7-2700942FDC3C@ianai.net> <$4h4hQNoSDXMFA3R@perry.co.uk> <4C5E2A13.6000509@gmail.com> Message-ID: >> my memory is that he said doubling every nine months. > Mine too. mo's too. i asked. randy From odlyzko at umn.edu Sun Aug 8 08:30:44 2010 From: odlyzko at umn.edu (Andrew Odlyzko) Date: Sun, 08 Aug 2010 08:30:44 -0500 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: References: <5AC3E79A-392B-4D1B-BFC7-2700942FDC3C@ianai.net> <$4h4hQNoSDXMFA3R@perry.co.uk> <4C5E2A13.6000509@gmail.com> Message-ID: <4c5eb184.zCi3ckNtt9RxZE0d%odlyzko@umn.edu> Fascinating. Memories may be plastic (something that has been established scientifically), or else we may have yet another inconsistency to add to the pile of others. Is there any documentation about the "doubling every nine months"? I have never seen that particular claim emanating from anyone involved with WorldCom/UUNet. On the other hand, existing record shows (among others): 1. U.S. Department of Commerce white paper from April 1998, http://govinfo.library.unt.edu/ecommerce/EDEreprt.pdf on p. 8 declares that "UUNET, one of the largest Internet backbone providers, estimates that Internet traffic doubles every 100 days," with a reference to an Inktomi white paper that attributes this claim to Mike O'Dell. The Inktomi report is no longer on the Web, but I can provide a copy to anyone interested. 2. The transcript of the May 2000 presentation by O'Dell at a Stanford conference clearly has him saying that the capacity of the UUNet network, as measured by OC12-miles, doubles every four months, http://www.dtc.umn.edu/~odlyzko/isources/odell-transcript.txt As is explained in my paper, in the 1998-2000 time frame, essentially all the WorldCom/UUNet claims then seemed to be about capacity, not traffic. 3. The year-end 2000 email from O'Dell to Dave Farber's IP list, http://www.interesting-people.org/archives/interesting-people/200011/msg00058.html has him talking of traffic doubling each year, while capacity grows 8-fold. If some time in that period there was a claim of a "doubling every nine months," too, that would be very interesting. Andrew Randy Bush wrote: > >> my memory is that he said doubling every nine months. > > Mine too. > > mo's too. i asked. > > randy From jared at puck.nether.net Sun Aug 8 09:29:32 2010 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 8 Aug 2010 10:29:32 -0400 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: <4c5eb184.zCi3ckNtt9RxZE0d%odlyzko@umn.edu> References: <5AC3E79A-392B-4D1B-BFC7-2700942FDC3C@ianai.net> <$4h4hQNoSDXMFA3R@perry.co.uk> <4C5E2A13.6000509@gmail.com> <4c5eb184.zCi3ckNtt9RxZE0d%odlyzko@umn.edu> Message-ID: <8F756AB3-F5A7-4C5D-9A60-13AEEC0EF772@puck.nether.net> One thing I have heard repeated about one large carrier is that only 10% of their network is used for their Internet product. The remainder of it is used for private leased lines (could also be someone running IP) or another carrier that is leasing a loop or tdm service from them. Jared Mauch On Aug 8, 2010, at 9:30 AM, odlyzko at umn.edu (Andrew Odlyzko) wrote: > Fascinating. Memories may be plastic (something that has been > established scientifically), or else we may have yet another > inconsistency to add to the pile of others. Is there any > documentation about the "doubling every nine months"? I have > never seen that particular claim emanating from anyone involved > with WorldCom/UUNet. > > On the other hand, existing record shows (among others): > > 1. U.S. Department of Commerce white paper from April 1998, > > http://govinfo.library.unt.edu/ecommerce/EDEreprt.pdf > > on p. 8 declares that "UUNET, one of the largest Internet > backbone providers, estimates that Internet traffic doubles > every 100 days," with a reference to an Inktomi white paper > that attributes this claim to Mike O'Dell. The Inktomi > report is no longer on the Web, but I can provide a copy > to anyone interested. > > 2. The transcript of the May 2000 presentation by O'Dell > at a Stanford conference clearly has him saying that the > capacity of the UUNet network, as measured by OC12-miles, > doubles every four months, > > http://www.dtc.umn.edu/~odlyzko/isources/odell-transcript.txt > > As is explained in my paper, in the 1998-2000 time frame, > essentially all the WorldCom/UUNet claims then seemed to be > about capacity, not traffic. > > 3. The year-end 2000 email from O'Dell to Dave Farber's IP list, > > http://www.interesting-people.org/archives/interesting-people/200011/msg00058.html > > has him talking of traffic doubling each year, while capacity > grows 8-fold. > > If some time in that period there was a claim of a "doubling > every nine months," too, that would be very interesting. > > Andrew > > > > > > Randy Bush wrote: > >>>> my memory is that he said doubling every nine months. >>> Mine too. >> >> mo's too. i asked. >> >> randy From booloo at ucsc.edu Sun Aug 8 18:21:02 2010 From: booloo at ucsc.edu (Mark Boolootian) Date: Sun, 8 Aug 2010 16:21:02 -0700 Subject: Google wants your Internet to be faster Message-ID: <20100808232102.GA12802@root.ucsc.edu> Cringely has a theory and it involves Google and Verizon, but it doesn't involve net neutrality: http://www.nytimes.com/2010/08/08/opinion/08cringeley.html?_r=2 From raymond at prolocation.net Sun Aug 8 18:25:33 2010 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Mon, 9 Aug 2010 01:25:33 +0200 (CEST) Subject: Google wants your Internet to be faster In-Reply-To: <20100808232102.GA12802@root.ucsc.edu> References: <20100808232102.GA12802@root.ucsc.edu> Message-ID: Hi! > Cringely has a theory and it involves Google and Verizon, > but it doesn't involve net neutrality: > > http://www.nytimes.com/2010/08/08/opinion/08cringeley.html?_r=2 Woow this is fantactic news. Oh wait. Didnt Akamai invent this years ago? Bye, Raymond. From tagno25 at gmail.com Sun Aug 8 18:38:57 2010 From: tagno25 at gmail.com (Philip Dorr) Date: Sun, 8 Aug 2010 18:38:57 -0500 Subject: Google wants your Internet to be faster In-Reply-To: References: <20100808232102.GA12802@root.ucsc.edu> Message-ID: nytimes==troll (when it comes to technology) On Sun, Aug 8, 2010 at 6:25 PM, Raymond Dijkxhoorn wrote: > Hi! > >> Cringely has a theory and it involves Google and Verizon, >> but it doesn't involve net neutrality: >> >> ?http://www.nytimes.com/2010/08/08/opinion/08cringeley.html?_r=2 > > Woow this is fantactic news. Oh wait. Didnt Akamai invent this years ago? > > Bye, > Raymond. > > From lists at memetic.org Sun Aug 8 18:56:00 2010 From: lists at memetic.org (Adam Armstrong) Date: Mon, 09 Aug 2010 00:56:00 +0100 Subject: Google wants your Internet to be faster In-Reply-To: <20100808232102.GA12802@root.ucsc.edu> References: <20100808232102.GA12802@root.ucsc.edu> Message-ID: <4C5F4410.1030107@memetic.org> On 09/08/2010 00:21, Mark Boolootian wrote: > > Cringely has a theory and it involves Google and Verizon, > but it doesn't involve net neutrality: > > http://www.nytimes.com/2010/08/08/opinion/08cringeley.html?_r=2 > I'd assumed this would have been everyone's guess when the stories first appeared. It's not even a particularly new idea for Google, but it's probably the first time the media has heard of it. adam. From swmike at swm.pp.se Mon Aug 9 00:21:17 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 9 Aug 2010 07:21:17 +0200 (CEST) Subject: Google wants your Internet to be faster In-Reply-To: References: <20100808232102.GA12802@root.ucsc.edu> Message-ID: On Mon, 9 Aug 2010, Raymond Dijkxhoorn wrote: > Woow this is fantactic news. Oh wait. Didnt Akamai invent this years > ago? I helped install my first Akamai cluster before year 2000 if I remember correctly. So it's at least a decade ago :P -- Mikael Abrahamsson email: swmike at swm.pp.se From lists at internetpolicyagency.com Mon Aug 9 03:34:17 2010 From: lists at internetpolicyagency.com (Roland Perry) Date: Mon, 9 Aug 2010 09:34:17 +0100 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: References: <5AC3E79A-392B-4D1B-BFC7-2700942FDC3C@ianai.net> <$4h4hQNoSDXMFA3R@perry.co.uk> <4C5E2A13.6000509@gmail.com> Message-ID: In article , Randy Bush writes >>> my memory is that he said doubling every nine months. >> Mine too. > >mo's too. i asked. This isn't just my recollection of what Mike said in 2001, the news item I quoted was printed in 2001. So even if it's a mistaken memory (of the late 90's), it was a mistaken memory captured in 2001. I mentioned it simply as a fairly contemporary reference to the meme. Having said that, doubling every 9 months was approximately the growth that LINX was seeing at the time. -- Roland Perry From graham at apolix.co.za Mon Aug 9 04:14:16 2010 From: graham at apolix.co.za (Graham Beneke) Date: Mon, 09 Aug 2010 11:14:16 +0200 Subject: Google wants your Internet to be faster In-Reply-To: References: <20100808232102.GA12802@root.ucsc.edu> Message-ID: <4C5FC6E8.3090303@apolix.co.za> On 09/08/2010 07:21, Mikael Abrahamsson wrote: > I helped install my first Akamai cluster before year 2000 if I remember > correctly. So it's at least a decade ago :P What I find funny is that Google has already been running these kinds of content distribution nodes in Africa for over a year. It makes a significant difference to the user experience when you reduced the RTT to the content servers by 200-400ms -- Graham Beneke From randy at psg.com Mon Aug 9 06:58:39 2010 From: randy at psg.com (Randy Bush) Date: Mon, 09 Aug 2010 04:58:39 -0700 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: References: <5AC3E79A-392B-4D1B-BFC7-2700942FDC3C@ianai.net> <$4h4hQNoSDXMFA3R@perry.co.uk> <4C5E2A13.6000509@gmail.com> Message-ID: while most of us seem to remember traffic doubling every nine months or a year (and some have memories of that being the meme then) [0], capacity build was massively above that level. think of the compound rate one gets when one substitutes owned wet glass for a few leased stm-1s. to quote a friend if a network's capacity grows O(10**6) in 6 years, measured in miles*gigabits/sec, how would you describe it? randy -- [0] - we're seeing about 50% broadband growth a year in japan according to thems that track, see Kenjiro Cho. "Broadband Traffic Report" Internet Infrastructure Review vol.4, pp18-23. August 2009. From stefan at nordu.net Mon Aug 9 09:01:59 2010 From: stefan at nordu.net (=?ISO-8859-1?Q?Stefan_Listr=F6m?=) Date: Mon, 09 Aug 2010 16:01:59 +0200 Subject: NOC Best Practices In-Reply-To: References: Message-ID: <4C600A57.8060801@nordu.net> Hello Kim I am also interested in NOC best practices, but have found out that it is not easy to find much documented on the subject. I think as most seem to have already answered in your thread, that is because every NOC is a little different from the other. Specially depending on the type of organisation or company they are working for. One of the things we have done in the research and educational community in Europe is to start a Task Force[1] on the topic. The task force has not really kicked off yet, so unfortunately we don't have any answers to your questions yet. I also guess your from a commercial company which might have a little different priorities than "we" do. That said, maybe looking at our questions and problems, might give you some food for thoughts in regards to what is important for your NOC. Following my link[2] below you can find our Terms of Reference. Basically what we are aiming to investigate and what we initially think is interesting to discuss in regards to a NOC. Not sure if it is helpful for you, but during our initial discussions around the task force we had some presentations about the NOC from different kinds of organisations. You can find the presentation slides on our meeting page[3]. If you are interested in ITIL and operations I can recommend the following two books: IT Service Management Based on ITIL V3, A Pocket Guide The Visible OPS Handbook, Implementing ITIL in 4 practical and auditable steps They are fairly easily read and make some good points. But if you consider implementing ITIL, be aware of the fact that it is easy to overcomplicating things. I would recommend starting out small and only use the things you think makes sense in regards to your organisation. Someone in this thread mentioned e-tom[4] which is published by TMForum. TMForum publish best practices in among other things operations, the downside is that you have to be a member to access most of their published documents. [1] http://www.terena.org/activities/tf-noc/ [2] http://www.terena.org/activities/tf-noc/tf-noc-tor_v3.pdf [3] http://www.terena.org/activities/tf-noc/prep/programme.html [4] http://www.tmforum.org/DocumentsBusiness/BusinessProcessFramework/35431/article.html Best regards Stefan On 2010-07-16 20:34, Kasper Adel wrote: > Thanks for all the people that replied off list, asking me to send them > responses i will get. > > I got nothing other than : > http://www.nanog.org/meetings/nanog24/abstracts.php?pt=OTM1Jm5hbm9nMjQ=&nm=nanog24 > and > > Network Management- Accounting and Performance Strategies - Just the first > three chapters > > Which is useful but i am looking for more stuff from the best people that > run the best NOCs in the world. > > So i'm throwing this out again. > > I am looking for pointers, suggestions, URLs, documents, donations on what a > professional NOC would have on the below topics: > > 1) Briefly, how they handle their own tickets with vendors or internal > 2) How they create a learning environment for their people (Documenting > Syslog, lessons learned from problems...etc) > 3) Shift to Shift hand over procedures > 4) Manual tests they start their day with and what they automate (common > stuff) > 5) Change management best practices and working with operations/engineering > when a change will be implemented > > Should i be looking for ITIL stuff or its not any good? > > Thanks, > Kim > > On Wed, Jul 14, 2010 at 8:24 PM, Kasper Adel wrote: > >> Hello Everyone, >> >> I am currently working on building a NOC so i'm looking for >> materials/pointers to Best Practices documented out there. >> >> On the top of my head are things like: >> >> 1) Documenting Incidents and handling them >> 2) Documenting Syslog messages >> 3) Documenting Vendor Software Bugs >> 4) Shift to Shift Hand over procedures >> 5) Commonly used scripts for monitoring >> 6) Frequently testing High Availability >> 7) Capturing config changes. >> ....etc >> >> I can see that this is years of experience but i am wondering if any of >> this was captured some where. >> >> Thanks, >> Kim >> From frank at fttx.org Mon Aug 9 10:01:12 2010 From: frank at fttx.org (Frank A. Coluccio) Date: Mon, 9 Aug 2010 08:01:12 -0700 Subject: off-topic: historical query concerning the Internet bubble Message-ID: <20100809080112.12211BFB@resin05.mta.everyone.net> re: Capacity ".... as measured by OC12-miles, doubles every four months..." Now that's a fascinating form of metric in itself. Distance * bit-rate equals capacity? What happened to the 'traffic' component? Likewise, what does this say regarding the various thresholds for refreshing bandwidth that individual operators have set as defaults, i.e., 20%, or 50%, or even 90%, before pulling the trigger and lighting up the next OC 'n'? Some providers tweaked 'n tuned their networks until the cows came home, others threw bandwidth 'lavishly' at the first inkling of the next plateau being reached. Even full disclosure by all Tier Ones concerning the number of OC-12 ports they were using, under these conditions, couldn't give an accurate picture of actual traffic levels being supported, IMO. --- odlyzko at umn.edu wrote: From: odlyzko at umn.edu (Andrew Odlyzko) To: randy at psg.com Cc: nanog at nanog.org Subject: Re: off-topic: historical query concerning the Internet bubble Date: Sun, 08 Aug 2010 08:30:44 -0500 Fascinating. Memories may be plastic (something that has been established scientifically), or else we may have yet another inconsistency to add to the pile of others. Is there any documentation about the "doubling every nine months"? I have never seen that particular claim emanating from anyone involved with WorldCom/UUNet. On the other hand, existing record shows (among others): 1. U.S. Department of Commerce white paper from April 1998, http://govinfo.library.unt.edu/ecommerce/EDEreprt.pdf on p. 8 declares that "UUNET, one of the largest Internet backbone providers, estimates that Internet traffic doubles every 100 days," with a reference to an Inktomi white paper that attributes this claim to Mike O'Dell. The Inktomi report is no longer on the Web, but I can provide a copy to anyone interested. 2. The transcript of the May 2000 presentation by O'Dell at a Stanford conference clearly has him saying that the capacity of the UUNet network, as measured by OC12-miles, doubles every four months, http://www.dtc.umn.edu/~odlyzko/isources/odell-transcript.txt As is explained in my paper, in the 1998-2000 time frame, essentially all the WorldCom/UUNet claims then seemed to be about capacity, not traffic. 3. The year-end 2000 email from O'Dell to Dave Farber's IP list, http://www.interesting-people.org/archives/interesting-people/200011/ms g00058.html has him talking of traffic doubling each year, while capacity grows 8-fold. If some time in that period there was a claim of a "doubling every nine months," too, that would be very interesting. Andrew Randy Bush wrote: > >> my memory is that he said doubling every nine months. > > Mine too. > > mo's too. i asked. > > randy From morrowc.lists at gmail.com Mon Aug 9 10:12:14 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 9 Aug 2010 11:12:14 -0400 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: <20100805222706.GJ63440@blackrose.org> References: <20100805222706.GJ63440@blackrose.org> Message-ID: On Thu, Aug 5, 2010 at 6:27 PM, Dorian Kim wrote: > Was Mike O'Dell's famous doubling every 100 days just a myth? > Like any good tale, there most likely was an element of truth > behind it. I think, from another list about 2 yrs ago, the person responsible for this data inside the company at the time (now not there) said someone misinterpreted his stats/numbers... -chris From Valdis.Kletnieks at vt.edu Mon Aug 9 10:32:09 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 09 Aug 2010 11:32:09 -0400 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: Your message of "Mon, 09 Aug 2010 08:01:12 PDT." <20100809080112.12211BFB@resin05.mta.everyone.net> References: <20100809080112.12211BFB@resin05.mta.everyone.net> Message-ID: <144011.1281367929@localhost> On Mon, 09 Aug 2010 08:01:12 PDT, "Frank A. Coluccio" said: > re: > Capacity ".... as measured by OC12-miles, > doubles every four months..." > Now that's a fascinating form of metric in itself. > Distance * bit-rate equals capacity? What happened > to the 'traffic' component? It's a measure of *capacity*, not traffic. If you string up 1 1GE line or a bundle of 24 100GE, that's the *capacity* of the path, even if there's only 600 mbits/sec actually flowing. Remember your car's gas tank only hold 17.6 gallons of gas, whether you drive enough that you buy gas every Monday and Thursday, or so little you only buy gas on the 3rd of every month. And adding miles as a component has its uses - stringing an OC-12 across a meet-me room is less of a challenge than lighting up a Boston-San Diego link. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From fweimer at bfk.de Mon Aug 9 11:32:21 2010 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 09 Aug 2010 16:32:21 +0000 Subject: Google wants your Internet to be faster In-Reply-To: <4C5FC6E8.3090303@apolix.co.za> (Graham Beneke's message of "Mon\, 09 Aug 2010 11\:14\:16 +0200") References: <20100808232102.GA12802@root.ucsc.edu> <4C5FC6E8.3090303@apolix.co.za> Message-ID: <82lj8fn3vu.fsf@mid.bfk.de> * Graham Beneke: > On 09/08/2010 07:21, Mikael Abrahamsson wrote: >> I helped install my first Akamai cluster before year 2000 if I remember >> correctly. So it's at least a decade ago :P > > What I find funny is that Google has already been running these kinds > of content distribution nodes in Africa for over a year. They certainly have got infrastructure all over the globe. The Verizon is probably just a private peering agreement, and someone misinterpreted that (or deliberately misrepresented it). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From nick at foobar.org Mon Aug 9 11:45:51 2010 From: nick at foobar.org (Nick Hilliard) Date: Mon, 09 Aug 2010 17:45:51 +0100 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: References: <20100805222706.GJ63440@blackrose.org> Message-ID: <4C6030BF.1030306@foobar.org> On 09/08/2010 16:12, Christopher Morrow wrote: > I think, from another list about 2 yrs ago, the person responsible for > this data inside the company at the time (now not there) said someone > misinterpreted his stats/numbers... No doubt this is true. And I note we haven't even started discussing whether this "doubling every N time periods" refers to bit-rate, bytes passed or daily max. I would have said that most networks during that period had occasional burst growth rates of up to 100% within 100 days. The growth curve second derivative is usually much bumpier than the first derivative. So, regardless of source, the quotation is a truism, an urban myth and ultimately means very little. Nick From andy at nosignal.org Mon Aug 9 12:43:13 2010 From: andy at nosignal.org (Andy Davidson) Date: Mon, 9 Aug 2010 18:43:13 +0100 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: References: <5AC3E79A-392B-4D1B-BFC7-2700942FDC3C@ianai.net> <$4h4hQNoSDXMFA3R@perry.co.uk> Message-ID: On 7 Aug 2010, at 18:09, Roland Perry didn't exactly write: > 'a good rule of thumb during the late 1990's was that traffic doubled every 100 days' This is the West, sir. When the legend becomes fact, print the legend. To the original poster, there is another collection of memes (some might even/one day be true) on the 'Future of the Internet' lecture series, on Stanford's 'iTunes U' area - lecture 3 is on Internet Economics and touches on the history of this (mis?)-quote ? Best wishes Andy From chaim.rieger at gmail.com Mon Aug 9 12:43:14 2010 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Mon, 9 Aug 2010 10:43:14 -0700 Subject: Google wants your Internet to be faster In-Reply-To: <82lj8fn3vu.fsf@mid.bfk.de> References: <20100808232102.GA12802@root.ucsc.edu> <4C5FC6E8.3090303@apolix.co.za> <82lj8fn3vu.fsf@mid.bfk.de> Message-ID: WSJ has live updates on the google - verizon release http://blogs.wsj.com/digits/2010/08/09/live-blogging-the-google-verizon-net-neutrality-announcement/ From reese at inkworkswell.com Mon Aug 9 13:23:46 2010 From: reese at inkworkswell.com (Reese) Date: Mon, 09 Aug 2010 14:23:46 -0400 Subject: Google wants your Internet to be faster In-Reply-To: <82lj8fn3vu.fsf@mid.bfk.de> References: <20100808232102.GA12802@root.ucsc.edu> <4C5FC6E8.3090303@apolix.co.za> <82lj8fn3vu.fsf@mid.bfk.de> Message-ID: <4C6047B2.9050107@inkworkswell.com> On 09 Aug 10 12:32 PM, Florian Weimer wrote: > * Graham Beneke: > >> On 09/08/2010 07:21, Mikael Abrahamsson wrote: >>> I helped install my first Akamai cluster before year 2000 if I remember >>> correctly. So it's at least a decade ago :P >> >> What I find funny is that Google has already been running these kinds >> of content distribution nodes in Africa for over a year. > > They certainly have got infrastructure all over the globe. Hmmm. "If it plays in [insert name of locale in Africa]" will not have the same ring as "Peoria." For the older genset anyway. Maybe if it rhymes? Spoken to a musical backdrop? The current crop of youts will not hesitate once. > The Verizon is probably just a private peering agreement, and someone > misinterpreted that (or deliberately misrepresented it). Or it was supposed to be a secret. G was still denying any sort of agreement with V, last I heard. Reese From jason.iannone at gmail.com Mon Aug 9 13:46:50 2010 From: jason.iannone at gmail.com (Jason Iannone) Date: Mon, 9 Aug 2010 12:46:50 -0600 Subject: Google wants your Internet to be faster In-Reply-To: <4C6047B2.9050107@inkworkswell.com> References: <20100808232102.GA12802@root.ucsc.edu> <4C5FC6E8.3090303@apolix.co.za> <82lj8fn3vu.fsf@mid.bfk.de> <4C6047B2.9050107@inkworkswell.com> Message-ID: http://googlepublicpolicy.blogspot.com/2010/08/joint-policy-proposal-for-open-internet.html Pretty boiler plate pro net neutral. The transparency requirements and 'differentiated services' exceptions are particularly interesting. On Mon, Aug 9, 2010 at 12:23 PM, Reese wrote: > On 09 Aug 10 12:32 PM, Florian Weimer wrote: >> >> * Graham Beneke: >> >>> On 09/08/2010 07:21, Mikael Abrahamsson wrote: >>>> >>>> I helped install my first Akamai cluster before year 2000 if I remember >>>> correctly. So it's at least a decade ago :P >>> >>> What I find funny is that Google has already been running these kinds >>> of content distribution nodes in Africa for over a year. >> >> They certainly have got infrastructure all over the globe. > > Hmmm. "If it plays in [insert name of locale in Africa]" will not have > the same ring as "Peoria." For the older genset anyway. Maybe if it rhymes? > Spoken to a musical backdrop? The current crop of youts will > not hesitate once. > >> The Verizon is probably just a private peering agreement, and someone >> misinterpreted that (or deliberately misrepresented it). > > Or it was supposed to be a secret. G was still denying any sort of > agreement with V, last I heard. > > Reese > > > > > > From joly at punkcast.com Mon Aug 9 13:52:22 2010 From: joly at punkcast.com (Joly MacFie) Date: Mon, 9 Aug 2010 14:52:22 -0400 Subject: Google wants your Internet to be faster In-Reply-To: References: <20100808232102.GA12802@root.ucsc.edu> <4C5FC6E8.3090303@apolix.co.za> <82lj8fn3vu.fsf@mid.bfk.de> <4C6047B2.9050107@inkworkswell.com> Message-ID: Surely "differentiated services" could include a 'YouTube Channel' - something they deny in the call? I've blogged the proposal at http://www.isoc-ny.org/p2/?p=1112 j On Mon, Aug 9, 2010 at 2:46 PM, Jason Iannone wrote: > > http://googlepublicpolicy.blogspot.com/2010/08/joint-policy-proposal-for-open-internet.html > > Pretty boiler plate pro net neutral. The transparency requirements > and 'differentiated services' exceptions are particularly interesting. > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com Secretary - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From zaid at zaidali.com Mon Aug 9 14:18:12 2010 From: zaid at zaidali.com (Zaid Ali) Date: Mon, 09 Aug 2010 12:18:12 -0700 Subject: Google wants your Internet to be faster In-Reply-To: Message-ID: The devil is always in the details. The Network management piece is quite glossed over and gives a different perception in the summary. You can't perform the proposed network management piece without deep packet inspection which violates every users privacy. Zaid On 8/9/10 11:52 AM, "Joly MacFie" wrote: > Surely "differentiated services" could include a 'YouTube Channel' - > something they deny in the call? > > I've blogged the proposal at http://www.isoc-ny.org/p2/?p=1112 > > j > > On Mon, Aug 9, 2010 at 2:46 PM, Jason Iannone wrote: > >> >> http://googlepublicpolicy.blogspot.com/2010/08/joint-policy-proposal-for-open >> -internet.html >> >> Pretty boiler plate pro net neutral. The transparency requirements >> and 'differentiated services' exceptions are particularly interesting. >> >> From joly at punkcast.com Mon Aug 9 14:29:46 2010 From: joly at punkcast.com (Joly MacFie) Date: Mon, 9 Aug 2010 15:29:46 -0400 Subject: Google wants your Internet to be faster In-Reply-To: References: Message-ID: Nor ensure 'lawful' content On Mon, Aug 9, 2010 at 3:18 PM, Zaid Ali wrote: > The devil is always in the details. The Network management piece is quite > glossed over and gives a different perception in the summary. You can't > perform the proposed network management piece without deep packet > inspection > which violates every users privacy. > > Zaid > > > On 8/9/10 11:52 AM, "Joly MacFie" wrote: > > > Surely "differentiated services" could include a 'YouTube Channel' - > > something they deny in the call? > > > > I've blogged the proposal at http://www.isoc-ny.org/p2/?p=1112 > > > > j > > > > On Mon, Aug 9, 2010 at 2:46 PM, Jason Iannone >wrote: > > > >> > >> > http://googlepublicpolicy.blogspot.com/2010/08/joint-policy-proposal-for-open > >> -internet.html > >> > >> Pretty boiler plate pro net neutral. The transparency requirements > >> and 'differentiated services' exceptions are particularly interesting. > >> > >> > > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com Secretary - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From Valdis.Kletnieks at vt.edu Mon Aug 9 14:46:41 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 09 Aug 2010 15:46:41 -0400 Subject: Google wants your Internet to be faster In-Reply-To: Your message of "Mon, 09 Aug 2010 15:29:46 EDT." References: Message-ID: <8590.1281383201@localhost> On Mon, 09 Aug 2010 15:29:46 EDT, Joly MacFie said: > Nor ensure 'lawful' content Do you *really* want to go there? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From lists at internetpolicyagency.com Mon Aug 9 15:29:12 2010 From: lists at internetpolicyagency.com (Roland Perry) Date: Mon, 9 Aug 2010 21:29:12 +0100 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: <4C6030BF.1030306@foobar.org> References: <20100805222706.GJ63440@blackrose.org> <4C6030BF.1030306@foobar.org> Message-ID: In article <4C6030BF.1030306 at foobar.org>, Nick Hilliard writes >On 09/08/2010 16:12, Christopher Morrow wrote: >> I think, from another list about 2 yrs ago, the person responsible for >> this data inside the company at the time (now not there) said someone >> misinterpreted his stats/numbers... > >No doubt this is true. And I note we haven't even started discussing >whether this "doubling every N time periods" refers to bit-rate, bytes >passed or daily max. In the case of LINX traffic it was bits-per-second; any of: average, peak or total per day, because the shape of the daily and weekly curve didn't change much even over a period of years. >I would have said that most networks during that period had occasional >burst growth rates of up to 100% within 100 days. The growth curve >second derivative is usually much bumpier than the first derivative. >So, regardless of source, the quotation is a truism, an urban myth and >ultimately means very little. Growth at LINX was extremely steady (being an aggregate of over a hundred operators). -- Roland Perry From mpalmer at hezmatt.org Mon Aug 9 16:30:27 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Tue, 10 Aug 2010 07:30:27 +1000 Subject: Google wants your Internet to be faster In-Reply-To: References: Message-ID: <20100809213027.GF12712@hezmatt.org> On Mon, Aug 09, 2010 at 12:18:12PM -0700, Zaid Ali wrote: > The devil is always in the details. The Network management piece is quite > glossed over and gives a different perception in the summary. You can't > perform the proposed network management piece without deep packet inspection > which violates every users privacy. This is Google we're talking about here, though. - Matt -- MySQL seems to be the Windows of the database world. Broken, underspecced, and mainly only popular due to inertia and people who don't really know what they're doing. -- Peter Corlett, in the Monastery From kenny.sallee at gmail.com Mon Aug 9 18:01:00 2010 From: kenny.sallee at gmail.com (Kenny Sallee) Date: Mon, 9 Aug 2010 16:01:00 -0700 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: <604794.12749.qm@web53002.mail.re2.yahoo.com> References: <604794.12749.qm@web53002.mail.re2.yahoo.com> Message-ID: On Fri, Aug 6, 2010 at 2:52 PM, Jessica Yu wrote: > > I do not know if making such distinction would alter the conclusion of your > paper. But, to me, there is a difference between one to predict the growth > of > one particular network based on the stats collected than one to predict the > growth of the entire Internet with no solid data. > Thanks!--Jessica > Agree with Jessica: you can't say the 'Internet' doubles every x number of days/amount of time no matter what the number of days or amount of time is. The 'Internet' is a series of tubes...hahaha couldn't help it....As we all know the Internet is a bunch of providers plugged into each other. Provider A may see an 10x increase in traffic every month while provider B may not. For example, if Google makes a deal with Verizon only Verizon will see a huge increase in traffic internally and less externally (or vice versa). Until Google goes somewhere else! So the whole 'myth' of Internet doubling every 100 days to me is something someone (ODell it seems) made up to appease someone higher in the chain or a government committee that really doesn't get it. IE - it's marketing talk to quantify something. I guess if all the ISP's in the world provided a central repository bandwidth numbers they have on their backbone then you could make up some stats about Internet traffic as a whole. But without that - it just doesn't make much sense. Just my .02 Kenny From courtneysmith at comcast.net Mon Aug 9 18:01:04 2010 From: courtneysmith at comcast.net (courtneysmith at comcast.net) Date: Mon, 9 Aug 2010 23:01:04 +0000 (UTC) Subject: Looking for a Illinois Century Network(AS6325) contact Message-ID: <1413372419.1040873.1281394864985.JavaMail.root@sz0003a.westchester.pa.mail.comcast.net> Looking for a network engineering contact at ICN(AS6325). I'm trying to find out if they have BGP communities for their customers to use. Please reply off list. Thanks. From matthew at walster.org Mon Aug 9 19:30:05 2010 From: matthew at walster.org (Matthew Walster) Date: Tue, 10 Aug 2010 01:30:05 +0100 Subject: Proxy Server In-Reply-To: References: <8C26A4FDAE599041A13EB499117D3C2816470D07@ex-mb-1.corp.atlasnetworks.us> Message-ID: On 6 August 2010 22:04, Owen DeLong wrote: > Apparently it can be made to work: Indeed, I used the above instructions to setup IPv6 on my home pfSense box, with the upstream being a HurricaneElectric v6v4 tunnel. It worked very well - though it only worked with RA, there's obviously no dhcp6 implementation installed/supported. M From jason at lixfeld.ca Mon Aug 9 19:48:15 2010 From: jason at lixfeld.ca (Jason Lixfeld) Date: Mon, 9 Aug 2010 20:48:15 -0400 Subject: Example RFI for colo provider selection Message-ID: I'm researching a list of some colocation providers I have here to find the most suitable one to provide services for a project I'm working on. My thought is to send out an informal RFI, which I believe is something others may have done too. If anyone is able to share, I'd be interested in having a peek at some of these colo-centric RFIs to understand what questions others have asked in the past, as it may help me come up with some questions that I may not have thought of myself. If an RFI isn't an appropriate means to gather information on such a prospect, I'd certainly like to hear that too. Thanks in advance. PS. To any reader who may be thinking this is an open invitation for a sales email, it's not :) From sethm at rollernet.us Mon Aug 9 20:39:19 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 09 Aug 2010 18:39:19 -0700 Subject: Example RFI for colo provider selection In-Reply-To: References: Message-ID: <4C60ADC7.3070405@rollernet.us> On 8/9/2010 17:48, Jason Lixfeld wrote: > I'm researching a list of some colocation providers I have here to find the most suitable one to provide services for a project I'm working on. My thought is to send out an informal RFI, which I believe is something others may have done too. If anyone is able to share, I'd be interested in having a peek at some of these colo-centric RFIs to understand what questions others have asked in the past, as it may help me come up with some questions that I may not have thought of myself. > > If an RFI isn't an appropriate means to gather information on such a prospect, I'd certainly like to hear that too. > > Thanks in advance. > > PS. To any reader who may be thinking this is an open invitation for a sales email, it's not :) Pretty much every first contact I see is along the lines of "I have the following requirements X, Y, and Z. Please provide a quote to suit these." The format of these may vary wildly. As far as questions to ask, IPv6 is always on the top of my list but almost always makes the viable prospects list pretty slim. Power *type* availability is often overlooked (i.e. 208 volts or three-phase) until the fateful day you need more than single phase 120 to run something and the colo says oops not available. ~Seth From randy at psg.com Mon Aug 9 21:46:39 2010 From: randy at psg.com (Randy Bush) Date: Mon, 09 Aug 2010 19:46:39 -0700 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: <20100809080112.12211BFB@resin05.mta.everyone.net> References: <20100809080112.12211BFB@resin05.mta.everyone.net> Message-ID: > Distance * bit-rate equals capacity? What happened to the 'traffic' > component? traffic is not a component of capacity. capicity is an upper bound on traffic. randy From morrowc.lists at gmail.com Mon Aug 9 22:29:53 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 9 Aug 2010 23:29:53 -0400 Subject: Google wants your Internet to be faster In-Reply-To: References: Message-ID: On Mon, Aug 9, 2010 at 3:18 PM, Zaid Ali wrote: > The devil is always in the details. The Network management piece is quite > glossed over and gives a different perception in the summary. You can't > perform the proposed network management piece without deep packet inspection > which violates every users privacy. how is that though? you COULD do something odd like say: "Anything to zaid-ali's netblocks is preferred in queues over things to jolymacfie's netblocks. that wouldn't require any DPI at all, just a traffic classification engine on/near the endpoint, say like on the DocSIS modem, or on the handset itself... many handsets are unix-ish things with some ability to do 'firewall' things, certainly they could mark packets outbound, certainly at peering points a network could classify in simple ways and mark packets properly there as well. nothing required DPI, unless you want to delve into: "That is not ssh on port 22" port 443 is the new port 80! woot! -chris From mansaxel at besserwisser.org Tue Aug 10 01:37:13 2010 From: mansaxel at besserwisser.org (Mans Nilsson) Date: Tue, 10 Aug 2010 08:37:13 +0200 Subject: Example RFI for colo provider selection In-Reply-To: References: Message-ID: <20100810063713.GR14173@besserwisser.org> Subject: Example RFI for colo provider selection Date: Mon, Aug 09, 2010 at 08:48:15PM -0400 Quoting Jason Lixfeld (jason at lixfeld.ca): > I'm researching a list of some colocation providers I have here to find the most suitable one to provide services for a project I'm working on. My thought is to send out an informal RFI, which I believe is something others may have done too. If anyone is able to share, I'd be interested in having a peek at some of these colo-centric RFIs to understand what questions others have asked in the past, as it may help me come up with some questions that I may not have thought of myself. * Most overlooked: Does the backup power system cope with the cooling power requirements? * Several fiber providers connecting the facility, or one heavily multi-pathed. * If you intend to buy transit, number of (and perhaps prefered) transit providers. * If you intend to make your own IP-infrastructure, which transmission providers are present? * Space to grow, price. (ie. where do I leave the underpriced introductory offer and go into more expensive list-price setups) * Power, as previously mentioned. Three-phase is IMNSHO a must. But, then, I'm from Yoorp. In power, several subtopics: - Dual circuits, independently UPS-backed. - Generator backup. - Frequency of full-scale and load tests of power backup systems. Anything less than load test several times per year and at least one full-scale axe-in-mains-feeder -type test per year means that the "Diesel promise" is a lie. - They should have monitoring and trend watching systems set up to stop accepting new customers once any UPS is at 50% of rated load (What happens when one UPS side commits seppuku and fails to bypass?) - Power protection systems, for overvoltage, spikes, thunderstorms, etc. More could be added and has been. My 0,05 ?, this. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I want a VEGETARIAN BURRITO to go ... with EXTRA MSG!! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From lists at internetpolicyagency.com Tue Aug 10 02:56:46 2010 From: lists at internetpolicyagency.com (Roland Perry) Date: Tue, 10 Aug 2010 08:56:46 +0100 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: References: <604794.12749.qm@web53002.mail.re2.yahoo.com> Message-ID: In article , Kenny Sallee writes >So the whole 'myth' of Internet doubling every 100 days to me is >something someone (ODell it seems) made up to appease someone higher in >the chain or a government committee that really doesn't get it. [Whether it was really 100 days, or 200 days...] a statistic like this has very real operational significance, because it sets expectations in the minds of senior management and investors that the new shiny hardware (or leased line, or peering agreement...) you just put in place isn't going to last "a lifetime", and will need replacing/upgrading really quite soon. Another meme at the time (at least in the UK) was the idea of "Internet Time", where things happened four times as fast as "real life". So you'd realise that things like a "five year plan" were really only going to last just over a year. And, of course, policy and law related to the Internet gets out of date four times as fast, too. -- Roland Perry From kandby at aviso.ci Tue Aug 10 04:11:51 2010 From: kandby at aviso.ci (KANDE Baya) Date: Tue, 10 Aug 2010 09:11:51 -0000 Subject: Send NANOG mailing list submissions Message-ID: <000901cb386c$12433950$36c9abf0$@ci> From sean at donelan.com Tue Aug 10 06:35:35 2010 From: sean at donelan.com (Sean Donelan) Date: Tue, 10 Aug 2010 07:35:35 -0400 (EDT) Subject: Google wants your Internet to be faster In-Reply-To: References: Message-ID: On Mon, 9 Aug 2010, Christopher Morrow wrote: > On Mon, Aug 9, 2010 at 3:18 PM, Zaid Ali wrote: >> The devil is always in the details. The Network management piece is quite >> glossed over and gives a different perception in the summary. You can't >> perform the proposed network management piece without deep packet inspection >> which violates every users privacy. > > how is that though? you COULD do something odd like say: "Anything to > zaid-ali's netblocks is preferred in queues over things to > jolymacfie's netblocks. that wouldn't require any DPI at all, just a > traffic classification engine on/near the endpoint, say like on the > DocSIS modem, or on the handset itself... many handsets are unix-ish > things with some ability to do 'firewall' things, certainly they could > mark packets outbound, certainly at peering points a network could > classify in simple ways and mark packets properly there as well. Or even simplier, sell seperate TDM circuits. Although some people think there is only a single network, Internet; in practice the Internet has always been just one of many different networks built on top of various telecommunication facilities. Is there a performance difference between the Internet and Internet2? Should that be allowed, or must all IP networks have the same performance? From nathan at atlasnetworks.us Tue Aug 10 11:36:44 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Tue, 10 Aug 2010 16:36:44 +0000 Subject: Google wants your Internet to be faster In-Reply-To: References: Message-ID: <8C26A4FDAE599041A13EB499117D3C28164758A4@ex-mb-1.corp.atlasnetworks.us> > Is there a performance difference between the Internet and Internet2? > Should that be allowed, or must all IP networks have the same > performance? I think that statement may confuse metrics like performance and capacity, with the action of intentionally QOS'ing Netflix over Youtube over the same uplink. One is a reality, and one offers disturbing possibilities. Best Regards, Nathan Eisenberg From kenny.sallee at gmail.com Tue Aug 10 11:49:54 2010 From: kenny.sallee at gmail.com (Kenny Sallee) Date: Tue, 10 Aug 2010 09:49:54 -0700 Subject: Google wants your Internet to be faster In-Reply-To: <8C26A4FDAE599041A13EB499117D3C28164758A4@ex-mb-1.corp.atlasnetworks.us> References: <8C26A4FDAE599041A13EB499117D3C28164758A4@ex-mb-1.corp.atlasnetworks.us> Message-ID: On Tue, Aug 10, 2010 at 9:36 AM, Nathan Eisenberg wrote: > > Is there a performance difference between the Internet and Internet2? > > Should that be allowed, or must all IP networks have the same > > performance? > > I think that statement may confuse metrics like performance and capacity, > with the action of intentionally QOS'ing Netflix over Youtube over the same > uplink. One is a reality, and one offers disturbing possibilities. > > Best Regards, > Nathan Eisenberg > > > Maybe the ISP's should move this choice to the consumer. The last mile is 'usually' where congestion really hits. Why not build a portal for consumers to go in an choose what's important to them? I know some MPLS VPN providers do something similar (have a portal businesses can use to view and modify QoS settings). I'd love to be able to prioritize Netflix over youtube or bittorrent or whatever games my kids are playing since I mainly use Netflix to watch movies. But I wouldn't like the big guys dictating what is important to me. From mike at sabbota.com Tue Aug 10 12:02:30 2010 From: mike at sabbota.com (Mike Sabbota) Date: Tue, 10 Aug 2010 11:02:30 -0600 Subject: Google wants your Internet to be faster In-Reply-To: References: <8C26A4FDAE599041A13EB499117D3C28164758A4@ex-mb-1.corp.atlasnetworks.us> Message-ID: I don't see providers ever pushing it that far down the stream. Would you be willing to pay more for your consumer connection to maintain those types of features? Business connections, absolutely. It's really about controlling bandwidth on the shared link, not your individual home connection. So for connectivity feeding a neighborhood or apartment building the question arises do you allow multiple users to use all of the bandwidth for P2P and crowd out your Netflix traffic? The question is should Netflix have to pay more to ensure quality service to their streaming subscribers? I view this exercise as paying for priority when the circuit is full -- like a special carpool lane. It's not like the provider will randomly send you traffic you don't want. If Netflix sucks do you blame your provider or Netflix? In the end, do you switch providers or cancel Netflix? My guess is most consumers will cancel Netflix before they switch their Internet provider. Not saying that this can't be abused by providers not having in enough capacity and content companies bidding to be most important on the circuit. On Tue, Aug 10, 2010 at 10:49 AM, Kenny Sallee wrote: > On Tue, Aug 10, 2010 at 9:36 AM, Nathan Eisenberg > wrote: > > > > Is there a performance difference between the Internet and Internet2? > > > Should that be allowed, or must all IP networks have the same > > > performance? > > > > I think that statement may confuse metrics like performance and capacity, > > with the action of intentionally QOS'ing Netflix over Youtube over the > same > > uplink. One is a reality, and one offers disturbing possibilities. > > > > Best Regards, > > Nathan Eisenberg > > > > > > > Maybe the ISP's should move this choice to the consumer. The last mile is > 'usually' where congestion really hits. Why not build a portal for > consumers to go in an choose what's important to them? I know some MPLS > VPN > providers do something similar (have a portal businesses can use to view > and > modify QoS settings). I'd love to be able to prioritize Netflix over > youtube or bittorrent or whatever games my kids are playing since I mainly > use Netflix to watch movies. But I wouldn't like the big guys dictating > what is important to me. > From morrowc.lists at gmail.com Tue Aug 10 12:03:52 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 10 Aug 2010 13:03:52 -0400 Subject: Google wants your Internet to be faster In-Reply-To: References: <8C26A4FDAE599041A13EB499117D3C28164758A4@ex-mb-1.corp.atlasnetworks.us> Message-ID: On Tue, Aug 10, 2010 at 12:49 PM, Kenny Sallee wrote: > Maybe the ISP's should move this choice to the consumer. ?The last mile is > 'usually' where congestion really hits. ?Why not build a portal for > consumers to go in an choose what's important to them? ?I know some MPLS VPN > providers do something similar (have a portal businesses can use to view and verizon-business was hot-to-trot to do this when I left (3yrs or so) I understand it's more a reality now than then. I also hear there is a decent competitor to BT in the UK (which I'll say is IPPlus and be wrong about since that's swisscom I think) that does this for consumers, something about letting the consumer choose to always keep their pipe full, but useful to them. Apparently they employ some dpi-type devices and have very good reviews from customers... > modify QoS settings). ?I'd love to be able to prioritize Netflix over > youtube or bittorrent or whatever games my kids are playing since I mainly > use Netflix to watch movies. ?But I wouldn't like the big guys dictating > what is important to me. so you'd like to foist the problem off to the provider (cost/configuration) and benefit? Are you willing to pay some incrementally higher charge per month for that service? what about for security services? Do you think there are enough folks willing to pay for this sort of thing that it'd make a decent business to be in? -Chris From nathan at atlasnetworks.us Tue Aug 10 12:29:37 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Tue, 10 Aug 2010 17:29:37 +0000 Subject: Google wants your Internet to be faster In-Reply-To: References: <8C26A4FDAE599041A13EB499117D3C28164758A4@ex-mb-1.corp.atlasnetworks.us> Message-ID: <8C26A4FDAE599041A13EB499117D3C2816475A42@ex-mb-1.corp.atlasnetworks.us> > Maybe the ISP's should move this choice to the consumer. ? The consumer already has this option on many SOHO firewalls. No action by ISPs is required. But this is totally irrelevant to the idea of Net Neutrality. > I view this exercise as paying for priority when the circuit is full -- like a special carpool lane. Carrier circuits should never be 'full', unless your definition of 'full' is 50-70%, IMHO. 100% full is a failure of engineering, business planning, and monitoring. Priority shouldn't be required. Best Regards, Nathan Eisenberg From kenny.sallee at gmail.com Tue Aug 10 12:54:34 2010 From: kenny.sallee at gmail.com (Kenny Sallee) Date: Tue, 10 Aug 2010 10:54:34 -0700 Subject: Google wants your Internet to be faster In-Reply-To: References: <8C26A4FDAE599041A13EB499117D3C28164758A4@ex-mb-1.corp.atlasnetworks.us> Message-ID: so you'd like to foist the problem off to the provider > (cost/configuration) and benefit? Are you willing to pay some > incrementally higher charge per month for that service? what about for > security services? Do you think there are enough folks willing to pay > for this sort of thing that it'd make a decent business to be in? > > -Chris > Yes I would pay more to ensure the apps I care about work. I don't think I would for security services however. I think that other consumers may - if an SP could actually provide it (and prove what they are providing is doing something). From hhoffman at ip-solutions.net Tue Aug 10 13:00:19 2010 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Tue, 10 Aug 2010 14:00:19 -0400 Subject: Google wants your Internet to be faster In-Reply-To: <8590.1281383201@localhost> References: <8590.1281383201@localhost> Message-ID: <1281463219.15560.76.camel@n1-20-152.dhcp.drexel.edu> Heh, well is seems like one of the PIRGs is joining the fray, at least in PA: http://www.pennpirg.org/action/google?id4=es On Mon, 2010-08-09 at 15:46 -0400, Valdis.Kletnieks at vt.edu wrote: > On Mon, 09 Aug 2010 15:29:46 EDT, Joly MacFie said: > > Nor ensure 'lawful' content > > Do you *really* want to go there? From kenny.sallee at gmail.com Tue Aug 10 13:05:11 2010 From: kenny.sallee at gmail.com (Kenny Sallee) Date: Tue, 10 Aug 2010 11:05:11 -0700 Subject: Google wants your Internet to be faster In-Reply-To: <8C26A4FDAE599041A13EB499117D3C2816475A42@ex-mb-1.corp.atlasnetworks.us> References: <8C26A4FDAE599041A13EB499117D3C28164758A4@ex-mb-1.corp.atlasnetworks.us> <8C26A4FDAE599041A13EB499117D3C2816475A42@ex-mb-1.corp.atlasnetworks.us> Message-ID: On Tue, Aug 10, 2010 at 10:29 AM, Nathan Eisenberg wrote: > > Maybe the ISP's should move this choice to the consumer. > > The consumer already has this option on many SOHO firewalls. No action by > ISPs is required. But this is totally irrelevant to the idea of Net > Neutrality. > > Yes - but you can only traffic shape / prioritize so much after the data has reached your end of a circuit / connection. So yes those SOHO devices do it - but if you look on the wire - you'll see more actual bandwidth making it across then you are expecting. The SOHO devices are just buffering / dropping stuff / manipulating TCP flows to slow unimportant stuff down. It's a better solution to do this on the provider side > > I view this exercise as paying for priority when the circuit is full -- > like a special carpool lane. > > Carrier circuits should never be 'full', unless your definition of 'full' > is 50-70%, IMHO. 100% full is a failure of engineering, business planning, > and monitoring. Priority shouldn't be required. > > True - but we are not talking about carrier circuits in the core. Agree with your statements regarding core carrier circuits. We are talking about the 'last mile' DSL/Cable/Fiber connection into your house. My bandwidth is pegged everytime I download a new version of Linux from bittorrent. During that time - my VoIP and Netflix have issues. > Best Regards, > Nathan Eisenberg > > From justin.horstman at gorillanation.com Tue Aug 10 13:54:12 2010 From: justin.horstman at gorillanation.com (Justin Horstman) Date: Tue, 10 Aug 2010 11:54:12 -0700 Subject: Google wants your Internet to be faster In-Reply-To: <1281463219.15560.76.camel@n1-20-152.dhcp.drexel.edu> References: <8590.1281383201@localhost> <1281463219.15560.76.camel@n1-20-152.dhcp.drexel.edu> Message-ID: <8C164D3BAF7C7F41B9B286385037B13102C3EDF522@lax-exch-fe-01.gorillanation.local> That link is silly, and completely opposite to what they said.... -----Original Message----- From: Harry Hoffman [mailto:hhoffman at ip-solutions.net] Sent: Tuesday, August 10, 2010 11:00 AM To: Valdis.Kletnieks at vt.edu Cc: nanog at nanog.org Subject: Re: Google wants your Internet to be faster Heh, well is seems like one of the PIRGs is joining the fray, at least in PA: http://www.pennpirg.org/action/google?id4=es On Mon, 2010-08-09 at 15:46 -0400, Valdis.Kletnieks at vt.edu wrote: > On Mon, 09 Aug 2010 15:29:46 EDT, Joly MacFie said: > > Nor ensure 'lawful' content > > Do you *really* want to go there? From oberman at es.net Tue Aug 10 14:58:15 2010 From: oberman at es.net (Kevin Oberman) Date: Tue, 10 Aug 2010 12:58:15 -0700 Subject: Google wants your Internet to be faster In-Reply-To: Your message of "Tue, 10 Aug 2010 11:54:12 PDT." <8C164D3BAF7C7F41B9B286385037B13102C3EDF522@lax-exch-fe-01.gorillanation.local> Message-ID: <20100810195815.CD1591CC3A@ptavv.es.net> It makes the thread very hard to follow. > Why not? > > Please don't top post! > From: Justin Horstman > Date: Tue, 10 Aug 2010 11:54:12 -0700 > > That link is silly, and completely opposite to what they said.... > > -----Original Message----- > From: Harry Hoffman [mailto:hhoffman at ip-solutions.net] > Sent: Tuesday, August 10, 2010 11:00 AM > To: Valdis.Kletnieks at vt.edu > Cc: nanog at nanog.org > Subject: Re: Google wants your Internet to be faster > > Heh, well is seems like one of the PIRGs is joining the fray, at least > in PA: > > http://www.pennpirg.org/action/google?id4=es > The NY Times article has little to nothing to do with reality and it was bad of PennPIRG to cite that bit of twaddle. That said, the actual, published document has some huge issues. It pays excellent lip service to net neutrality, but it has simply HUGE loopholes with lots of weasel words that could be used to get away with most anything. for example, it expressly excludes and wireless network. It is being widely interpreted as being anti-network neutrality. Whether Google intended this is unclear. I suspect Verizon wanted exactly what it got. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From jeroen at mompl.net Tue Aug 10 15:33:07 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Tue, 10 Aug 2010 13:33:07 -0700 Subject: Google wants your Internet to be faster In-Reply-To: <20100810195815.CD1591CC3A@ptavv.es.net> References: <20100810195815.CD1591CC3A@ptavv.es.net> Message-ID: <4C61B783.3060606@mompl.net> Kevin Oberman wrote: > That said, the actual, published document has some huge issues. It pays > excellent lip service to net neutrality, but it has simply HUGE > loopholes with lots of weasel words that could be used to get away with > most anything. for example, it expressly excludes and wireless network. Not having read any of the articles and not having researched the matter of network neutrality much at all. But wouldn't using either a VPN service or setting up VPN on one or more virtual servers at strategic locations of your choice avoid this? Unless "they" try to bandwidth limit your VPN tunnel(s) indiscriminately. Or did I miss something blatantly obvious? At least VPN does a great job of "routing around" GeoIP blocking... Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From will at harg.net Tue Aug 10 16:28:04 2010 From: will at harg.net (Will Hargrave) Date: Tue, 10 Aug 2010 22:28:04 +0100 Subject: AW: Recommended 1Gb SFP for ~115km? In-Reply-To: References: Message-ID: On 4 Aug 2010, at 17:58, Thomas Weible wrote: > Cisco did a quite good job on implementing the DDM characteristics of the optics. So why not to take a 32dB or even 41dB power budget SFP and make it workable in the switch / router. Works like charm in some setups and you see straight the actual line. Sadly not the case here. OP is using a 6506, and the majority of the 67xx linecards released (which are the decent gige linecards for 6500) don't even support DDM/DOM at all. Only the very latest hardware revisions do. Sigh. Other vendors refuse to report light levels from optics they didn't supply. This is just a bad-faith way round the RFP/tender clauses we've all been including for the past 5 years prohibiting vendor locking optics. Shame on them. Will From jjackson at aninetworks.net Tue Aug 10 16:42:43 2010 From: jjackson at aninetworks.net (Joseph Jackson) Date: Tue, 10 Aug 2010 14:42:43 -0700 Subject: Google wants your Internet to be faster In-Reply-To: <4C61B783.3060606@mompl.net> References: <20100810195815.CD1591CC3A@ptavv.es.net> <4C61B783.3060606@mompl.net> Message-ID: <6D497FE8AFD83E49AFADD9114C569F8F06B580ABA9@EXMBX10.exchhosting.com> -----Original Message----- From: Jeroen van Aart [mailto:jeroen at mompl.net] Sent: Tuesday, August 10, 2010 3:33 PM To: NANOG list Subject: Re: Google wants your Internet to be faster Kevin Oberman wrote: > That said, the actual, published document has some huge issues. It pays > excellent lip service to net neutrality, but it has simply HUGE > loopholes with lots of weasel words that could be used to get away with > most anything. for example, it expressly excludes and wireless network. Not having read any of the articles and not having researched the matter of network neutrality much at all. But wouldn't using either a VPN service or setting up VPN on one or more virtual servers at strategic locations of your choice avoid this? Unless "they" try to bandwidth limit your VPN tunnel(s) indiscriminately. Or did I miss something blatantly obvious? At least VPN does a great job of "routing around" GeoIP blocking... The way I understand it is if you aren't paying for preferred service then your VPN traffic would be at the bottom of the stack on forwarding. So while it gets around GeoIP stuff vpns would be subject to the same quality of service settings as any other traffic that isn't paying for a faster service. Joseph From joly at punkcast.com Tue Aug 10 16:53:07 2010 From: joly at punkcast.com (Joly MacFie) Date: Tue, 10 Aug 2010 17:53:07 -0400 Subject: Google wants your Internet to be faster In-Reply-To: <4C61B783.3060606@mompl.net> References: <20100810195815.CD1591CC3A@ptavv.es.net> <4C61B783.3060606@mompl.net> Message-ID: Isn't the essence of consensus is to find common areas of agreement while punting on the rest. There's plenty to focus on that IS in there, like transparency and FCC control? Kevin Oberman wrote: > >> That said, the actual, published document has some huge issues. It pays >> excellent lip service to net neutrality, but it has simply HUGE >> loopholes with lots of weasel words that could be used to get away with >> most anything. for example, it expressly excludes and wireless network. >> > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com Secretary - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From oberman at es.net Tue Aug 10 16:57:19 2010 From: oberman at es.net (Kevin Oberman) Date: Tue, 10 Aug 2010 14:57:19 -0700 Subject: Google wants your Internet to be faster In-Reply-To: Your message of "Tue, 10 Aug 2010 14:42:43 PDT." <6D497FE8AFD83E49AFADD9114C569F8F06B580ABA9@EXMBX10.exchhosting.com> Message-ID: <20100810215719.1720B1CC3B@ptavv.es.net> > From: Joseph Jackson > Date: Tue, 10 Aug 2010 14:42:43 -0700 > > > > -----Original Message----- > From: Jeroen van Aart [mailto:jeroen at mompl.net] > Sent: Tuesday, August 10, 2010 3:33 PM > To: NANOG list > Subject: Re: Google wants your Internet to be faster > > Kevin Oberman wrote: > > That said, the actual, published document has some huge issues. It pays > > excellent lip service to net neutrality, but it has simply HUGE > > loopholes with lots of weasel words that could be used to get away with > > most anything. for example, it expressly excludes and wireless network. > > Not having read any of the articles and not having researched the matter > of network neutrality much at all. But wouldn't using either a VPN > service or setting up VPN on one or more virtual servers at strategic > locations of your choice avoid this? Unless "they" try to bandwidth > limit your VPN tunnel(s) indiscriminately. Or did I miss something > blatantly obvious? > > At least VPN does a great job of "routing around" GeoIP blocking... > > > The way I understand it is if you aren't paying for preferred service > then your VPN traffic would be at the bottom of the stack on > forwarding. So while it gets around GeoIP stuff vpns would be subject > to the same quality of service settings as any other traffic that > isn't paying for a faster service. > > Joseph > VPNs are very handy for this, but it is worth remembering that it is not free. All of the traffic has to traverse the network to the VPN box and then to the client. This can hit congestion issues, but always increases RTT and that can be a real pain. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From Valdis.Kletnieks at vt.edu Tue Aug 10 17:00:06 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 10 Aug 2010 18:00:06 -0400 Subject: Google wants your Internet to be faster In-Reply-To: Your message of "Tue, 10 Aug 2010 14:42:43 PDT." <6D497FE8AFD83E49AFADD9114C569F8F06B580ABA9@EXMBX10.exchhosting.com> References: <20100810195815.CD1591CC3A@ptavv.es.net> <4C61B783.3060606@mompl.net> <6D497FE8AFD83E49AFADD9114C569F8F06B580ABA9@EXMBX10.exchhosting.com> Message-ID: <12384.1281477606@localhost> On Tue, 10 Aug 2010 14:42:43 PDT, Joseph Jackson said: > The way I understand it is if you aren't paying for preferred service then > your VPN traffic would be at the bottom of the stack on forwarding. So while > it gets around GeoIP stuff vpns would be subject to the same quality of service > settings as any other traffic that isn't paying for a faster service. This sounds suspiciously like Matt Blaze's observation: "A commercial CA will protect you from anyone whose money it refuses to take". As usual, it ends up as "follow the money". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From oberman at es.net Tue Aug 10 17:03:43 2010 From: oberman at es.net (Kevin Oberman) Date: Tue, 10 Aug 2010 15:03:43 -0700 Subject: Google wants your Internet to be faster In-Reply-To: Your message of "Tue, 10 Aug 2010 17:53:07 EDT." Message-ID: <20100810220343.1B5951CC3A@ptavv.es.net> Top posting reformatted. > Kevin Oberman wrote: > > > >> That said, the actual, published document has some huge issues. It pays > >> excellent lip service to net neutrality, but it has simply HUGE > >> loopholes with lots of weasel words that could be used to get away with > >> most anything. for example, it expressly excludes and wireless network. > >> > > > > > From: Joly MacFie > Date: Tue, 10 Aug 2010 17:53:07 -0400 > > Isn't the essence of consensus is to find common areas of agreement while > punting on the rest. There's plenty to focus on that IS in there, like > transparency and FCC control? You can punt the rest, but when the wording states that a large and rapidly growing segment of the network is subject to having preferred services is a bit more that a 'punt'. Also, the wording seems to work hard at making sure that you will always be able to justify any "non-neutral' things you might decide to do. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From young at jsyoung.net Tue Aug 10 18:28:48 2010 From: young at jsyoung.net (Jeff Young) Date: Wed, 11 Aug 2010 09:28:48 +1000 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: References: <604794.12749.qm@web53002.mail.re2.yahoo.com> Message-ID: <214885B1-7B60-45A2-B3CC-2EA349E05F1F@jsyoung.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 At the time these statements were made it was possible to make reasonable assumptions about the size of the Internet. As a Tier 1 knew how much traffic our customer links generated by the size of the link. We knew exactly how much traffic stayed within our backbones and how much traffic ended up in a peering arrangement. We knew with some precision just how much of the Tier 2 ISP market was connected to us and how much was connected to others, and who the others were. I don't think the theory still holds but traffic on-net versus off-net was a pretty good indication of market share. Today's Internet handles much more traffic in-region and is bounded by phenomenon such as language barrier (although the amount of spam I get in Chinese characters has increased recently, who let the barrier down?). This phenomenon wasn't as prominent in '98-'01 and while I wouldn't say it's impossible I think you'd have to commission the folks at UCSD to get anything that resembled a value for total Internet capacity today. Doubling in 9-12 months was a reasonable figure back then. 100 days might have been a short-term spike caused by a back-log of activations (we sometimes stopped the machine while we made upgrades) but it certainly was an anomaly. jy On 10/08/2010, at 9:01 AM, Kenny Sallee wrote: > On Fri, Aug 6, 2010 at 2:52 PM, Jessica Yu wrote: >> >> I do not know if making such distinction would alter the conclusion of your >> paper. But, to me, there is a difference between one to predict the growth >> of >> one particular network based on the stats collected than one to predict the >> growth of the entire Internet with no solid data. >> Thanks!--Jessica >> > > Agree with Jessica: you can't say the 'Internet' doubles every x number of > days/amount of time no matter what the number of days or amount of time is. > The 'Internet' is a series of tubes...hahaha couldn't help it....As we all > know the Internet is a bunch of providers plugged into each other. Provider > A may see an 10x increase in traffic every month while provider B may not. > For example, if Google makes a deal with Verizon only Verizon will see a > huge increase in traffic internally and less externally (or vice versa). > Until Google goes somewhere else! So the whole 'myth' of Internet doubling > every 100 days to me is something someone (ODell it seems) made up to > appease someone higher in the chain or a government committee that really > doesn't get it. IE - it's marketing talk to quantify something. I guess if > all the ISP's in the world provided a central repository bandwidth numbers > they have on their backbone then you could make up some stats about Internet > traffic as a whole. But without that - it just doesn't make much sense. > > Just my .02 > Kenny > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) iF4EAREIAAYFAkxh4LUACgkQxvthcni5E2+7AwD+Lx+Dm14XTn/qZpy2co3CrcI1 dzA9QycoM2VmMBjmfxwA/1LD7gqI3zd80VozkHMDbDIREDPxKBPPtMlb+7Tu/nPV =wt/O -----END PGP SIGNATURE----- From kris.foster at gmail.com Wed Aug 11 01:48:50 2010 From: kris.foster at gmail.com (kris foster) Date: Tue, 10 Aug 2010 23:48:50 -0700 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: <214885B1-7B60-45A2-B3CC-2EA349E05F1F@jsyoung.net> References: <604794.12749.qm@web53002.mail.re2.yahoo.com> <214885B1-7B60-45A2-B3CC-2EA349E05F1F@jsyoung.net> Message-ID: <621C1B2C-F7E3-438F-9DDD-D5DC41979922@gmail.com> A comment from Jeremy Orbell at LINX: -- The period of growth being discussed predates my own involvement in the industry as I didn't join LINX until 2003. However I do know that LINX regularly announced new traffic milestones at the exchange as they happened back in the late 90s. I've looked back through our archive of press releases and noted a few of these so you will get an idea of how peak traffic was increasing at LINX at that time. 27 April 1998 - 200 Mbps 24 August 1999 - 850 Mbps 17 September 1999 - 1 Gbps 5 November 1999 - 1.25 Gbps 13 December 1999 - 1.5 Gbps 27 March 2000 - 2 Gbps 11 January 2001 - 5 Gbps Unfortunately I cannot post links the original material as it isn't available online at the moment but in the LINX 15th anniversary issue of HotLINX last year we reprinted a copy of a LINX press release from 17th September 1999 which said: "The London Internet Exchange is pleased to announce it has this week reached traffic levels of one Gigabit, positioning it clearly as one of the top 5 Internet Exchanges in the world. This shows a 455% increase in traffic from the level of 180 Mbps one year ago." Looking at that 180 Mbps number it looks like it might refer to a Spring 1998 figure rather than September 1998 because I did find a reference to a peak of 200 Mbps being achieved in April of that year. The discrepency could perhaps be explained by other means such as averages but like I say, it was before my time. Anyway, the full press release which I quoted from can be read on page 3 of the following PDF:https://www.linx.net/files/hotlinx/hotlinx-20.pdf I hope this will be of hope to you. Jeremy Orbell LINX Marketing & Communications On Aug 10, 2010, at 4:28 PM, Jeff Young wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > At the time these statements were made it was possible to make reasonable > assumptions about the size of the Internet. As a Tier 1 knew how much traffic our > customer links generated by the size of the link. We knew exactly how much > traffic stayed within our backbones and how much traffic ended up in a > peering arrangement. We knew with some precision just how much of the > Tier 2 ISP market was connected to us and how much was connected to others, > and who the others were. I don't think the theory still holds but traffic on-net > versus off-net was a pretty good indication of market share. > > Today's Internet handles much more traffic in-region and is bounded by > phenomenon such as language barrier (although the amount of spam I get > in Chinese characters has increased recently, who let the barrier down?). > This phenomenon wasn't as prominent in '98-'01 and while I wouldn't say > it's impossible I think you'd have to commission the folks at UCSD to get > anything that resembled a value for total Internet capacity today. > > Doubling in 9-12 months was a reasonable figure back then. 100 days > might have been a short-term spike caused by a back-log of activations > (we sometimes stopped the machine while we made upgrades) but it > certainly was an anomaly. > > jy > > > On 10/08/2010, at 9:01 AM, Kenny Sallee wrote: > >> On Fri, Aug 6, 2010 at 2:52 PM, Jessica Yu wrote: >>> >>> I do not know if making such distinction would alter the conclusion of your >>> paper. But, to me, there is a difference between one to predict the growth >>> of >>> one particular network based on the stats collected than one to predict the >>> growth of the entire Internet with no solid data. >>> Thanks!--Jessica >>> >> >> Agree with Jessica: you can't say the 'Internet' doubles every x number of >> days/amount of time no matter what the number of days or amount of time is. >> The 'Internet' is a series of tubes...hahaha couldn't help it....As we all >> know the Internet is a bunch of providers plugged into each other. Provider >> A may see an 10x increase in traffic every month while provider B may not. >> For example, if Google makes a deal with Verizon only Verizon will see a >> huge increase in traffic internally and less externally (or vice versa). >> Until Google goes somewhere else! So the whole 'myth' of Internet doubling >> every 100 days to me is something someone (ODell it seems) made up to >> appease someone higher in the chain or a government committee that really >> doesn't get it. IE - it's marketing talk to quantify something. I guess if >> all the ISP's in the world provided a central repository bandwidth numbers >> they have on their backbone then you could make up some stats about Internet >> traffic as a whole. But without that - it just doesn't make much sense. >> >> Just my .02 >> Kenny >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.14 (Darwin) > > iF4EAREIAAYFAkxh4LUACgkQxvthcni5E2+7AwD+Lx+Dm14XTn/qZpy2co3CrcI1 > dzA9QycoM2VmMBjmfxwA/1LD7gqI3zd80VozkHMDbDIREDPxKBPPtMlb+7Tu/nPV > =wt/O > -----END PGP SIGNATURE----- > From lists at internetpolicyagency.com Wed Aug 11 03:04:06 2010 From: lists at internetpolicyagency.com (Roland Perry) Date: Wed, 11 Aug 2010 09:04:06 +0100 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: <621C1B2C-F7E3-438F-9DDD-D5DC41979922@gmail.com> References: <604794.12749.qm@web53002.mail.re2.yahoo.com> <214885B1-7B60-45A2-B3CC-2EA349E05F1F@jsyoung.net> <621C1B2C-F7E3-438F-9DDD-D5DC41979922@gmail.com> Message-ID: In article <621C1B2C-F7E3-438F-9DDD-D5DC41979922 at gmail.com>, kris foster quotes Jeremy Orbell >Anyway, the full press release which I quoted from can be read on page 3 >of the following PDF:https://www.linx.net/files/hotlinx/hotlinx-20.pdf And on page 2 there's the "Internet Time x4" meme, which was indeed in its heyday in 2001. -- Roland Perry From sven at cb3rob.net Wed Aug 11 05:52:53 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Wed, 11 Aug 2010 10:52:53 +0000 (UTC) Subject: net-neutrality Message-ID: Hi, considering the fact that several organisations have been severely undermining net-neutrality over the past few months, which they seem to see as less important than their copyright bullshit, we have decided to set an example: Should the following networks, to which list more will be added over the coming month, desire to exchange traffic with AS34109, they can obtain a traffic relay contract at sales at cb3rob.net, the costs of which amount to 10000 euros per month, excl. 19% VAT, if not, well, then it's simply no more internets for them... sorry peeps. 193.108.8.0/21#GEMA-NET 195.109.249.64/29#SONYMUSIC 195.143.92.160/27#SBMG1-NETS 212.123.224.240/29#Net-WEGENER-MEDIA-BV 212.123.227.64/29#BumaStemra2 212.136.193.216/29#BUMA 212.78.179.240/28#BUMA-STEMRA 213.208.242.160/29#NL-COLT-BUMA-STEMRA 217.148.80.112/28#NL-NXS-CUST-1004613 85.236.46.0/24#IX-UNIVERSAL-NET -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven at cb3rob.net ========================================================================= C3P0, der elektrische Westerwelle ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Aug 11 06:17:47 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 11 Aug 2010 20:47:47 +0930 Subject: net-neutrality In-Reply-To: References: Message-ID: <20100811204747.04523a23@opy.nosense.org> On Wed, 11 Aug 2010 10:52:53 +0000 (UTC) Sven Olaf Kamphuis wrote: > Hi, considering the fact that several organisations have been severely > undermining net-neutrality over the past few months, What is your definition of violating net-neutrality? Is it (a) carriers ransoming content providers so that only then will the content providers receive fair, equal and unfettered access to the carriers' customers? or (b) applying QoS to customer traffic if necessary because TCP was designed to suck up all the bandwidth available (to try to achieve 100% return on investment in the network capex), based on an original assumption that there'd be short bursts of TCP traffic, and now some applications, particular P2P ones, which use TCP, now create constant rather than bursty load on the network, resulting in congestion and impacting latency sensitive applications such as VoIP and gaming? > which they seem to > see as less important than their copyright bullshit, we have decided to > set an example: > > Should the following networks, to which list more will be added over the > coming month, desire to exchange traffic with AS34109, they can obtain a > traffic relay contract at sales at cb3rob.net, the costs of which amount > to 10000 euros per month, excl. 19% VAT, if not, well, then it's simply no > more internets for them... sorry peeps. > > > 193.108.8.0/21#GEMA-NET > 195.109.249.64/29#SONYMUSIC > 195.143.92.160/27#SBMG1-NETS > 212.123.224.240/29#Net-WEGENER-MEDIA-BV > 212.123.227.64/29#BumaStemra2 > 212.136.193.216/29#BUMA > 212.78.179.240/28#BUMA-STEMRA > 213.208.242.160/29#NL-COLT-BUMA-STEMRA > 217.148.80.112/28#NL-NXS-CUST-1004613 > 85.236.46.0/24#IX-UNIVERSAL-NET > > > -- > Greetings, > > Sven Olaf Kamphuis, > CB3ROB Ltd. & Co. KG > ========================================================================= > Address: Koloniestrasse 34 VAT Tax ID: DE267268209 > D-13359 Registration: HRA 42834 B > BERLIN Phone: +31/(0)87-8747479 > Germany GSM: +49/(0)152-26410799 > RIPE: CBSK1-RIPE e-Mail: sven at cb3rob.net > ========================================================================= > C3P0, der elektrische Westerwelle > > ========================================================================= > > Confidential: Please be advised that the information contained in this > email message, including all attached documents or files, is privileged > and confidential and is intended only for the use of the individual or > individuals addressed. Any other use, dissemination, distribution or > copying of this communication is strictly prohibited. > > From ops.lists at gmail.com Wed Aug 11 06:22:00 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 11 Aug 2010 16:52:00 +0530 Subject: net-neutrality In-Reply-To: References: Message-ID: If you announce anything worth reaching in that AS of yours .. MAYBE, JUST MAYBE they'd care rather than yawn 84.22.96.0/19 has, for instance - 84.22.96.254 cock-is.huge.nl If sony music etc want to engage in a size war with you, that's entirely up to them. Meanwhile, please leave nanog out of this. It is your toy AS with what looks like little or no production traffic on it, and you're free to play with it as you like. --srs On Wed, Aug 11, 2010 at 4:22 PM, Sven Olaf Kamphuis wrote: > Hi, considering the fact that several organisations have been severely > undermining net-neutrality over the past few months, which they seem to see > as less important than their copyright bullshit, we have decided to set an > example: > > Should the following networks, to which list more will be added over the > coming month, desire to exchange traffic with AS34109, they can obtain a > traffic relay contract at sales at cb3rob.net, the costs of which amount to > 10000 euros per month, excl. 19% VAT, if not, well, then it's simply no more > internets for them... sorry peeps. > > > 193.108.8.0/21#GEMA-NET > 195.109.249.64/29#SONYMUSIC > 195.143.92.160/27#SBMG1-NETS > 212.123.224.240/29#Net-WEGENER-MEDIA-BV > 212.123.227.64/29#BumaStemra2 > 212.136.193.216/29#BUMA > 212.78.179.240/28#BUMA-STEMRA > 213.208.242.160/29#NL-COLT-BUMA-STEMRA > 217.148.80.112/28#NL-NXS-CUST-1004613 > 85.236.46.0/24#IX-UNIVERSAL-NET > > > -- > Greetings, > > Sven Olaf Kamphuis, > CB3ROB Ltd. & Co. KG > ========================================================================= > Address: Koloniestrasse 34 ? ? ? ? VAT Tax ID: ? ? ?DE267268209 > ? ? ? ? D-13359 ? ? ? ? ? ? ? ? ? Registration: ? ?HRA 42834 B > ? ? ? ? BERLIN ? ? ? ? ? ? ? ? ? ?Phone: ? ? ? ? ? +31/(0)87-8747479 > ? ? ? ? Germany ? ? ? ? ? ? ? ? ? GSM: ? ? ? ? ? ? +49/(0)152-26410799 > RIPE: ? ?CBSK1-RIPE ? ? ? ? ? ? ? ?e-Mail: ? ? ? ? ?sven at cb3rob.net > ========================================================================= > C3P0, der elektrische Westerwelle > > ========================================================================= > > Confidential: Please be advised that the information contained in this > email message, including all attached documents or files, is privileged > and confidential and is intended only for the use of the individual or > individuals addressed. Any other use, dissemination, distribution or > copying of this communication is strictly prohibited. > > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From sven at cb3rob.net Wed Aug 11 06:25:25 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Wed, 11 Aug 2010 11:25:25 +0000 (UTC) Subject: net-neutrality In-Reply-To: <20100811204747.04523a23@opy.nosense.org> References: <20100811204747.04523a23@opy.nosense.org> Message-ID: it is: c) RIAA/MPAA members trying to make ISPs liable for what customers do in order to somehow fork the isp into kicking out the customer, as they refuse to simply go to court against the customer but rather prefer to harrass their ISP or their isp's isp.. Well guess what, we don't really feel like giving them something for free (their traffic being relayed over our infrastructure) if they act hostile, if they can't get the piratebay ITSELF to shut down, we can only conclude the piratebay has the RIGHT to internet just as much as they do, actually more, as the piratebay paid us, and they don't. (so let's change the payment structure a bit and make these people pay us too ;) see also the various piratebay cases, as well as the fact that universal music germany gmbh can't be fucked to pay for their own court fees if they need a court order to get us to give out an address (the poor fuckers, whatever happened to mtv-cribs ;) -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven at cb3rob.net ========================================================================= C3P0, der elektrische Westerwelle ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Wed, 11 Aug 2010, Mark Smith wrote: > On Wed, 11 Aug 2010 10:52:53 +0000 (UTC) > Sven Olaf Kamphuis wrote: > >> Hi, considering the fact that several organisations have been severely >> undermining net-neutrality over the past few months, > > What is your definition of violating net-neutrality? > > Is it > > (a) carriers ransoming content providers so that only then will the > content providers receive fair, equal and unfettered access to the > carriers' customers? > > or > > (b) applying QoS to customer traffic if necessary because TCP was > designed to suck up all the bandwidth available (to try to achieve 100% > return on investment in the network capex), based on an original > assumption that there'd be short bursts of TCP traffic, and now some > applications, particular P2P ones, which use TCP, now create constant > rather than bursty load on the network, resulting in congestion and > impacting latency sensitive applications such as VoIP and gaming? > > > >> which they seem to >> see as less important than their copyright bullshit, we have decided to >> set an example: >> >> Should the following networks, to which list more will be added over the >> coming month, desire to exchange traffic with AS34109, they can obtain a >> traffic relay contract at sales at cb3rob.net, the costs of which amount >> to 10000 euros per month, excl. 19% VAT, if not, well, then it's simply no >> more internets for them... sorry peeps. >> >> >> 193.108.8.0/21#GEMA-NET >> 195.109.249.64/29#SONYMUSIC >> 195.143.92.160/27#SBMG1-NETS >> 212.123.224.240/29#Net-WEGENER-MEDIA-BV >> 212.123.227.64/29#BumaStemra2 >> 212.136.193.216/29#BUMA >> 212.78.179.240/28#BUMA-STEMRA >> 213.208.242.160/29#NL-COLT-BUMA-STEMRA >> 217.148.80.112/28#NL-NXS-CUST-1004613 >> 85.236.46.0/24#IX-UNIVERSAL-NET >> >> >> -- >> Greetings, >> >> Sven Olaf Kamphuis, >> CB3ROB Ltd. & Co. KG >> ========================================================================= >> Address: Koloniestrasse 34 VAT Tax ID: DE267268209 >> D-13359 Registration: HRA 42834 B >> BERLIN Phone: +31/(0)87-8747479 >> Germany GSM: +49/(0)152-26410799 >> RIPE: CBSK1-RIPE e-Mail: sven at cb3rob.net >> ========================================================================= >> C3P0, der elektrische Westerwelle >> >> ========================================================================= >> >> Confidential: Please be advised that the information contained in this >> email message, including all attached documents or files, is privileged >> and confidential and is intended only for the use of the individual or >> individuals addressed. Any other use, dissemination, distribution or >> copying of this communication is strictly prohibited. >> >> > From sven at cb3rob.net Wed Aug 11 06:26:59 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Wed, 11 Aug 2010 11:26:59 +0000 (UTC) Subject: net-neutrality In-Reply-To: <20100811204747.04523a23@opy.nosense.org> References: <20100811204747.04523a23@opy.nosense.org> Message-ID: next up on the list: disney, paramount pictures, sony music entertainment, sony pictures entertainment, most of vivendi/universal group, viacom.. all of these organisations have well established themselves on the list of organisations not worthy to have their traffic relayed for free. -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven at cb3rob.net ========================================================================= C3P0, der elektrische Westerwelle ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Wed, 11 Aug 2010, Mark Smith wrote: > On Wed, 11 Aug 2010 10:52:53 +0000 (UTC) > Sven Olaf Kamphuis wrote: > >> Hi, considering the fact that several organisations have been severely >> undermining net-neutrality over the past few months, > > What is your definition of violating net-neutrality? > > Is it > > (a) carriers ransoming content providers so that only then will the > content providers receive fair, equal and unfettered access to the > carriers' customers? > > or > > (b) applying QoS to customer traffic if necessary because TCP was > designed to suck up all the bandwidth available (to try to achieve 100% > return on investment in the network capex), based on an original > assumption that there'd be short bursts of TCP traffic, and now some > applications, particular P2P ones, which use TCP, now create constant > rather than bursty load on the network, resulting in congestion and > impacting latency sensitive applications such as VoIP and gaming? > > > >> which they seem to >> see as less important than their copyright bullshit, we have decided to >> set an example: >> >> Should the following networks, to which list more will be added over the >> coming month, desire to exchange traffic with AS34109, they can obtain a >> traffic relay contract at sales at cb3rob.net, the costs of which amount >> to 10000 euros per month, excl. 19% VAT, if not, well, then it's simply no >> more internets for them... sorry peeps. >> >> >> 193.108.8.0/21#GEMA-NET >> 195.109.249.64/29#SONYMUSIC >> 195.143.92.160/27#SBMG1-NETS >> 212.123.224.240/29#Net-WEGENER-MEDIA-BV >> 212.123.227.64/29#BumaStemra2 >> 212.136.193.216/29#BUMA >> 212.78.179.240/28#BUMA-STEMRA >> 213.208.242.160/29#NL-COLT-BUMA-STEMRA >> 217.148.80.112/28#NL-NXS-CUST-1004613 >> 85.236.46.0/24#IX-UNIVERSAL-NET >> >> >> -- >> Greetings, >> >> Sven Olaf Kamphuis, >> CB3ROB Ltd. & Co. KG >> ========================================================================= >> Address: Koloniestrasse 34 VAT Tax ID: DE267268209 >> D-13359 Registration: HRA 42834 B >> BERLIN Phone: +31/(0)87-8747479 >> Germany GSM: +49/(0)152-26410799 >> RIPE: CBSK1-RIPE e-Mail: sven at cb3rob.net >> ========================================================================= >> C3P0, der elektrische Westerwelle >> >> ========================================================================= >> >> Confidential: Please be advised that the information contained in this >> email message, including all attached documents or files, is privileged >> and confidential and is intended only for the use of the individual or >> individuals addressed. Any other use, dissemination, distribution or >> copying of this communication is strictly prohibited. >> >> > From sven at cb3rob.net Wed Aug 11 06:29:32 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Wed, 11 Aug 2010 11:29:32 +0000 (UTC) Subject: net-neutrality In-Reply-To: References: Message-ID: hmm funny, it had the piratebay on it, the 3rd most visted .org domain in the world, as well as number 7 or so on the list of most visted websites in the entire world, until a few months ago. not to mention several of our other clients ;) i'd suggest you do your homework properly next time :P the MAFIAA surely did :P -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven at cb3rob.net ========================================================================= C3P0, der elektrische Westerwelle ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Wed, 11 Aug 2010, Suresh Ramasubramanian wrote: > If you announce anything worth reaching in that AS of yours .. MAYBE, > JUST MAYBE they'd care rather than yawn > > 84.22.96.0/19 has, for instance - 84.22.96.254 cock-is.huge.nl > > If sony music etc want to engage in a size war with you, that's > entirely up to them. > > Meanwhile, please leave nanog out of this. It is your toy AS with > what looks like little or no production traffic on it, and you're free > to play with it as you like. > > --srs > > On Wed, Aug 11, 2010 at 4:22 PM, Sven Olaf Kamphuis wrote: >> Hi, considering the fact that several organisations have been severely >> undermining net-neutrality over the past few months, which they seem to see >> as less important than their copyright bullshit, we have decided to set an >> example: >> >> Should the following networks, to which list more will be added over the >> coming month, desire to exchange traffic with AS34109, they can obtain a >> traffic relay contract at sales at cb3rob.net, the costs of which amount to >> 10000 euros per month, excl. 19% VAT, if not, well, then it's simply no more >> internets for them... sorry peeps. >> >> >> 193.108.8.0/21#GEMA-NET >> 195.109.249.64/29#SONYMUSIC >> 195.143.92.160/27#SBMG1-NETS >> 212.123.224.240/29#Net-WEGENER-MEDIA-BV >> 212.123.227.64/29#BumaStemra2 >> 212.136.193.216/29#BUMA >> 212.78.179.240/28#BUMA-STEMRA >> 213.208.242.160/29#NL-COLT-BUMA-STEMRA >> 217.148.80.112/28#NL-NXS-CUST-1004613 >> 85.236.46.0/24#IX-UNIVERSAL-NET >> >> >> -- >> Greetings, >> >> Sven Olaf Kamphuis, >> CB3ROB Ltd. & Co. KG >> ========================================================================= >> Address: Koloniestrasse 34 ? ? ? ? VAT Tax ID: ? ? ?DE267268209 >> ? ? ? ? D-13359 ? ? ? ? ? ? ? ? ? Registration: ? ?HRA 42834 B >> ? ? ? ? BERLIN ? ? ? ? ? ? ? ? ? ?Phone: ? ? ? ? ? +31/(0)87-8747479 >> ? ? ? ? Germany ? ? ? ? ? ? ? ? ? GSM: ? ? ? ? ? ? +49/(0)152-26410799 >> RIPE: ? ?CBSK1-RIPE ? ? ? ? ? ? ? ?e-Mail: ? ? ? ? ?sven at cb3rob.net >> ========================================================================= >> C3P0, der elektrische Westerwelle >> >> ========================================================================= >> >> Confidential: Please be advised that the information contained in this >> email message, including all attached documents or files, is privileged >> and confidential and is intended only for the use of the individual or >> individuals addressed. Any other use, dissemination, distribution or >> copying of this communication is strictly prohibited. >> >> >> > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > From ops.lists at gmail.com Wed Aug 11 06:34:22 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 11 Aug 2010 17:04:22 +0530 Subject: net-neutrality In-Reply-To: References: Message-ID: On Wed, Aug 11, 2010 at 4:59 PM, Sven Olaf Kamphuis wrote: > hmm funny, it had the piratebay on it, the 3rd most visted .org domain in > the world, as well as number 7 or so on the list of most visted websites in > the entire world, until a few months ago. no, that doesnt matter as much as just how much traffic you actually exchange with those asns From sven at cb3rob.net Wed Aug 11 06:35:30 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Wed, 11 Aug 2010 11:35:30 +0000 (UTC) Subject: net-neutrality In-Reply-To: References: Message-ID: On Wed, 11 Aug 2010, Suresh Ramasubramanian wrote: > On Wed, Aug 11, 2010 at 4:59 PM, Sven Olaf Kamphuis wrote: >> hmm funny, it had the piratebay on it, the 3rd most visted .org domain in >> the world, as well as number 7 or so on the list of most visted websites in >> the entire world, until a few months ago. > > no, that doesnt matter as much as just how much traffic you actually > exchange with those asns > just for your info, this is just the first step, we can make it severely more nasty for them :P. -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven at cb3rob.net ========================================================================= C3P0, der elektrische Westerwelle ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. From sven at cb3rob.net Wed Aug 11 06:38:34 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Wed, 11 Aug 2010 11:38:34 +0000 (UTC) Subject: net-neutrality In-Reply-To: References: Message-ID: btw, considering that you appearantly run a larger network than the 3 networks we own and operate, willing to sell? :P -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven at cb3rob.net ========================================================================= C3P0, der elektrische Westerwelle ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Wed, 11 Aug 2010, Suresh Ramasubramanian wrote: > On Wed, Aug 11, 2010 at 4:59 PM, Sven Olaf Kamphuis wrote: >> hmm funny, it had the piratebay on it, the 3rd most visted .org domain in >> the world, as well as number 7 or so on the list of most visted websites in >> the entire world, until a few months ago. > > no, that doesnt matter as much as just how much traffic you actually > exchange with those asns > From raymond at prolocation.net Wed Aug 11 06:44:02 2010 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Wed, 11 Aug 2010 13:44:02 +0200 (CEST) Subject: net-neutrality In-Reply-To: References: Message-ID: Hi! > btw, considering that you appearantly run a larger network than the 3 > networks we own and operate, willing to sell? :P That would be rarther funny Sven, you buying IBM. Sweet dreams. Bye, Raymond. From ops.lists at gmail.com Wed Aug 11 06:50:23 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 11 Aug 2010 17:20:23 +0530 Subject: net-neutrality In-Reply-To: References: Message-ID: Not that I am speaking for anybody but myself here. I'll killfile this thread now On Wed, Aug 11, 2010 at 5:14 PM, Raymond Dijkxhoorn wrote: > >> btw, considering that you appearantly run a larger network than the 3 >> networks we own and operate, willing to sell? :P > > That would be rarther funny Sven, you buying IBM. Sweet dreams. -- Suresh Ramasubramanian (ops.lists at gmail.com) From nenolod at systeminplace.net Wed Aug 11 10:41:40 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Wed, 11 Aug 2010 10:41:40 -0500 Subject: net-neutrality In-Reply-To: References: Message-ID: <1281541300.6792.3.camel@petrie.dereferenced.org> On Wed, 2010-08-11 at 11:29 +0000, Sven Olaf Kamphuis wrote: > hmm funny, it had the piratebay on it, if you think that is a good sales point... do you actually have any legitimate customers? william From nenolod at systeminplace.net Wed Aug 11 11:09:13 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Wed, 11 Aug 2010 11:09:13 -0500 Subject: net-neutrality In-Reply-To: References: <20100811204747.04523a23@opy.nosense.org> Message-ID: <1281542953.6792.8.camel@petrie.dereferenced.org> On Wed, 2010-08-11 at 11:25 +0000, Sven Olaf Kamphuis wrote: > it is: > > c) RIAA/MPAA members trying to make ISPs liable for what customers do in > order to somehow fork the isp into kicking out the customer, as they > refuse to simply go to court against the customer but rather prefer to > harrass their ISP or their isp's isp.. > did you stop taking your medication today? net-neutrality has nothing to do with following the law. if you do not like the copyright enforcement law in the netherlands, then change the law in the netherlands. nanog is not your soapbox, and I for one, am tired of hearing about how you host thepiratebay (which is, for the last few years at least, a pretty shitty torrent tracker anyway). so please, for the love of $deity, stop posting your crap to this list. by the way, you're still invited to provide a list of legitimate (e.g. not warez) customers you have. i'm pretty sure that you do not have any though. william From zimmy at zimmy.co.uk Wed Aug 11 11:21:35 2010 From: zimmy at zimmy.co.uk (Chris Fuenty) Date: Wed, 11 Aug 2010 11:21:35 -0500 Subject: net-neutrality In-Reply-To: References: Message-ID: <4C62CE0F.1070000@zimmy.co.uk> Other clients eh? Something tells your transit would be completely useless on days where new microsoft/adobe/protools/games gets released. Just saying. c On 8/11/2010 6:29 AM, Sven Olaf Kamphuis wrote: > hmm funny, it had the piratebay on it, the 3rd most visted .org domain > in the world, as well as number 7 or so on the list of most visted > websites in the entire world, until a few months ago. > > not to mention several of our other clients ;) > > i'd suggest you do your homework properly next time :P > > the MAFIAA surely did :P > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From nathan at atlasnetworks.us Wed Aug 11 11:27:43 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 11 Aug 2010 16:27:43 +0000 Subject: net-neutrality In-Reply-To: References: Message-ID: <8C26A4FDAE599041A13EB499117D3C2816478040@ex-mb-1.corp.atlasnetworks.us> > Hi, considering the fact that several organisations have been severely > undermining net-neutrality over the past few months, which they seem to see > as less important than their copyright bullshit, we have decided to set an > example: > > Should the following networks, to which list more will be added over the > coming month, desire to exchange traffic with AS34109, they can obtain a > traffic relay contract at sales at cb3rob.net, the costs of which amount to 10000 > euros per month, excl. 19% VAT, if not, well, then it's simply no more internets > for them... sorry peeps. Just so I understand correctly, you're implementing what is tantamount to a 'violation of net neutrality' in order to punish these organizations for attempting to protect their intellectual property? You seem to value the neutral natural state of the internet at large. If you're upset by the way these businesses have conducted themselves, find a response which doesn't violate your own ethics. Otherwise, you look like a hypocrite throwing a tantrum. Best Regards, Nathan Eisenberg From odlyzko at umn.edu Wed Aug 11 11:55:34 2010 From: odlyzko at umn.edu (Andrew Odlyzko) Date: Wed, 11 Aug 2010 11:55:34 -0500 (CDT) Subject: off-topic: summary on Internet traffic growth myths Message-ID: Since several members of this list requested it, here is a summary of the responses to my request for information about Internet growth during the telecom bubble, in particular the perceptions of the O'Dell/Sidgmore/WorldCom/UUNet "Internet doubling every 100 days" myth. First of all, many thanks to all those who responded, on and off-list. This involved extensive correspondence and some long phone conversations, and helped fill out the picture of those very confusing times (and also made it even clearer than before that there were many different perspectives on what was happening). The entire message is rather long, but it is written in sections, to make it easy to get the gist quickly and neglect the rest. Andrew ------------------------------------------------------------------- 1. Short summary: People who got into the game late, or had been working at small ISPs or other enterprises, were generally willing to give serious credence to the "Internet doubling every 100 days" tale. The old-timers, especially those who worked for large ISPs or other large corporate establishment or research networks, were convinced by the late 1990s that this tale was false, but did not talk about it publicly, even inside the NANOG community. ------------------------------------------------------------------- 2. Longer version: The range of views was very wide, and hard to give justice to in full. But there seemed to be two distinct groups, and the consensus views (which obviously exclude quite a few people) appear to have been: 2A: Those who entered the field in the late 1990s, especially if they worked for small ISPs or other small enterprises, tended to regard the claim seriously. (But it should be remarked that hardly anybody devoted too much effort or thought to the claim, they were too busy putting out fires in their own backyards to worry about global issues.) They remembered periods of desperate efforts to keep up with exploding demand in their businesses. We saw just a few hours ago a post about LINX growing 5.5x in one year. Somebody else wrote about growing their business's traffic 1,000x in 2 years, or about 30x per year. People involved in such incidents often tended to think that their experience during such times might not have been untypical. 2B: Those who worked at places with large traffic, and especially those who got into the field in the early 1990s, were quite sure by the late 1990s that the UUNet fable was just that. Comments regarding everything emanating from UUNet during that period included phrases like "blowing smoke," "rolling our eyes," "taking it with a rock of salt." They had no direct knowledge of what went on inside UUNet, but from watching peering traffic, talking to salespeople about customer losses and wins, and to suppliers about deliveries of equipment, they could be pretty certain that neither the traffic nor the capacity of UUNet could be exploding at the mythical rates. They could see occasional spikes in traffic growth at some customers, or in some parts of their networks, but overall could see traffic growth settling down to a fairly regular doubling or a bit more than doubling each year. However, they did not discuss this in public, and I discuss that below, in point #4. ------------------------------------------------------------------- 3. Growth spurt in mid-1990s: The old-timers also provided very informative feedback about the global Internet traffic growth spurt in the 1995-96 time frame. It did hit suddenly and unexpectedly. (I am still trying to get confirmation on this, but I believe one of the informants said that before this period, the engineers at that person's Tier-1 ISP would routinely double the forecasts provided by the marketing team. At the peak of the bubble, the marketers would demand that the engineers plan for double the capacity that the engineers thought was going to be necessary.) Moreover, the dramatic slowdown in traffic growth that took place in 1997 was, at least in a number of cases, due substantially to a capacity crunch. Router and photonic equipment manufacturers did not have the technology needed for the traffic, and ILECs were slow in supplying access as well as backbone links. Hence the traffic growth spurt in 1996-96 was followed by a capacity growth spurt in 1997-98, which helped provide more credibility for the myth. ------------------------------------------------------------------- 4. Information viscosity: This incident provides far more information confirming the concept of "information viscosity" that I wrote about in my paper, that important and relevant information was available, but was not widely dispersed. Why did the information that Internet traffic was not doubling every 100 days get out to the public? It was not a closely guarded national security secret, after all. There seemed to be many reasons operating. In the case of Genuity (as the quote from Scott Marcus in my paper explains) it was a high-level decision, that going public would hurt the company, as it might be suspected of losing market share. But that seemed to be unusual, in that Genuity, while a major Tier-1 ISP, was small and independent, and so had people like Scott who were engineers, yet involved in policy making. At other places, other dynamics operated. At AT&T, for example, I was called in to a meeting with the management of WorldNet, the AT&T ISP unit, at the end of 2000. They had been telling their customers that Internet traffic was growing 10x per year, and some of those customers asked them about the discrepancy between that claim and the estimates of some folks from AT&T Labs - Research (Kerry Coffman and myself) that growth was just 2x per year. Now it is an interesting perspective on "information viscosity" and AT&T (and other large bureaucratic organizations) that those folks had not heard of Kerry's and my work, even though we had publicized it at the company. But in any event, at that meeting, I did succeed in convincing them that Internet traffic was growing only 2x per year (using evidence in my papers with Kerry, as well as extensive additional data from within AT&T itself), and they agreed they would not propagate the myth among customers. But the interesting thing was that many of the attendees (who included quite a few engineering types, not just the management) seemed disappointed. That really surprised me. After all, AT&T's Internet traffic was growing just about 4x per year, which meant our market share was doubling, instead of being cut in half. But it seems that many of them had really bought into the Internet dream. And, furthermore, the story that we were losing market share was a good one to pry additional resources from the corporation. Several of the NANOG old-timers said that they felt constrained from speaking about the falsity of the myth of astronomical growth rates by group solidarity. After all, it was a small, select group, and bad-mouthing one of their own in front of outsiders or even NANOG newbies did not seem the right thing to do. Then there was the additional factor that one person discussed very explicitly, and that I infer also applied in other cases. The myth was useful. Back in the mid-1990s, when it was not a myth, it did spur equipment suppliers and ILECs to greater effort. And afterwards, it was handy in internal fights over power and resources. If the Internet was exploding, one should not worry about closely examining expansion plans. In some ways, the persistence of false perceptions about Internet traffic growth mirrors that of utilization rates of data networks. When I wrote the paper "Data networks are lightly utilized, and will stay that way," back in 1998, http://www.dtc.umn.edu/~odlyzko/doc/network.utilization.pdf the more clueful data network engineers all knew that utilization rates were generally low, and usually had a good understanding as to why. But top management, as well as the research community, were almost uniformly convinced that congestion was the rule. It took me a while to understand the dynamics of the situation, in which network engineers and managers found it easier to say that they were experiencing 80% utilization and 20% packet losses and needed to upgrade, without having to explain to CEOs, CIOs, and especially to clueless CFOs, that this referred just to the peak hour on one crucial corporate WAN link, and yet justified a big new investment. Few people were lying, but many had incentives to maintain delusions among the top levels of the hierarchy. These demonstrations of information viscosity of course undermine the foundations of much of modern economics, especially of the efficient markets hypothesis. But that last myth is even more durable than "Internet traffic doubling every 100 days," especially since it does not lead directly to lots of dark fiber lying around unused, and lots of companies bankrupt. Information viscosity in facts and ideas in economics is very high, so we should not expect any changes on that scene. ------------------------------------------------------------------- 5. As a reminder, the paper that led to this discussion is "Bubbles, gullibility, and other challenges for economics, psychology, sociology, and information sciences," http://www.dtc.umn.edu/~odlyzko/doc/mania03.pdf The page with source materials from the bubbles times, http://www.dtc.umn.edu/~odlyzko/isources/ now has, in addition to a transcript of the O'Dell lecture at Stanford in May 2000, a copy of the Sidgmore paper from the Vortex98 Conference of May 1998. From jharper at first-american.net Wed Aug 11 12:23:01 2010 From: jharper at first-american.net (Jeff Harper) Date: Wed, 11 Aug 2010 12:23:01 -0500 Subject: =?utf-8?q?RE=3A_net-neutrality?= In-Reply-To: References: Message-ID: This is kind of like one person saying they're not going to listen to a radio station anymore. > -----Original Message----- > From: Sven Olaf Kamphuis [mailto:sven at cb3rob.net] > Sent: Wednesday, August 11, 2010 5:53 AM > To: nanog at nanog.org > Cc: aktive at lists.piratenpartei.de; algemeen at lists.piratenpartij.nl > Subject: net-neutrality > > Hi, considering the fact that several organisations have been severely > undermining net-neutrality over the past few months, which they seem to > see as less important than their copyright bullshit, we have decided to > set an example: > > Should the following networks, to which list more will be added over > the > coming month, desire to exchange traffic with AS34109, they can obtain > a > traffic relay contract at sales at cb3rob.net, the costs of which amount > to 10000 euros per month, excl. 19% VAT, if not, well, then it's simply > no > more internets for them... sorry peeps. > > > 193.108.8.0/21#GEMA-NET > 195.109.249.64/29#SONYMUSIC > 195.143.92.160/27#SBMG1-NETS > 212.123.224.240/29#Net-WEGENER-MEDIA-BV > 212.123.227.64/29#BumaStemra2 > 212.136.193.216/29#BUMA > 212.78.179.240/28#BUMA-STEMRA > 213.208.242.160/29#NL-COLT-BUMA-STEMRA > 217.148.80.112/28#NL-NXS-CUST-1004613 > 85.236.46.0/24#IX-UNIVERSAL-NET > > > -- > Greetings, > > Sven Olaf Kamphuis, > CB3ROB Ltd. & Co. KG > ======================================================================= > == > Address: Koloniestrasse 34 VAT Tax ID: DE267268209 > D-13359 Registration: HRA 42834 B > BERLIN Phone: +31/(0)87-8747479 > Germany GSM: +49/(0)152- > 26410799 > RIPE: CBSK1-RIPE e-Mail: sven at cb3rob.net > ======================================================================= > == > C3P0, der elektrische Westerwelle > > ======================================================================= > == > > Confidential: Please be advised that the information contained in this > email message, including all attached documents or files, is privileged > and confidential and is intended only for the use of the individual or > individuals addressed. Any other use, dissemination, distribution or > copying of this communication is strictly prohibited. > From jyy_99 at yahoo.com Wed Aug 11 12:24:30 2010 From: jyy_99 at yahoo.com (Jessica Yu) Date: Wed, 11 Aug 2010 10:24:30 -0700 (PDT) Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: References: <604794.12749.qm@web53002.mail.re2.yahoo.com> Message-ID: <434568.49696.qm@web53008.mail.re2.yahoo.com> Wait a sec, you seems to assume that the 'Doubling every 100 days" statement was?referring?to the Internet traffic not just UUNet traffic.? My recollection was that?the statement?was referring to UUNet traffic based on the stats collected in a period of time (see my previous email).?That is why I urged the author of the paper?to make this important distinction.? If one made a prediction based on?stats collected?and the prediction was not accurate due to the imperfection of stats (in this case, it may be caused by a short term growth?abnormally, as Jeff Young pointed out), it is unfair to assume the person misled?public on purpose. Thanks! --Jessica ________________________________ From: Kenny Sallee To: Jessica Yu ; Andrew Odlyzko Cc: nanog at nanog.org Sent: Mon, August 9, 2010 4:01:00 PM Subject: Re: off-topic: historical query concerning the Internet bubble On Fri, Aug 6, 2010 at 2:52 PM, Jessica Yu wrote: I do not know if making such distinction would alter the conclusion of your >paper.? But, to me, there is a difference between one to predict the growth of >one particular network based on the stats collected than?one to predict?the >growth of the entire Internet with no solid data. >Thanks!--Jessica > Agree with Jessica: you can't say the 'Internet' doubles every x number of days/amount of time no matter what the number of days or amount of time is. ?The 'Internet' is a series of tubes...hahaha couldn't help it....As we all know the Internet is a bunch of providers plugged into each other. ?Provider A may see an 10x increase in traffic every month while provider B may not. ?For example, if Google makes a deal with Verizon only Verizon will see a huge increase in traffic internally and less externally (or?vice?versa). ?Until Google goes somewhere else! ?So the whole 'myth' of Internet doubling every 100 days to me is something someone (ODell it seems) made up to appease someone higher in the chain or a government committee that really doesn't get it. ?IE - it's marketing talk to quantify something. ?I guess if all the ISP's in the world provided a central repository bandwidth numbers they have on their backbone then you could make up some stats about Internet traffic as a whole. ?But without that - it just doesn't make much sense. Just my .02 Kenny From Valdis.Kletnieks at vt.edu Wed Aug 11 12:50:53 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 11 Aug 2010 13:50:53 -0400 Subject: =?utf-8?q?RE=3A_net-neutrality?= In-Reply-To: Your message of "Wed, 11 Aug 2010 12:23:01 CDT." References: Message-ID: <5164.1281549053@localhost> On Wed, 11 Aug 2010 12:23:01 CDT, Jeff Harper said: > This is kind of like one person saying they're not going to listen to a > radio station anymore. "And the only reason I'm singing you this song now is cause you may know somebody in a similar situation, or you may be in a similar situation, and if your in a situation like that there's only one thing you can do and that's walk into the shrink wherever you are ,just walk in say "Shrink, You can get anything you want, at Alice's restaurant.". And walk out. You know, if one person, just one person does it they may think he's really sick and they won't take him. And if two people, two people do it, in harmony, they may think they're both faggots and they won't take either of them. And three people do it, three, can you imagine, three people walking in singin a bar of Alice's Restaurant and walking out. They may think it's an organization. And can you, can you imagine fifty people a day,I said fifty people a day walking in singin a bar of Alice's Restaurant and walking out. And friends they may thinks it's a movement." Of course, that *does* require finding 49 other like-minded people. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From infolacnog at lacnog.org Wed Aug 11 12:54:00 2010 From: infolacnog at lacnog.org (LACNOG 2010) Date: Wed, 11 Aug 2010 14:54:00 -0300 Subject: LACNOC 2010 - Meeting Registration Message-ID: Dear colleagues, LACNOG is pleased to announce the opening of registration to participate in the LACNOG 2010 meeting to be held in conjunction with LACNIC XIV and the 4th Brazilian PTT Forum. This joint event will take place from 19 to 22 October 2010, at the Caesar Park International Airport Hotel in Guarulhos, Sao Paulo, Brazil. Register now at: http://www.lacnog.org/en/eventos/lacnog-2010/registro Book your hotel at: http://www.lacnog.org/en/eventos/lacnog-2010/hospedaje Information and other details are available at the meeting website: http://www.lacnog.org/en/eventos/lacnog-2010/inicio LACNOG Program Committee From john at internetassociatesllc.com Wed Aug 11 13:13:47 2010 From: john at internetassociatesllc.com (John Lee) Date: Wed, 11 Aug 2010 13:13:47 -0500 Subject: off-topic: summary on Internet traffic growth History Message-ID: <53A6C7E936ED8544B1A2BC990D254F946FC6040B0B@MEMEXG1.HOST.local> Andrew, Earlier this week I had a meeting with the ex-Director of the Network Operations Center for MFS-Datanet/MCI whose tenure was through 1999. From 1994 to 1998 they were re-architeching the Frame Relay and ATM networks to handle the growth in traffic including these new facilities called peering points of MAE-East and MAE-West. From roughly 1990 to then end of 1996 they saw traffic on their switches grow at 50-70% growth every 6 months. By the last half of 1996 there was a head of line blocking problem on the DEC FDDI switches that was "regularly" bringing down the Internet. The architecture had lower traffic circuits were going through concentrators while higher traffic circuits were directly attached to ports on the switchs. MFS-Datanet was not going to take the hit for the interruptions to the Internet and was going to inform the trade press there was a problem with DEC FDDI switches so Digital "gave" six switches for the re-architecture of the MAEs to solve the problem. Once this problem was solved the first quarter of 1997 saw a 70% jump in traffic that quarter alone. This "historical event" would in my memory be the genesis of the 100% traffic growth in 100 days legend. (So it was only 70% in 90 days which for the marketing folks does not cut it so 100% in 100 days sounds much better?? :) ) MCI bought MFS-Datanet because MCI had the customers and MFS-Datanet had all of the fiber running to key locations at the time and could drastically cut MCI's costs. UUNET "merged" with MCI and their traffic was put on this same network. MCI went belly up and Verizon bought the network. Personal Note: from 1983 to 90 I worked for Hayes the modem folks and became the Godfather to Ascend communications with Jeanette, Rob, Jay and Steve whose team produced the TNT line of modem/ISDN to Ethernet central site concentrators (in the early ninties) that drove a large portion of the user traffic to the Internet at the time, generating the "bubble". John (ISDN) Lee ________________________________________ From: Andrew Odlyzko [odlyzko at umn.edu] Sent: Wednesday, August 11, 2010 12:55 PM To: nanog at nanog.org Subject: off-topic: summary on Internet traffic growth myths Since several members of this list requested it, here is a summary of the responses to my request for information about Internet growth during the telecom bubble, in particular the perceptions of the O'Dell/Sidgmore/WorldCom/UUNet "Internet doubling every 100 days" myth. First of all, many thanks to all those who responded, on and off-list. This involved extensive correspondence and some long phone conversations, and helped fill out the picture of those very confusing times (and also made it even clearer than before that there were many different perspectives on what was happening). The entire message is rather long, but it is written in sections, to make it easy to get the gist quickly and neglect the rest. Andrew ------------------------------------------------------------------- 1. Short summary: People who got into the game late, or had been working at small ISPs or other enterprises, were generally willing to give serious credence to the "Internet doubling every 100 days" tale. The old-timers, especially those who worked for large ISPs or other large corporate establishment or research networks, were convinced by the late 1990s that this tale was false, but did not talk about it publicly, even inside the NANOG community. ------------------------------------------------------------------- 2. Longer version: The range of views was very wide, and hard to give justice to in full. But there seemed to be two distinct groups, and the consensus views (which obviously exclude quite a few people) appear to have been: 2A: Those who entered the field in the late 1990s, especially if they worked for small ISPs or other small enterprises, tended to regard the claim seriously. (But it should be remarked that hardly anybody devoted too much effort or thought to the claim, they were too busy putting out fires in their own backyards to worry about global issues.) They remembered periods of desperate efforts to keep up with exploding demand in their businesses. We saw just a few hours ago a post about LINX growing 5.5x in one year. Somebody else wrote about growing their business's traffic 1,000x in 2 years, or about 30x per year. People involved in such incidents often tended to think that their experience during such times might not have been untypical. 2B: Those who worked at places with large traffic, and especially those who got into the field in the early 1990s, were quite sure by the late 1990s that the UUNet fable was just that. Comments regarding everything emanating from UUNet during that period included phrases like "blowing smoke," "rolling our eyes," "taking it with a rock of salt." They had no direct knowledge of what went on inside UUNet, but from watching peering traffic, talking to salespeople about customer losses and wins, and to suppliers about deliveries of equipment, they could be pretty certain that neither the traffic nor the capacity of UUNet could be exploding at the mythical rates. They could see occasional spikes in traffic growth at some customers, or in some parts of their networks, but overall could see traffic growth settling down to a fairly regular doubling or a bit more than doubling each year. However, they did not discuss this in public, and I discuss that below, in point #4. ------------------------------------------------------------------- 3. Growth spurt in mid-1990s: The old-timers also provided very informative feedback about the global Internet traffic growth spurt in the 1995-96 time frame. It did hit suddenly and unexpectedly. (I am still trying to get confirmation on this, but I believe one of the informants said that before this period, the engineers at that person's Tier-1 ISP would routinely double the forecasts provided by the marketing team. At the peak of the bubble, the marketers would demand that the engineers plan for double the capacity that the engineers thought was going to be necessary.) Moreover, the dramatic slowdown in traffic growth that took place in 1997 was, at least in a number of cases, due substantially to a capacity crunch. Router and photonic equipment manufacturers did not have the technology needed for the traffic, and ILECs were slow in supplying access as well as backbone links. Hence the traffic growth spurt in 1996-96 was followed by a capacity growth spurt in 1997-98, which helped provide more credibility for the myth. ------------------------------------------------------------------- 4. Information viscosity: This incident provides far more information confirming the concept of "information viscosity" that I wrote about in my paper, that important and relevant information was available, but was not widely dispersed. Why did the information that Internet traffic was not doubling every 100 days get out to the public? It was not a closely guarded national security secret, after all. There seemed to be many reasons operating. In the case of Genuity (as the quote from Scott Marcus in my paper explains) it was a high-level decision, that going public would hurt the company, as it might be suspected of losing market share. But that seemed to be unusual, in that Genuity, while a major Tier-1 ISP, was small and independent, and so had people like Scott who were engineers, yet involved in policy making. At other places, other dynamics operated. At AT&T, for example, I was called in to a meeting with the management of WorldNet, the AT&T ISP unit, at the end of 2000. They had been telling their customers that Internet traffic was growing 10x per year, and some of those customers asked them about the discrepancy between that claim and the estimates of some folks from AT&T Labs - Research (Kerry Coffman and myself) that growth was just 2x per year. Now it is an interesting perspective on "information viscosity" and AT&T (and other large bureaucratic organizations) that those folks had not heard of Kerry's and my work, even though we had publicized it at the company. But in any event, at that meeting, I did succeed in convincing them that Internet traffic was growing only 2x per year (using evidence in my papers with Kerry, as well as extensive additional data from within AT&T itself), and they agreed they would not propagate the myth among customers. But the interesting thing was that many of the attendees (who included quite a few engineering types, not just the management) seemed disappointed. That really surprised me. After all, AT&T's Internet traffic was growing just about 4x per year, which meant our market share was doubling, instead of being cut in half. But it seems that many of them had really bought into the Internet dream. And, furthermore, the story that we were losing market share was a good one to pry additional resources from the corporation. Several of the NANOG old-timers said that they felt constrained from speaking about the falsity of the myth of astronomical growth rates by group solidarity. After all, it was a small, select group, and bad-mouthing one of their own in front of outsiders or even NANOG newbies did not seem the right thing to do. Then there was the additional factor that one person discussed very explicitly, and that I infer also applied in other cases. The myth was useful. Back in the mid-1990s, when it was not a myth, it did spur equipment suppliers and ILECs to greater effort. And afterwards, it was handy in internal fights over power and resources. If the Internet was exploding, one should not worry about closely examining expansion plans. In some ways, the persistence of false perceptions about Internet traffic growth mirrors that of utilization rates of data networks. When I wrote the paper "Data networks are lightly utilized, and will stay that way," back in 1998, http://www.dtc.umn.edu/~odlyzko/doc/network.utilization.pdf the more clueful data network engineers all knew that utilization rates were generally low, and usually had a good understanding as to why. But top management, as well as the research community, were almost uniformly convinced that congestion was the rule. It took me a while to understand the dynamics of the situation, in which network engineers and managers found it easier to say that they were experiencing 80% utilization and 20% packet losses and needed to upgrade, without having to explain to CEOs, CIOs, and especially to clueless CFOs, that this referred just to the peak hour on one crucial corporate WAN link, and yet justified a big new investment. Few people were lying, but many had incentives to maintain delusions among the top levels of the hierarchy. These demonstrations of information viscosity of course undermine the foundations of much of modern economics, especially of the efficient markets hypothesis. But that last myth is even more durable than "Internet traffic doubling every 100 days," especially since it does not lead directly to lots of dark fiber lying around unused, and lots of companies bankrupt. Information viscosity in facts and ideas in economics is very high, so we should not expect any changes on that scene. ------------------------------------------------------------------- 5. As a reminder, the paper that led to this discussion is "Bubbles, gullibility, and other challenges for economics, psychology, sociology, and information sciences," http://www.dtc.umn.edu/~odlyzko/doc/mania03.pdf The page with source materials from the bubbles times, http://www.dtc.umn.edu/~odlyzko/isources/ now has, in addition to a transcript of the O'Dell lecture at Stanford in May 2000, a copy of the Sidgmore paper from the Vortex98 Conference of May 1998. From david at ulevitch.com Wed Aug 11 14:00:12 2010 From: david at ulevitch.com (David Ulevitch) Date: Wed, 11 Aug 2010 12:00:12 -0700 Subject: Cost of transit and options in APAC Message-ID: Hi Nanog, As we extend our reach into Asia, we're finding that our typical carriers (see: upstreams of AS36692) who provide service to us in North America and Europe are not able to offer us service in Asia either (1) at all or (2) at prices remotely resembling our pricing in NA and EU. For example: Level(3) simply has no presence in Asia and on the pricing side, NTT, GBLX, Verizon and others' pricing is many times higher than their NA and EU pricing. In most cases, it's 10 or more times higher. Additionally, some of the networks seem to market their network based on their reach into the US, rather than their reach into actual users in Asia, which is what we're looking for. So my question is, what are non-APAC-based networks doing as they expand into Asia for transit beyond peering with whomever will peer with them to get close to actual users in Asia? Are people using regional carriers? Are people just paying the "crazy" (compared to US pricing) bandwidth costs? Are people doing peering-only setups out there? Any help would be useful -- hopefully this is on-topic for NANOG, which I think it is, since I'm curious how NA operators deal with these challenges as they expand into APAC. I'm happy to summarize responses later if there is interest. Thanks, David From cboyd at gizmopartners.com Wed Aug 11 14:10:05 2010 From: cboyd at gizmopartners.com (Chris Boyd) Date: Wed, 11 Aug 2010 14:10:05 -0500 Subject: off-topic: summary on Internet traffic growth History In-Reply-To: <53A6C7E936ED8544B1A2BC990D254F946FC6040B0B@MEMEXG1.HOST.local> References: <53A6C7E936ED8544B1A2BC990D254F946FC6040B0B@MEMEXG1.HOST.local> Message-ID: <06D9EF2B-8D2E-4F7F-995C-4D7D3831FF57@gizmopartners.com> On Aug 11, 2010, at 1:13 PM, John Lee wrote: > MCI bought MFS-Datanet because MCI had the customers and MFS-Datanet had all of the fiber running to key locations at the time and could drastically cut MCI's costs. UUNET "merged" with MCI and their traffic was put on this same network. MCI went belly up and Verizon bought the network. Although not directly involved in the MCI Internet operations, I read all the announcements that came across the email when I worked at MCI from early 1993 to late 1998. My recollection is that Worldcom bought out MFS. UUnet was a later acquisition by the Worldcom monster (no, no biases here :-). While this was going on MCI was building and running what was called the BIPP (Basic IP Platform) internally. That product was at least reasonably successful, enough so that some gummint powers that be required divestiture of the BIPP from the company that would come out of the proposed acquisition of MCI by Worldcom. The regulators felt that Worldcom would have too large a share of the North American Internet traffic. The BIPP went with BT IIRC, and I think finally landed in Global Crossing's assets. --Chris From brunner at nic-naa.net Wed Aug 11 14:27:05 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 11 Aug 2010 15:27:05 -0400 Subject: I slogged through it so you don't have to -- ICANN Vertical Integration WG for dummies In-Reply-To: <4C4D9CA6.1040201@nic-naa.net> References: <4C2DF0F8.9060909@abenaki.wabanaki.net> <4C4D9CA6.1040201@nic-naa.net> Message-ID: <4C62F989.4090807@nic-naa.net> The window for comments closes tomorrow. Of course, the window for comments that somehow paint ICANN as a bastion of fools never closes, but anyone in the access and above business that opines on the structure, and interests, of registrars and registries, who opines after tomorrow, but not before tomorrow, is pretty much null routed. The public comments mailbox is vi-pdp-initial-report at icann.org Eric From randy.whitney at verizonbusiness.com Wed Aug 11 14:28:21 2010 From: randy.whitney at verizonbusiness.com (Randy Whitney) Date: Wed, 11 Aug 2010 15:28:21 -0400 Subject: off-topic: summary on Internet traffic growth History In-Reply-To: <06D9EF2B-8D2E-4F7F-995C-4D7D3831FF57@gizmopartners.com> References: <53A6C7E936ED8544B1A2BC990D254F946FC6040B0B@MEMEXG1.HOST.local> <06D9EF2B-8D2E-4F7F-995C-4D7D3831FF57@gizmopartners.com> Message-ID: <4C62F9D5.4090309@verizonbusiness.com> On 8/11/2010 3:10 PM, Chris Boyd wrote: > > On Aug 11, 2010, at 1:13 PM, John Lee wrote: > >> MCI bought MFS-Datanet because MCI had the customers and >> MFS-Datanet had all of the fiber running to key locations at the >> time and could drastically cut MCI's costs. UUNET "merged" with MCI >> and their traffic was put on this same network. MCI went belly up >> and Verizon bought the network. > > Although not directly involved in the MCI Internet operations, I read > all the announcements that came across the email when I worked at MCI > from early 1993 to late 1998. > > My recollection is that Worldcom bought out MFS. UUnet was a later > acquisition by the Worldcom monster (no, no biases here :-). While > this was going on MCI was building and running what was called the > BIPP (Basic IP Platform) internally. That product was at least > reasonably successful, enough so that some gummint powers that be > required divestiture of the BIPP from the company that would come out > of the proposed acquisition of MCI by Worldcom. The regulators felt > that Worldcom would have too large a share of the North American > Internet traffic. The BIPP went with BT IIRC, and I think finally > landed in Global Crossing's assets. > > --Chris Correct order of (in)digestion UUNet > MFS > Worldcom >< MCI > Verizon. There were other multi-way acquisitions in-between as well (CNS, ANS, etc.) -Randy. From franck at genius.com Wed Aug 11 14:29:37 2010 From: franck at genius.com (Franck Martin) Date: Thu, 12 Aug 2010 07:29:37 +1200 (FJT) Subject: Cost of transit and options in APAC In-Reply-To: Message-ID: <13485638.719.1281554976626.JavaMail.franck@franck-martins-macbook-pro.local> Nice to see this change.... APAC has been obliged to pay the cost to peer with the US (long distance links are expensive). Now that US wants to peer with Asia, pricing may become more balanced... ----- Original Message ----- From: "David Ulevitch" To: nanog at merit.edu Sent: Thursday, 12 August, 2010 7:00:12 AM Subject: Cost of transit and options in APAC Hi Nanog, As we extend our reach into Asia, we're finding that our typical carriers (see: upstreams of AS36692) who provide service to us in North America and Europe are not able to offer us service in Asia either (1) at all or (2) at prices remotely resembling our pricing in NA and EU. For example: Level(3) simply has no presence in Asia and on the pricing side, NTT, GBLX, Verizon and others' pricing is many times higher than their NA and EU pricing. In most cases, it's 10 or more times higher. Additionally, some of the networks seem to market their network based on their reach into the US, rather than their reach into actual users in Asia, which is what we're looking for. So my question is, what are non-APAC-based networks doing as they expand into Asia for transit beyond peering with whomever will peer with them to get close to actual users in Asia? Are people using regional carriers? Are people just paying the "crazy" (compared to US pricing) bandwidth costs? Are people doing peering-only setups out there? Any help would be useful -- hopefully this is on-topic for NANOG, which I think it is, since I'm curious how NA operators deal with these challenges as they expand into APAC. I'm happy to summarize responses later if there is interest. Thanks, David From rs at seastrom.com Wed Aug 11 14:30:37 2010 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 11 Aug 2010 15:30:37 -0400 Subject: off-topic: summary on Internet traffic growth History In-Reply-To: <06D9EF2B-8D2E-4F7F-995C-4D7D3831FF57@gizmopartners.com> (Chris Boyd's message of "Wed, 11 Aug 2010 14:10:05 -0500") References: <53A6C7E936ED8544B1A2BC990D254F946FC6040B0B@MEMEXG1.HOST.local> <06D9EF2B-8D2E-4F7F-995C-4D7D3831FF57@gizmopartners.com> Message-ID: <86pqxp0wwy.fsf@seastrom.com> Chris Boyd writes: > My recollection is that Worldcom bought out MFS. UUnet was a later > acquisition by the Worldcom monster (no, no biases here :-). MFS acquired UUnet Technologies on 12 August 1996. On 31 December 1996, MFS "merged with and into WorldCom, Inc" although it sure looked like an acquisition to those of us who were watching from the sidelines. -r From odlyzko at umn.edu Wed Aug 11 14:34:56 2010 From: odlyzko at umn.edu (Andrew Odlyzko) Date: Wed, 11 Aug 2010 14:34:56 -0500 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: <434568.49696.qm@web53008.mail.re2.yahoo.com> References: <604794.12749.qm@web53002.mail.re2.yahoo.com> <434568.49696.qm@web53008.mail.re2.yahoo.com> Message-ID: <4c62fb60.T6x6wa1RjtSJLDre%odlyzko@umn.edu> Jessica, As I explained in an email in response to your earlier posting, my paper makes it very clear that Mike O'Dell and John Sidgmore were, for most of the time in the 1997-2001 time frame, talking of a doubling every 100 days of capacity, not traffic, and only for UUNet. (In fact, the Sidgmore paper from Vortex98 that I have just posted, at http://www.dtc.umn.edu/~odlyzko/isources/sidgmore-vortex98b.pdf, has him saying pretty explicitly that UUNet was gaining market share, and the rest of the industry was growing more slowly.) However, the press, and the public, assumed that the traffic of the entire Internet was growing at those rates. How people could make such a mistake is a mystery that I point out as a mystery in my paper. In fact, the Sidgmore paper has an interesting exchange. In the Q&A session (included in the paper), Bob Lucky asks Sidgmore about traffic growth, clearly assuming that Sidgmore had been talking of traffic. Sidgmore responds, very clearly talking about capacity, but clearly assuming that Lucky had asked about capacity. So here we have a record of two people, both industry insiders, talking past each other. Another mystery to add to the others. If you want to get into this further, let's take the discussion off-list, as I doubt this picayune non-operational matter will interest too many folks here. Best regards, Andrew Jessica Yu wrote: > Wait a sec, you seems to assume that the 'Doubling every 100 days" statement > was?referring?to the Internet traffic not just UUNet traffic.? My recollection > was that?the statement?was referring to UUNet traffic based on the stats > collected in a period of time (see my previous email).?That is why I urged the > author of the paper?to make this important distinction.? If one made a > prediction based on?stats collected?and the prediction was not accurate due to > the imperfection of stats (in this case, it may be caused by a short term > growth?abnormally, as Jeff Young pointed out), it is unfair to assume the person > misled?public on purpose. > > Thanks! > > --Jessica > > > > ________________________________ > From: Kenny Sallee > To: Jessica Yu ; Andrew Odlyzko > Cc: nanog at nanog.org > Sent: Mon, August 9, 2010 4:01:00 PM > Subject: Re: off-topic: historical query concerning the Internet bubble > > > > > > On Fri, Aug 6, 2010 at 2:52 PM, Jessica Yu wrote: > I do not know if making such distinction would alter the conclusion of your > >paper.? But, to me, there is a difference between one to predict the growth of > >one particular network based on the stats collected than?one to predict?the > >growth of the entire Internet with no solid data. > >Thanks!--Jessica > > > Agree with Jessica: you can't say the 'Internet' doubles every x number of > days/amount of time no matter what the number of days or amount of time is. ?The > 'Internet' is a series of tubes...hahaha couldn't help it....As we all know the > Internet is a bunch of providers plugged into each other. ?Provider A may see an > 10x increase in traffic every month while provider B may not. ?For example, if > Google makes a deal with Verizon only Verizon will see a huge increase in > traffic internally and less externally (or?vice?versa). ?Until Google goes > somewhere else! ?So the whole 'myth' of Internet doubling every 100 days to me > is something someone (ODell it seems) made up to appease someone higher in the > chain or a government committee that really doesn't get it. ?IE - it's marketing > talk to quantify something. ?I guess if all the ISP's in the world provided a > central repository bandwidth numbers they have on their backbone then you could > make up some stats about Internet traffic as a whole. ?But without that - it > just doesn't make much sense. > > > > Just my .02 > Kenny > > > > From joelja at bogus.com Wed Aug 11 14:53:18 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 11 Aug 2010 12:53:18 -0700 Subject: Cost of transit and options in APAC In-Reply-To: <13485638.719.1281554976626.JavaMail.franck@franck-martins-macbook-pro.local> References: <13485638.719.1281554976626.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4C62FFAE.1090608@bogus.com> On 8/11/10 12:29 PM, Franck Martin wrote: > Nice to see this change.... > > APAC has been obliged to pay the cost to peer with the US (long > distance links are expensive). Now that US wants to peer with Asia, > pricing may become more balanced... I think the question is more like why am I being quoted $100 A megabit in India for transit in India? Not why am I being charged for for the transport cost across the pacific. The answer has more to do with the maturity of comms infrastructure, the cost of captial, and regulatory or monopoloy capture than it does with some artifical lack of price equilibrium. > ----- Original Message ----- From: "David Ulevitch" > To: nanog at merit.edu Sent: Thursday, 12 August, > 2010 7:00:12 AM Subject: Cost of transit and options in APAC > > Hi Nanog, > > As we extend our reach into Asia, we're finding that our typical > carriers (see: upstreams of AS36692) who provide service to us in > North America and Europe are not able to offer us service in Asia > either (1) at all or (2) at prices remotely resembling our pricing > in NA and EU. For example: Level(3) simply has no presence in Asia > and on the pricing side, NTT, GBLX, Verizon and others' pricing is > many times higher than their NA and EU pricing. In most cases, it's > 10 or more times higher. > > Additionally, some of the networks seem to market their network > based on their reach into the US, rather than their reach into actual > users in Asia, which is what we're looking for. > > So my question is, what are non-APAC-based networks doing as they > expand into Asia for transit beyond peering with whomever will peer > with them to get close to actual users in Asia? > > Are people using regional carriers? Are people just paying the > "crazy" (compared to US pricing) bandwidth costs? Are people doing > peering-only setups out there? Any help would be useful -- > hopefully this is on-topic for NANOG, which I think it is, since I'm > curious how NA operators deal with these challenges as they expand > into APAC. > > I'm happy to summarize responses later if there is interest. > > Thanks, David > > From tme at americafree.tv Wed Aug 11 15:24:18 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Wed, 11 Aug 2010 16:24:18 -0400 Subject: off-topic: summary on Internet traffic growth History In-Reply-To: <4C62F9D5.4090309@verizonbusiness.com> References: <53A6C7E936ED8544B1A2BC990D254F946FC6040B0B@MEMEXG1.HOST.local> <06D9EF2B-8D2E-4F7F-995C-4D7D3831FF57@gizmopartners.com> <4C62F9D5.4090309@verizonbusiness.com> Message-ID: On Aug 11, 2010, at 3:28 PM, Randy Whitney wrote: > On 8/11/2010 3:10 PM, Chris Boyd wrote: >> >> On Aug 11, 2010, at 1:13 PM, John Lee wrote: >> >>> MCI bought MFS-Datanet because MCI had the customers and >>> MFS-Datanet had all of the fiber running to key locations at the >>> time and could drastically cut MCI's costs. UUNET "merged" with MCI >>> and their traffic was put on this same network. MCI went belly up >>> and Verizon bought the network. >> >> Although not directly involved in the MCI Internet operations, I read >> all the announcements that came across the email when I worked at MCI >> from early 1993 to late 1998. >> >> My recollection is that Worldcom bought out MFS. UUnet was a later >> acquisition by the Worldcom monster (no, no biases here :-). While >> this was going on MCI was building and running what was called the >> BIPP (Basic IP Platform) internally. That product was at least >> reasonably successful, enough so that some gummint powers that be >> required divestiture of the BIPP from the company that would come out >> of the proposed acquisition of MCI by Worldcom. The regulators felt >> that Worldcom would have too large a share of the North American >> Internet traffic. The BIPP went with BT IIRC, and I think finally >> landed in Global Crossing's assets. What happened to VBNS in all of this ? Marshall >> >> --Chris > > Correct order of (in)digestion UUNet > MFS > Worldcom >< MCI > Verizon. > > There were other multi-way acquisitions in-between as well (CNS, ANS, etc.) > > -Randy. > > > From brent at servuhome.net Wed Aug 11 15:47:55 2010 From: brent at servuhome.net (Brent Jones) Date: Wed, 11 Aug 2010 13:47:55 -0700 Subject: MPLS providers between Portland OR and NYC Message-ID: Does anyone have any recommendations or experience to share about any L2 providers in the Portland OR, and NYC markets? Specifically, providers that can do 1Gbit between those cities, with reasonable SLAs. Comments off-list would be greatly appreciated! -- Brent Jones brent at servuhome.net From christopher.p.hart at gmail.com Wed Aug 11 15:50:12 2010 From: christopher.p.hart at gmail.com (Christopher Hart) Date: Wed, 11 Aug 2010 13:50:12 -0700 Subject: Cost of transit and options in APAC In-Reply-To: <4C62FFAE.1090608@bogus.com> References: <13485638.719.1281554976626.JavaMail.franck@franck-martins-macbook-pro.local> <4C62FFAE.1090608@bogus.com> Message-ID: "...the cost of captial, and regulatory or monopoloy capture than it does with some artifical lack of price equilibrium." now that sounds like fodder for a different list ;) On Wed, Aug 11, 2010 at 12:53 PM, Joel Jaeggli wrote: > On 8/11/10 12:29 PM, Franck Martin wrote: > > Nice to see this change.... > > > > APAC has been obliged to pay the cost to peer with the US (long > > distance links are expensive). Now that US wants to peer with Asia, > > pricing may become more balanced... > > I think the question is more like why am I being quoted $100 A megabit > in India for transit in India? Not why am I being charged for for the > transport cost across the pacific. > > The answer has more to do with the maturity of comms infrastructure, the > cost of captial, and regulatory or monopoloy capture than it does with > some artifical lack of price equilibrium. > > > ----- Original Message ----- From: "David Ulevitch" > > To: nanog at merit.edu Sent: Thursday, 12 August, > > 2010 7:00:12 AM Subject: Cost of transit and options in APAC > > > > Hi Nanog, > > > > As we extend our reach into Asia, we're finding that our typical > > carriers (see: upstreams of AS36692) who provide service to us in > > North America and Europe are not able to offer us service in Asia > > either (1) at all or (2) at prices remotely resembling our pricing > > in NA and EU. For example: Level(3) simply has no presence in Asia > > and on the pricing side, NTT, GBLX, Verizon and others' pricing is > > many times higher than their NA and EU pricing. In most cases, it's > > 10 or more times higher. > > > > Additionally, some of the networks seem to market their network > > based on their reach into the US, rather than their reach into actual > > users in Asia, which is what we're looking for. > > > > So my question is, what are non-APAC-based networks doing as they > > expand into Asia for transit beyond peering with whomever will peer > > with them to get close to actual users in Asia? > > > > Are people using regional carriers? Are people just paying the > > "crazy" (compared to US pricing) bandwidth costs? Are people doing > > peering-only setups out there? Any help would be useful -- > > hopefully this is on-topic for NANOG, which I think it is, since I'm > > curious how NA operators deal with these challenges as they expand > > into APAC. > > > > I'm happy to summarize responses later if there is interest. > > > > Thanks, David > > > > > > > -- Respectfully, Chris Hart Developer / System Administrator Insuremonkey.com 2080 E. Flamingo, Suite 223 Las Vegas, NV 89119 From bensons at queuefull.net Wed Aug 11 16:03:34 2010 From: bensons at queuefull.net (Benson Schliesser) Date: Wed, 11 Aug 2010 16:03:34 -0500 Subject: Cost of transit and options in APAC In-Reply-To: <4C62FFAE.1090608@bogus.com> References: <13485638.719.1281554976626.JavaMail.franck@franck-martins-macbook-pro.local> <4C62FFAE.1090608@bogus.com> Message-ID: <01FC6493-65A8-45D6-809A-06C65565F4B9@queuefull.net> On 11 Aug 10, at 2:53 PM, Joel Jaeggli wrote: > I think the question is more like why am I being quoted $100 A megabit > in India for transit in India? Not why am I being charged for for the > transport cost across the pacific. Obviously I can't speak for the providers in question, but I'd guess that the cost for transit in AP is strongly related to the cost of long-haul transport. Once upon a time, the majority of Internet traffic in AP countries *did* originate in the US. Does anybody have data that this is changing? Cheers, -Benson From leigh.porter at ukbroadband.com Wed Aug 11 17:02:22 2010 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 11 Aug 2010 23:02:22 +0100 Subject: Cost of transit and options in APAC In-Reply-To: <01FC6493-65A8-45D6-809A-06C65565F4B9@queuefull.net> References: <13485638.719.1281554976626.JavaMail.franck@franck-martins-macbook-pro.local> <4C62FFAE.1090608@bogus.com> <01FC6493-65A8-45D6-809A-06C65565F4B9@queuefull.net> Message-ID: <52AAF7ED-9C00-4025-A41C-69080EC6BF34@ukbroadband.com> On 11 Aug 2010, at 22:03, Benson Schliesser wrote: > > On 11 Aug 10, at 2:53 PM, Joel Jaeggli wrote: > >> I think the question is more like why am I being quoted $100 A megabit >> in India for transit in India? Not why am I being charged for for the >> transport cost across the pacific. > > Obviously I can't speak for the providers in question, but I'd guess that the cost for transit in AP is strongly related to the cost of long-haul transport. Once upon a time, the majority of Internet traffic in AP countries *did* originate in the US. Does anybody have data that this is changing? > > Cheers, > -Benson > > > Well, it would be hard to change because who would host in country when it costs so much to do so. It'd be much cheaper to host out of the country thereby exasperating the whole problem. -- Leigh Porter From franck at genius.com Wed Aug 11 17:07:51 2010 From: franck at genius.com (Franck Martin) Date: Thu, 12 Aug 2010 10:07:51 +1200 (FJT) Subject: Cost of transit and options in APAC In-Reply-To: <01FC6493-65A8-45D6-809A-06C65565F4B9@queuefull.net> Message-ID: <28139604.27.1281564468225.JavaMail.franck@franck-martins-macbook-pro.local> My feeling is that the Chinese market suffice to its own needs, now that all the major websites have their equivalent in Chinese and are more popular than the Chinese translation of US/EU based web sites. I have heard of large data Centres being built in AP. Google spoke at one time to do its own trans-pacific link, because it could not find anything suitable. I guess the location of akamai caches could be telling... I may also suspect economical models of trans-pacific fiber may be different from economical model for trans-atlantic fiber, which would explain difference in costs. I have heard of things like that, but don't have firm data. So it is empirical data, but I think things are changing. Understanding the landscape and the reason behind the costs may help negotiate a better deal. Finally, have you considered peering with Australia to see if it gives you access to the AP market at better cost? ----- Original Message ----- From: "Benson Schliesser" To: "Joel Jaeggli" , "Franck Martin" , "nanog" Sent: Thursday, 12 August, 2010 9:03:34 AM Subject: Re: Cost of transit and options in APAC On 11 Aug 10, at 2:53 PM, Joel Jaeggli wrote: > I think the question is more like why am I being quoted $100 A megabit > in India for transit in India? Not why am I being charged for for the > transport cost across the pacific. Obviously I can't speak for the providers in question, but I'd guess that the cost for transit in AP is strongly related to the cost of long-haul transport. Once upon a time, the majority of Internet traffic in AP countries *did* originate in the US. Does anybody have data that this is changing? Cheers, -Benson From joelja at bogus.com Wed Aug 11 17:15:22 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 11 Aug 2010 15:15:22 -0700 Subject: Cost of transit and options in APAC In-Reply-To: <01FC6493-65A8-45D6-809A-06C65565F4B9@queuefull.net> References: <13485638.719.1281554976626.JavaMail.franck@franck-martins-macbook-pro.local> <4C62FFAE.1090608@bogus.com> <01FC6493-65A8-45D6-809A-06C65565F4B9@queuefull.net> Message-ID: <4C6320FA.80901@bogus.com> On 8/11/10 2:03 PM, Benson Schliesser wrote: > > On 11 Aug 10, at 2:53 PM, Joel Jaeggli wrote: > >> I think the question is more like why am I being quoted $100 A >> megabit in India for transit in India? Not why am I being charged >> for for the transport cost across the pacific. > > Obviously I can't speak for the providers in question, but I'd guess > that the cost for transit in AP is strongly related to the cost of > long-haul transport. Start with something that can be effectively isolated from the transpacific path. Gotten a quote for a 1Gbe or 10Gbe between two cities in India recently? map that onto what you'd pay for a similar path in the US, count the extra zeros (once you account for the fact that INR is 46.91 to the dollar). > Once upon a time, the majority of Internet > traffic in AP countries *did* originate in the US. Does anybody have > data that this is changing? > Cheers, -Benson > > > From bensons at queuefull.net Wed Aug 11 17:20:57 2010 From: bensons at queuefull.net (Benson Schliesser) Date: Wed, 11 Aug 2010 17:20:57 -0500 Subject: off-topic: summary on Internet traffic growth History In-Reply-To: <06D9EF2B-8D2E-4F7F-995C-4D7D3831FF57@gizmopartners.com> References: <53A6C7E936ED8544B1A2BC990D254F946FC6040B0B@MEMEXG1.HOST.local> <06D9EF2B-8D2E-4F7F-995C-4D7D3831FF57@gizmopartners.com> Message-ID: <2594B329-0822-4933-9D61-F14979ABC502@queuefull.net> On 11 Aug 10, at 2:10 PM, Chris Boyd wrote: > My recollection is that Worldcom bought out MFS. UUnet was a later acquisition by the Worldcom monster (no, no biases here :-). While this was going on MCI was building and running what was called the BIPP (Basic IP Platform) internally. That product was at least reasonably successful, enough so that some gummint powers that be required divestiture of the BIPP from the company that would come out of the proposed acquisition of MCI by Worldcom. The regulators felt that Worldcom would have too large a share of the North American Internet traffic. The BIPP went with BT IIRC, and I think finally landed in Global Crossing's assets. Actually, Cable & Wireless acquired the BIPP after regulators forced Worldcom to divest one of their networks. C&W developed a new network architecture as an evolution of BIPP called "N3", based on MPLS as an ATM replacement for TE. (Perhaps somebody that worked at C&W back then can comment on N3; I can't recall what it stood for.) After a few years, C&W reorganized their American operations into a separate entity, which subsequently went bankrupt. Savvis (my current employer) bought the assets out of bankruptcy court. We then upgraded the N3 network to support better QoS, higher capacity, etc, and call it the "ATN" (Application Transport Network). The current Savvis core network, AS3561, is thus the evolved offspring of the MCI Internet Services / Internet-MCI network. Of course, before all of this, MCI built the network as a commercial Internet platform in parallel to their ARPA network. That's before my time, unfortunately, so I don't know many details. For instance I'm uncertain how the ASN has changed over the years. Anybody with more history and/or corrections would be appreciated. Cheers, -Benson From bensons at queuefull.net Wed Aug 11 17:41:16 2010 From: bensons at queuefull.net (Benson Schliesser) Date: Wed, 11 Aug 2010 17:41:16 -0500 Subject: Cost of transit and options in APAC In-Reply-To: <4C6320FA.80901@bogus.com> References: <13485638.719.1281554976626.JavaMail.franck@franck-martins-macbook-pro.local> <4C62FFAE.1090608@bogus.com> <01FC6493-65A8-45D6-809A-06C65565F4B9@queuefull.net> <4C6320FA.80901@bogus.com> Message-ID: On 11 Aug 10, at 5:15 PM, Joel Jaeggli wrote: >> Obviously I can't speak for the providers in question, but I'd guess >> that the cost for transit in AP is strongly related to the cost of >> long-haul transport. > > Start with something that can be effectively isolated from the > transpacific path. > > Gotten a quote for a 1Gbe or 10Gbe between two cities in India recently? That could be useful. Sadly, I have no first-hand knowledge of these costs. How does in-country transport compare to trans-Pacific transport cost? (i.e. on a per Mbps per kilometer or similar metric) I assume it's cheaper in-country / in-region compared to trans-oceanic. Is this true? Once that's known, I'd also look at the opposite: excluding any last-mile transport costs, what is the price per Mbps for transit service? That transit price has to accommodate both the local/in-region transport as well as trans-oceanic transport costs borne by the provider. If the locale of traffic is shifting, then the provider's transport costs are also shifting from one category to another. My advice to anybody looking to buy AP regional transit, assuming that trans-oceanic bandwidth is more expensive than regional bandwidth, is to negotiate a lower price in exchange for only in-region routes. If my assumption about bandwidth costs is backwards, then you're out of luck. (Maybe we need lower taxes, higher bribes, or more competition..?) Cheers, -Benson From nathan at robotics.net Wed Aug 11 17:45:36 2010 From: nathan at robotics.net (Nathan Stratton) Date: Wed, 11 Aug 2010 17:45:36 -0500 (CDT) Subject: Cost of transit and options in APAC In-Reply-To: <52AAF7ED-9C00-4025-A41C-69080EC6BF34@ukbroadband.com> References: <13485638.719.1281554976626.JavaMail.franck@franck-martins-macbook-pro.local> <4C62FFAE.1090608@bogus.com> <01FC6493-65A8-45D6-809A-06C65565F4B9@queuefull.net> <52AAF7ED-9C00-4025-A41C-69080EC6BF34@ukbroadband.com> Message-ID: On Wed, 11 Aug 2010, Leigh Porter wrote: > Well, it would be hard to change because who would host in country when it costs so much to do so. It'd be much cheaper to host out of the country thereby exasperating the whole problem. Well some of us have no choice. We provide hosted video conferencing solutions that require us to be closer to our subscribers. Some providers will lower their rates if you can show them most of your traffic will stay local. ><> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com From gregg at tocici.com Wed Aug 11 17:57:58 2010 From: gregg at tocici.com (Gregg Berkholtz) Date: Wed, 11 Aug 2010 18:57:58 -0400 Subject: Cost of transit and options in APAC In-Reply-To: <01FC6493-65A8-45D6-809A-06C65565F4B9@queuefull.net> References: <13485638.719.1281554976626.JavaMail.franck@franck-martins-macbook-pro.local> <4C62FFAE.1090608@bogus.com> <01FC6493-65A8-45D6-809A-06C65565F4B9@queuefull.net> Message-ID: <6008F4EA-7E4C-441E-A8A7-ADCB10E63A29@tocici.com> Around 40% of our low-end/budget VPS hosting customers are based in APAC. It's common for departing customers to cite the primary reason as seeking lower latency to their regions. Sent while on the go, please excuse terseness. On Aug 11, 2010, at 17:03, Benson Schliesser wrote: > > On 11 Aug 10, at 2:53 PM, Joel Jaeggli wrote: > >> I think the question is more like why am I being quoted $100 A megabit >> in India for transit in India? Not why am I being charged for for the >> transport cost across the pacific. > > Obviously I can't speak for the providers in question, but I'd guess that the cost for transit in AP is strongly related to the cost of long-haul transport. Once upon a time, the majority of Internet traffic in AP countries *did* originate in the US. Does anybody have data that this is changing? > > Cheers, > -Benson > > > From young at jsyoung.net Wed Aug 11 18:26:29 2010 From: young at jsyoung.net (Jeffrey S. Young) Date: Thu, 12 Aug 2010 09:26:29 +1000 Subject: off-topic: summary on Internet traffic growth History In-Reply-To: <53A6C7E936ED8544B1A2BC990D254F946FC6040B0B@MEMEXG1.HOST.local> References: <53A6C7E936ED8544B1A2BC990D254F946FC6040B0B@MEMEXG1.HOST.local> Message-ID: Worldcom bought MFS. Worldcom bought MCI. Worldcom bought UUnet. In your statement s/MCI/Worldcom/g I don't know if UUnet was part of Worldcom when MO first made statements about backbone growth, but I do know that internetMCI was still part of MCI and therefore, MCI was not a part of Worldcom. May seem like splitting hairs to some, but it is important to a few of us to point out that we never worked under Ebbers. Not that we had a choice :-). Growth of the NAPs during this period is a poor indicator of growth. Because of the glitch you mention in carrying capacity the tier 1's all but abandoned the NAPs for peering between themselves and from that point forward (mid '97) preferred direct peering arrangements. jy On 12/08/2010, at 4:13 AM, John Lee wrote: > Andrew, > > Earlier this week I had a meeting with the ex-Director of the Network Operations Center for MFS-Datanet/MCI whose tenure was through 1999. From 1994 to 1998 they were re-architeching the Frame Relay and ATM networks to handle the growth in traffic including these new facilities called peering points of MAE-East and MAE-West. From roughly 1990 to then end of 1996 they saw traffic on their switches grow at 50-70% growth every 6 months. By the last half of 1996 there was a head of line blocking problem on the DEC FDDI switches that was "regularly" bringing down the Internet. The architecture had lower traffic circuits were going through concentrators while higher traffic circuits were directly attached to ports on the switchs. > > > > MFS-Datanet was not going to take the hit for the interruptions to the Internet and was going to inform the trade press there was a problem with DEC FDDI switches so Digital "gave" six switches for the re-architecture of the MAEs to solve the problem. Once this problem was solved the first quarter of 1997 saw a 70% jump in traffic that quarter alone. This "historical event" would in my memory be the genesis of the 100% traffic growth in 100 days legend. (So it was only 70% in 90 days which for the marketing folks does not cut it so 100% in 100 days sounds much better?? :) ) > > > > MCI bought MFS-Datanet because MCI had the customers and MFS-Datanet had all of the fiber running to key locations at the time and could drastically cut MCI's costs. UUNET "merged" with MCI and their traffic was put on this same network. MCI went belly up and Verizon bought the network. > > > > Personal Note: from 1983 to 90 I worked for Hayes the modem folks and became the Godfather to Ascend communications with Jeanette, Rob, Jay and Steve whose team produced the TNT line of modem/ISDN to Ethernet central site concentrators (in the early ninties) that drove a large portion of the user traffic to the Internet at the time, generating the "bubble". > > > > John (ISDN) Lee > ________________________________________ > From: Andrew Odlyzko [odlyzko at umn.edu] > Sent: Wednesday, August 11, 2010 12:55 PM > To: nanog at nanog.org > Subject: off-topic: summary on Internet traffic growth myths > > Since several members of this list requested it, here is a summary > of the responses to my request for information about Internet growth > during the telecom bubble, in particular the perceptions of the > O'Dell/Sidgmore/WorldCom/UUNet "Internet doubling every 100 days" > myth. > > First of all, many thanks to all those who responded, on and off-list. > This involved extensive correspondence and some long phone conversations, > and helped fill out the picture of those very confusing times (and > also made it even clearer than before that there were many different > perspectives on what was happening). > > The entire message is rather long, but it is written in sections, > to make it easy to get the gist quickly and neglect the rest. > > Andrew > > > ------------------------------------------------------------------- > > 1. Short summary: People who got into the game late, or had been > working at small ISPs or other enterprises, were generally willing > to give serious credence to the "Internet doubling every 100 days" > tale. The old-timers, especially those who worked for large ISPs > or other large corporate establishment or research networks, were > convinced by the late 1990s that this tale was false, but did not > talk about it publicly, even inside the NANOG community. > > ------------------------------------------------------------------- > > 2. Longer version: The range of views was very wide, and hard to > give justice to in full. But there seemed to be two distinct > groups, and the consensus views (which obviously exclude quite > a few people) appear to have been: > > 2A: Those who entered the field in the late 1990s, especially > if they worked for small ISPs or other small enterprises, tended > to regard the claim seriously. (But it should be remarked that > hardly anybody devoted too much effort or thought to the claim, > they were too busy putting out fires in their own backyards to > worry about global issues.) They remembered periods of desperate > efforts to keep up with exploding demand in their businesses. > We saw just a few hours ago a post about LINX growing 5.5x in > one year. Somebody else wrote about growing their business's > traffic 1,000x in 2 years, or about 30x per year. People involved > in such incidents often tended to think that their experience > during such times might not have been untypical. > > 2B: Those who worked at places with large traffic, and especially > those who got into the field in the early 1990s, were quite sure > by the late 1990s that the UUNet fable was just that. Comments > regarding everything emanating from UUNet during that period > included phrases like "blowing smoke," "rolling our eyes," "taking > it with a rock of salt." They had no direct knowledge of what > went on inside UUNet, but from watching peering traffic, talking > to salespeople about customer losses and wins, and to suppliers > about deliveries of equipment, they could be pretty certain that > neither the traffic nor the capacity of UUNet could be exploding > at the mythical rates. They could see occasional spikes in > traffic growth at some customers, or in some parts of their > networks, but overall could see traffic growth settling down > to a fairly regular doubling or a bit more than doubling each > year. > > However, they did not discuss this in public, and I discuss that > below, in point #4. > > ------------------------------------------------------------------- > > 3. Growth spurt in mid-1990s: The old-timers also provided very > informative feedback about the global Internet traffic growth > spurt in the 1995-96 time frame. It did hit suddenly and > unexpectedly. (I am still trying to get confirmation on this, > but I believe one of the informants said that before this > period, the engineers at that person's Tier-1 ISP would routinely > double the forecasts provided by the marketing team. At the peak > of the bubble, the marketers would demand that the engineers plan > for double the capacity that the engineers thought was going > to be necessary.) Moreover, the dramatic slowdown in traffic > growth that took place in 1997 was, at least in a number of > cases, due substantially to a capacity crunch. Router and > photonic equipment manufacturers did not have the technology > needed for the traffic, and ILECs were slow in supplying > access as well as backbone links. Hence the traffic growth > spurt in 1996-96 was followed by a capacity growth spurt > in 1997-98, which helped provide more credibility for the > myth. > > ------------------------------------------------------------------- > > 4. Information viscosity: This incident provides far more > information confirming the concept of "information viscosity" > that I wrote about in my paper, that important and relevant > information was available, but was not widely dispersed. > > Why did the information that Internet traffic was not doubling > every 100 days get out to the public? It was not a closely > guarded national security secret, after all. > > There seemed to be many reasons operating. In the case of > Genuity (as the quote from Scott Marcus in my paper explains) > it was a high-level decision, that going public would hurt > the company, as it might be suspected of losing market share. > But that seemed to be unusual, in that Genuity, while a > major Tier-1 ISP, was small and independent, and so had > people like Scott who were engineers, yet involved in > policy making. At other places, other dynamics operated. > > At AT&T, for example, I was called in to a meeting with > the management of WorldNet, the AT&T ISP unit, at the > end of 2000. They had been telling their customers that > Internet traffic was growing 10x per year, and some of > those customers asked them about the discrepancy between > that claim and the estimates of some folks from AT&T > Labs - Research (Kerry Coffman and myself) that growth > was just 2x per year. Now it is an interesting perspective > on "information viscosity" and AT&T (and other large > bureaucratic organizations) that those folks had not > heard of Kerry's and my work, even though we had publicized > it at the company. But in any event, at that meeting, > I did succeed in convincing them that Internet traffic > was growing only 2x per year (using evidence in my papers > with Kerry, as well as extensive additional data from > within AT&T itself), and they agreed they would not > propagate the myth among customers. But the interesting > thing was that many of the attendees (who included quite > a few engineering types, not just the management) seemed > disappointed. That really surprised me. After all, > AT&T's Internet traffic was growing just about 4x per > year, which meant our market share was doubling, instead > of being cut in half. But it seems that many of them > had really bought into the Internet dream. And, furthermore, > the story that we were losing market share was a good one > to pry additional resources from the corporation. > > Several of the NANOG old-timers said that they felt constrained > from speaking about the falsity of the myth of astronomical > growth rates by group solidarity. After all, it was a > small, select group, and bad-mouthing one of their own > in front of outsiders or even NANOG newbies did not seem > the right thing to do. Then there was the additional > factor that one person discussed very explicitly, and > that I infer also applied in other cases. The myth was > useful. Back in the mid-1990s, when it was not a myth, > it did spur equipment suppliers and ILECs to greater > effort. And afterwards, it was handy in internal fights > over power and resources. If the Internet was exploding, > one should not worry about closely examining expansion > plans. > > In some ways, the persistence of false perceptions about > Internet traffic growth mirrors that of utilization rates > of data networks. When I wrote the paper "Data networks > are lightly utilized, and will stay that way," back in 1998, > > http://www.dtc.umn.edu/~odlyzko/doc/network.utilization.pdf > > the more clueful data network engineers all knew that > utilization rates were generally low, and usually had > a good understanding as to why. But top management, as > well as the research community, were almost uniformly > convinced that congestion was the rule. It took me a > while to understand the dynamics of the situation, in > which network engineers and managers found it easier > to say that they were experiencing 80% utilization and > 20% packet losses and needed to upgrade, without having > to explain to CEOs, CIOs, and especially to clueless > CFOs, that this referred just to the peak hour on one crucial > corporate WAN link, and yet justified a big new investment. > Few people were lying, but many had incentives to maintain > delusions among the top levels of the hierarchy. > > These demonstrations of information viscosity of course > undermine the foundations of much of modern economics, > especially of the efficient markets hypothesis. But that > last myth is even more durable than "Internet traffic > doubling every 100 days," especially since it does not > lead directly to lots of dark fiber lying around unused, > and lots of companies bankrupt. Information viscosity > in facts and ideas in economics is very high, so we > should not expect any changes on that scene. > > > ------------------------------------------------------------------- > > 5. As a reminder, the paper that led to this discussion is > "Bubbles, gullibility, and other challenges for economics, > psychology, sociology, and information sciences," > > http://www.dtc.umn.edu/~odlyzko/doc/mania03.pdf > > The page with source materials from the bubbles times, > > http://www.dtc.umn.edu/~odlyzko/isources/ > > now has, in addition to a transcript of the O'Dell lecture > at Stanford in May 2000, a copy of the Sidgmore paper from > the Vortex98 Conference of May 1998. > From deepak at ai.net Wed Aug 11 18:40:06 2010 From: deepak at ai.net (Deepak Jain) Date: Wed, 11 Aug 2010 19:40:06 -0400 Subject: off-topic: summary on Internet traffic growth History Message-ID: On my BB. I'm waiting for someone to correct this thread by saying MFS bought UUNET for ~2bill and WCOM absorbed MFS. That is all. ----- Original Message ----- From: Jeffrey S. Young To: John Lee Cc: nanog at nanog.org ; Andrew Odlyzko Sent: Wed Aug 11 19:26:29 2010 Subject: Re: off-topic: summary on Internet traffic growth History Worldcom bought MFS. Worldcom bought MCI. Worldcom bought UUnet. In your statement s/MCI/Worldcom/g I don't know if UUnet was part of Worldcom when MO first made statements about backbone growth, but I do know that internetMCI was still part of MCI and therefore, MCI was not a part of Worldcom. May seem like splitting hairs to some, but it is important to a few of us to point out that we never worked under Ebbers. Not that we had a choice :-). Growth of the NAPs during this period is a poor indicator of growth. Because of the glitch you mention in carrying capacity the tier 1's all but abandoned the NAPs for peering between themselves and from that point forward (mid '97) preferred direct peering arrangements. jy On 12/08/2010, at 4:13 AM, John Lee wrote: > Andrew, > > Earlier this week I had a meeting with the ex-Director of the Network Operations Center for MFS-Datanet/MCI whose tenure was through 1999. From 1994 to 1998 they were re-architeching the Frame Relay and ATM networks to handle the growth in traffic including these new facilities called peering points of MAE-East and MAE-West. From roughly 1990 to then end of 1996 they saw traffic on their switches grow at 50-70% growth every 6 months. By the last half of 1996 there was a head of line blocking problem on the DEC FDDI switches that was "regularly" bringing down the Internet. The architecture had lower traffic circuits were going through concentrators while higher traffic circuits were directly attached to ports on the switchs. > > > > MFS-Datanet was not going to take the hit for the interruptions to the Internet and was going to inform the trade press there was a problem with DEC FDDI switches so Digital "gave" six switches for the re-architecture of the MAEs to solve the problem. Once this problem was solved the first quarter of 1997 saw a 70% jump in traffic that quarter alone. This "historical event" would in my memory be the genesis of the 100% traffic growth in 100 days legend. (So it was only 70% in 90 days which for the marketing folks does not cut it so 100% in 100 days sounds much better?? :) ) > > > > MCI bought MFS-Datanet because MCI had the customers and MFS-Datanet had all of the fiber running to key locations at the time and could drastically cut MCI's costs. UUNET "merged" with MCI and their traffic was put on this same network. MCI went belly up and Verizon bought the network. > > > > Personal Note: from 1983 to 90 I worked for Hayes the modem folks and became the Godfather to Ascend communications with Jeanette, Rob, Jay and Steve whose team produced the TNT line of modem/ISDN to Ethernet central site concentrators (in the early ninties) that drove a large portion of the user traffic to the Internet at the time, generating the "bubble". > > > > John (ISDN) Lee > ________________________________________ > From: Andrew Odlyzko [odlyzko at umn.edu] > Sent: Wednesday, August 11, 2010 12:55 PM > To: nanog at nanog.org > Subject: off-topic: summary on Internet traffic growth myths > > Since several members of this list requested it, here is a summary > of the responses to my request for information about Internet growth > during the telecom bubble, in particular the perceptions of the > O'Dell/Sidgmore/WorldCom/UUNet "Internet doubling every 100 days" > myth. > > First of all, many thanks to all those who responded, on and off-list. > This involved extensive correspondence and some long phone conversations, > and helped fill out the picture of those very confusing times (and > also made it even clearer than before that there were many different > perspectives on what was happening). > > The entire message is rather long, but it is written in sections, > to make it easy to get the gist quickly and neglect the rest. > > Andrew > > > ------------------------------------------------------------------- > > 1. Short summary: People who got into the game late, or had been > working at small ISPs or other enterprises, were generally willing > to give serious credence to the "Internet doubling every 100 days" > tale. The old-timers, especially those who worked for large ISPs > or other large corporate establishment or research networks, were > convinced by the late 1990s that this tale was false, but did not > talk about it publicly, even inside the NANOG community. > > ------------------------------------------------------------------- > > 2. Longer version: The range of views was very wide, and hard to > give justice to in full. But there seemed to be two distinct > groups, and the consensus views (which obviously exclude quite > a few people) appear to have been: > > 2A: Those who entered the field in the late 1990s, especially > if they worked for small ISPs or other small enterprises, tended > to regard the claim seriously. (But it should be remarked that > hardly anybody devoted too much effort or thought to the claim, > they were too busy putting out fires in their own backyards to > worry about global issues.) They remembered periods of desperate > efforts to keep up with exploding demand in their businesses. > We saw just a few hours ago a post about LINX growing 5.5x in > one year. Somebody else wrote about growing their business's > traffic 1,000x in 2 years, or about 30x per year. People involved > in such incidents often tended to think that their experience > during such times might not have been untypical. > > 2B: Those who worked at places with large traffic, and especially > those who got into the field in the early 1990s, were quite sure > by the late 1990s that the UUNet fable was just that. Comments > regarding everything emanating from UUNet during that period > included phrases like "blowing smoke," "rolling our eyes," "taking > it with a rock of salt." They had no direct knowledge of what > went on inside UUNet, but from watching peering traffic, talking > to salespeople about customer losses and wins, and to suppliers > about deliveries of equipment, they could be pretty certain that > neither the traffic nor the capacity of UUNet could be exploding > at the mythical rates. They could see occasional spikes in > traffic growth at some customers, or in some parts of their > networks, but overall could see traffic growth settling down > to a fairly regular doubling or a bit more than doubling each > year. > > However, they did not discuss this in public, and I discuss that > below, in point #4. > > ------------------------------------------------------------------- > > 3. Growth spurt in mid-1990s: The old-timers also provided very > informative feedback about the global Internet traffic growth > spurt in the 1995-96 time frame. It did hit suddenly and > unexpectedly. (I am still trying to get confirmation on this, > but I believe one of the informants said that before this > period, the engineers at that person's Tier-1 ISP would routinely > double the forecasts provided by the marketing team. At the peak > of the bubble, the marketers would demand that the engineers plan > for double the capacity that the engineers thought was going > to be necessary.) Moreover, the dramatic slowdown in traffic > growth that took place in 1997 was, at least in a number of > cases, due substantially to a capacity crunch. Router and > photonic equipment manufacturers did not have the technology > needed for the traffic, and ILECs were slow in supplying > access as well as backbone links. Hence the traffic growth > spurt in 1996-96 was followed by a capacity growth spurt > in 1997-98, which helped provide more credibility for the > myth. > > ------------------------------------------------------------------- > > 4. Information viscosity: This incident provides far more > information confirming the concept of "information viscosity" > that I wrote about in my paper, that important and relevant > information was available, but was not widely dispersed. > > Why did the information that Internet traffic was not doubling > every 100 days get out to the public? It was not a closely > guarded national security secret, after all. > > There seemed to be many reasons operating. In the case of > Genuity (as the quote from Scott Marcus in my paper explains) > it was a high-level decision, that going public would hurt > the company, as it might be suspected of losing market share. > But that seemed to be unusual, in that Genuity, while a > major Tier-1 ISP, was small and independent, and so had > people like Scott who were engineers, yet involved in > policy making. At other places, other dynamics operated. > > At AT&T, for example, I was called in to a meeting with > the management of WorldNet, the AT&T ISP unit, at the > end of 2000. They had been telling their customers that > Internet traffic was growing 10x per year, and some of > those customers asked them about the discrepancy between > that claim and the estimates of some folks from AT&T > Labs - Research (Kerry Coffman and myself) that growth > was just 2x per year. Now it is an interesting perspective > on "information viscosity" and AT&T (and other large > bureaucratic organizations) that those folks had not > heard of Kerry's and my work, even though we had publicized > it at the company. But in any event, at that meeting, > I did succeed in convincing them that Internet traffic > was growing only 2x per year (using evidence in my papers > with Kerry, as well as extensive additional data from > within AT&T itself), and they agreed they would not > propagate the myth among customers. But the interesting > thing was that many of the attendees (who included quite > a few engineering types, not just the management) seemed > disappointed. That really surprised me. After all, > AT&T's Internet traffic was growing just about 4x per > year, which meant our market share was doubling, instead > of being cut in half. But it seems that many of them > had really bought into the Internet dream. And, furthermore, > the story that we were losing market share was a good one > to pry additional resources from the corporation. > > Several of the NANOG old-timers said that they felt constrained > from speaking about the falsity of the myth of astronomical > growth rates by group solidarity. After all, it was a > small, select group, and bad-mouthing one of their own > in front of outsiders or even NANOG newbies did not seem > the right thing to do. Then there was the additional > factor that one person discussed very explicitly, and > that I infer also applied in other cases. The myth was > useful. Back in the mid-1990s, when it was not a myth, > it did spur equipment suppliers and ILECs to greater > effort. And afterwards, it was handy in internal fights > over power and resources. If the Internet was exploding, > one should not worry about closely examining expansion > plans. > > In some ways, the persistence of false perceptions about > Internet traffic growth mirrors that of utilization rates > of data networks. When I wrote the paper "Data networks > are lightly utilized, and will stay that way," back in 1998, > > http://www.dtc.umn.edu/~odlyzko/doc/network.utilization.pdf > > the more clueful data network engineers all knew that > utilization rates were generally low, and usually had > a good understanding as to why. But top management, as > well as the research community, were almost uniformly > convinced that congestion was the rule. It took me a > while to understand the dynamics of the situation, in > which network engineers and managers found it easier > to say that they were experiencing 80% utilization and > 20% packet losses and needed to upgrade, without having > to explain to CEOs, CIOs, and especially to clueless > CFOs, that this referred just to the peak hour on one crucial > corporate WAN link, and yet justified a big new investment. > Few people were lying, but many had incentives to maintain > delusions among the top levels of the hierarchy. > > These demonstrations of information viscosity of course > undermine the foundations of much of modern economics, > especially of the efficient markets hypothesis. But that > last myth is even more durable than "Internet traffic > doubling every 100 days," especially since it does not > lead directly to lots of dark fiber lying around unused, > and lots of companies bankrupt. Information viscosity > in facts and ideas in economics is very high, so we > should not expect any changes on that scene. > > > ------------------------------------------------------------------- > > 5. As a reminder, the paper that led to this discussion is > "Bubbles, gullibility, and other challenges for economics, > psychology, sociology, and information sciences," > > http://www.dtc.umn.edu/~odlyzko/doc/mania03.pdf > > The page with source materials from the bubbles times, > > http://www.dtc.umn.edu/~odlyzko/isources/ > > now has, in addition to a transcript of the O'Dell lecture > at Stanford in May 2000, a copy of the Sidgmore paper from > the Vortex98 Conference of May 1998. > From deleskie at gmail.com Wed Aug 11 18:45:04 2010 From: deleskie at gmail.com (deleskie at gmail.com) Date: Wed, 11 Aug 2010 23:45:04 +0000 Subject: off-topic: summary on Internet traffic growth History In-Reply-To: References: <53A6C7E936ED8544B1A2BC990D254F946FC6040B0B@MEMEXG1.HOST.local> Message-ID: <1397494451-1281570304-cardhu_decombobulator_blackberry.rim.net-626840912-@bda002.bisx.prod.on.blackberry> I think for most of us iMCI'ers its a very big diffrence that iMCI != MCIWorldcom -jim Sent from my BlackBerry device on the Rogers Wireless Network -----Original Message----- From: "Jeffrey S. Young" Date: Thu, 12 Aug 2010 09:26:29 To: John Lee Cc: nanog at nanog.org; Andrew Odlyzko Subject: Re: off-topic: summary on Internet traffic growth History Worldcom bought MFS. Worldcom bought MCI. Worldcom bought UUnet. In your statement s/MCI/Worldcom/g I don't know if UUnet was part of Worldcom when MO first made statements about backbone growth, but I do know that internetMCI was still part of MCI and therefore, MCI was not a part of Worldcom. May seem like splitting hairs to some, but it is important to a few of us to point out that we never worked under Ebbers. Not that we had a choice :-). Growth of the NAPs during this period is a poor indicator of growth. Because of the glitch you mention in carrying capacity the tier 1's all but abandoned the NAPs for peering between themselves and from that point forward (mid '97) preferred direct peering arrangements. jy On 12/08/2010, at 4:13 AM, John Lee wrote: > Andrew, > > Earlier this week I had a meeting with the ex-Director of the Network Operations Center for MFS-Datanet/MCI whose tenure was through 1999. From 1994 to 1998 they were re-architeching the Frame Relay and ATM networks to handle the growth in traffic including these new facilities called peering points of MAE-East and MAE-West. From roughly 1990 to then end of 1996 they saw traffic on their switches grow at 50-70% growth every 6 months. By the last half of 1996 there was a head of line blocking problem on the DEC FDDI switches that was "regularly" bringing down the Internet. The architecture had lower traffic circuits were going through concentrators while higher traffic circuits were directly attached to ports on the switchs. > > > > MFS-Datanet was not going to take the hit for the interruptions to the Internet and was going to inform the trade press there was a problem with DEC FDDI switches so Digital "gave" six switches for the re-architecture of the MAEs to solve the problem. Once this problem was solved the first quarter of 1997 saw a 70% jump in traffic that quarter alone. This "historical event" would in my memory be the genesis of the 100% traffic growth in 100 days legend. (So it was only 70% in 90 days which for the marketing folks does not cut it so 100% in 100 days sounds much better?? :) ) > > > > MCI bought MFS-Datanet because MCI had the customers and MFS-Datanet had all of the fiber running to key locations at the time and could drastically cut MCI's costs. UUNET "merged" with MCI and their traffic was put on this same network. MCI went belly up and Verizon bought the network. > > > > Personal Note: from 1983 to 90 I worked for Hayes the modem folks and became the Godfather to Ascend communications with Jeanette, Rob, Jay and Steve whose team produced the TNT line of modem/ISDN to Ethernet central site concentrators (in the early ninties) that drove a large portion of the user traffic to the Internet at the time, generating the "bubble". > > > > John (ISDN) Lee >________________________________________ > From: Andrew Odlyzko [odlyzko at umn.edu] > Sent: Wednesday, August 11, 2010 12:55 PM > To: nanog at nanog.org > Subject: off-topic: summary on Internet traffic growth myths > > Since several members of this list requested it, here is a summary > of the responses to my request for information about Internet growth > during the telecom bubble, in particular the perceptions of the > O'Dell/Sidgmore/WorldCom/UUNet "Internet doubling every 100 days" > myth. > > First of all, many thanks to all those who responded, on and off-list. > This involved extensive correspondence and some long phone conversations, > and helped fill out the picture of those very confusing times (and > also made it even clearer than before that there were many different > perspectives on what was happening). > > The entire message is rather long, but it is written in sections, > to make it easy to get the gist quickly and neglect the rest. > > Andrew > > > ------------------------------------------------------------------- > > 1. Short summary: People who got into the game late, or had been > working at small ISPs or other enterprises, were generally willing > to give serious credence to the "Internet doubling every 100 days" > tale. The old-timers, especially those who worked for large ISPs > or other large corporate establishment or research networks, were > convinced by the late 1990s that this tale was false, but did not > talk about it publicly, even inside the NANOG community. > > ------------------------------------------------------------------- > > 2. Longer version: The range of views was very wide, and hard to > give justice to in full. But there seemed to be two distinct > groups, and the consensus views (which obviously exclude quite > a few people) appear to have been: > > 2A: Those who entered the field in the late 1990s, especially > if they worked for small ISPs or other small enterprises, tended > to regard the claim seriously. (But it should be remarked that > hardly anybody devoted too much effort or thought to the claim, > they were too busy putting out fires in their own backyards to > worry about global issues.) They remembered periods of desperate > efforts to keep up with exploding demand in their businesses. > We saw just a few hours ago a post about LINX growing 5.5x in > one year. Somebody else wrote about growing their business's > traffic 1,000x in 2 years, or about 30x per year. People involved > in such incidents often tended to think that their experience > during such times might not have been untypical. > > 2B: Those who worked at places with large traffic, and especially > those who got into the field in the early 1990s, were quite sure > by the late 1990s that the UUNet fable was just that. Comments > regarding everything emanating from UUNet during that period > included phrases like "blowing smoke," "rolling our eyes," "taking > it with a rock of salt." They had no direct knowledge of what > went on inside UUNet, but from watching peering traffic, talking > to salespeople about customer losses and wins, and to suppliers > about deliveries of equipment, they could be pretty certain that > neither the traffic nor the capacity of UUNet could be exploding > at the mythical rates. They could see occasional spikes in > traffic growth at some customers, or in some parts of their > networks, but overall could see traffic growth settling down > to a fairly regular doubling or a bit more than doubling each > year. > > However, they did not discuss this in public, and I discuss that > below, in point #4. > > ------------------------------------------------------------------- > > 3. Growth spurt in mid-1990s: The old-timers also provided very > informative feedback about the global Internet traffic growth > spurt in the 1995-96 time frame. It did hit suddenly and > unexpectedly. (I am still trying to get confirmation on this, > but I believe one of the informants said that before this > period, the engineers at that person's Tier-1 ISP would routinely > double the forecasts provided by the marketing team. At the peak > of the bubble, the marketers would demand that the engineers plan > for double the capacity that the engineers thought was going > to be necessary.) Moreover, the dramatic slowdown in traffic > growth that took place in 1997 was, at least in a number of > cases, due substantially to a capacity crunch. Router and > photonic equipment manufacturers did not have the technology > needed for the traffic, and ILECs were slow in supplying > access as well as backbone links. Hence the traffic growth > spurt in 1996-96 was followed by a capacity growth spurt > in 1997-98, which helped provide more credibility for the > myth. > > ------------------------------------------------------------------- > > 4. Information viscosity: This incident provides far more > information confirming the concept of "information viscosity" > that I wrote about in my paper, that important and relevant > information was available, but was not widely dispersed. > > Why did the information that Internet traffic was not doubling > every 100 days get out to the public? It was not a closely > guarded national security secret, after all. > > There seemed to be many reasons operating. In the case of > Genuity (as the quote from Scott Marcus in my paper explains) > it was a high-level decision, that going public would hurt > the company, as it might be suspected of losing market share. > But that seemed to be unusual, in that Genuity, while a > major Tier-1 ISP, was small and independent, and so had > people like Scott who were engineers, yet involved in > policy making. At other places, other dynamics operated. > > At AT&T, for example, I was called in to a meeting with > the management of WorldNet, the AT&T ISP unit, at the > end of 2000. They had been telling their customers that > Internet traffic was growing 10x per year, and some of > those customers asked them about the discrepancy between > that claim and the estimates of some folks from AT&T > Labs - Research (Kerry Coffman and myself) that growth > was just 2x per year. Now it is an interesting perspective > on "information viscosity" and AT&T (and other large > bureaucratic organizations) that those folks had not > heard of Kerry's and my work, even though we had publicized > it at the company. But in any event, at that meeting, > I did succeed in convincing them that Internet traffic > was growing only 2x per year (using evidence in my papers > with Kerry, as well as extensive additional data from > within AT&T itself), and they agreed they would not > propagate the myth among customers. But the interesting > thing was that many of the attendees (who included quite > a few engineering types, not just the management) seemed > disappointed. That really surprised me. After all, > AT&T's Internet traffic was growing just about 4x per > year, which meant our market share was doubling, instead > of being cut in half. But it seems that many of them > had really bought into the Internet dream. And, furthermore, > the story that we were losing market share was a good one > to pry additional resources from the corporation. > > Several of the NANOG old-timers said that they felt constrained > from speaking about the falsity of the myth of astronomical > growth rates by group solidarity. After all, it was a > small, select group, and bad-mouthing one of their own > in front of outsiders or even NANOG newbies did not seem > the right thing to do. Then there was the additional > factor that one person discussed very explicitly, and > that I infer also applied in other cases. The myth was > useful. Back in the mid-1990s, when it was not a myth, > it did spur equipment suppliers and ILECs to greater > effort. And afterwards, it was handy in internal fights > over power and resources. If the Internet was exploding, > one should not worry about closely examining expansion > plans. > > In some ways, the persistence of false perceptions about > Internet traffic growth mirrors that of utilization rates > of data networks. When I wrote the paper "Data networks > are lightly utilized, and will stay that way," back in 1998, > > http://www.dtc.umn.edu/~odlyzko/doc/network.utilization.pdf > > the more clueful data network engineers all knew that > utilization rates were generally low, and usually had > a good understanding as to why. But top management, as > well as the research community, were almost uniformly > convinced that congestion was the rule. It took me a > while to understand the dynamics of the situation, in > which network engineers and managers found it easier > to say that they were experiencing 80% utilization and > 20% packet losses and needed to upgrade, without having > to explain to CEOs, CIOs, and especially to clueless > CFOs, that this referred just to the peak hour on one crucial > corporate WAN link, and yet justified a big new investment. > Few people were lying, but many had incentives to maintain > delusions among the top levels of the hierarchy. > > These demonstrations of information viscosity of course > undermine the foundations of much of modern economics, > especially of the efficient markets hypothesis. But that > last myth is even more durable than "Internet traffic > doubling every 100 days," especially since it does not > lead directly to lots of dark fiber lying around unused, > and lots of companies bankrupt. Information viscosity > in facts and ideas in economics is very high, so we > should not expect any changes on that scene. > > > ------------------------------------------------------------------- > > 5. As a reminder, the paper that led to this discussion is > "Bubbles, gullibility, and other challenges for economics, > psychology, sociology, and information sciences," > > http://www.dtc.umn.edu/~odlyzko/doc/mania03.pdf > > The page with source materials from the bubbles times, > > http://www.dtc.umn.edu/~odlyzko/isources/ > > now has, in addition to a transcript of the O'Dell lecture > at Stanford in May 2000, a copy of the Sidgmore paper from > the Vortex98 Conference of May 1998. > From young at jsyoung.net Wed Aug 11 20:05:19 2010 From: young at jsyoung.net (Jeffrey S. Young) Date: Thu, 12 Aug 2010 11:05:19 +1000 Subject: off-topic: summary on Internet traffic growth History In-Reply-To: <06D9EF2B-8D2E-4F7F-995C-4D7D3831FF57@gizmopartners.com> References: <53A6C7E936ED8544B1A2BC990D254F946FC6040B0B@MEMEXG1.HOST.local> <06D9EF2B-8D2E-4F7F-995C-4D7D3831FF57@gizmopartners.com> Message-ID: BIPP was sold to C&W where it continued to use MCI transmission and facilities. In November 2000, C&W had rebuilt it on their own facilities (just a bit larger). Quite soon after the completion of the new network in 2000, C&W marketing was forecasting the need for a network that was ten times the size of their current backbone (the new network was four times the size of the original iMCI). C&W was chapter 7 within 12 months. BTW: C&W sued Worldcom and won a $250M settlement on the basis that MCI had hidden the iMCI sales and marketing team in the sale. The assets of C&W were sold to Savvis. jy On 12/08/2010, at 5:10 AM, Chris Boyd wrote: > > On Aug 11, 2010, at 1:13 PM, John Lee wrote: > >> MCI bought MFS-Datanet because MCI had the customers and MFS-Datanet had all of the fiber running to key locations at the time and could drastically cut MCI's costs. UUNET "merged" with MCI and their traffic was put on this same network. MCI went belly up and Verizon bought the network. > > Although not directly involved in the MCI Internet operations, I read all the announcements that came across the email when I worked at MCI from early 1993 to late 1998. > > My recollection is that Worldcom bought out MFS. UUnet was a later acquisition by the Worldcom monster (no, no biases here :-). While this was going on MCI was building and running what was called the BIPP (Basic IP Platform) internally. That product was at least reasonably successful, enough so that some gummint powers that be required divestiture of the BIPP from the company that would come out of the proposed acquisition of MCI by Worldcom. The regulators felt that Worldcom would have too large a share of the North American Internet traffic. The BIPP went with BT IIRC, and I think finally landed in Global Crossing's assets. > > --Chris > From deleskie at gmail.com Wed Aug 11 21:12:14 2010 From: deleskie at gmail.com (jim deleskie) Date: Wed, 11 Aug 2010 23:12:14 -0300 Subject: off-topic: summary on Internet traffic growth History In-Reply-To: <06D9EF2B-8D2E-4F7F-995C-4D7D3831FF57@gizmopartners.com> References: <53A6C7E936ED8544B1A2BC990D254F946FC6040B0B@MEMEXG1.HOST.local> <06D9EF2B-8D2E-4F7F-995C-4D7D3831FF57@gizmopartners.com> Message-ID: CIP went with BT (Concert) I still clearly remember the very long concall when we separated it from it BIPP connections. :) -jim On Wed, Aug 11, 2010 at 4:10 PM, Chris Boyd wrote: > > On Aug 11, 2010, at 1:13 PM, John Lee wrote: > >> MCI bought MFS-Datanet because MCI had the customers and MFS-Datanet had all of the fiber running to key locations at the time and could drastically cut MCI's costs. UUNET "merged" with MCI and their traffic was put on this same network. MCI went belly up and Verizon bought the network. > > Although not directly involved in the MCI Internet operations, I read all the announcements that came across the email when I worked at MCI from early 1993 to late 1998. > > My recollection is that Worldcom bought out MFS. ?UUnet was a later acquisition by the Worldcom monster (no, no biases here :-). ?While this was going on MCI was building and running what was called the BIPP (Basic IP Platform) internally. ?That product was at least reasonably successful, enough so that some gummint powers that be required divestiture of the BIPP from the company that would come out of the proposed acquisition of MCI by Worldcom. ?The regulators felt that Worldcom would have too large a share of the North American Internet traffic. ?The BIPP went with BT IIRC, and I think finally landed in Global Crossing's assets. > > --Chris > From mpalmer at hezmatt.org Wed Aug 11 21:01:38 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Thu, 12 Aug 2010 12:01:38 +1000 Subject: Cost of transit and options in APAC In-Reply-To: <4C62FFAE.1090608@bogus.com> References: <13485638.719.1281554976626.JavaMail.franck@franck-martins-macbook-pro.local> <4C62FFAE.1090608@bogus.com> Message-ID: <20100812020138.GB11895@hezmatt.org> On Wed, Aug 11, 2010 at 12:53:18PM -0700, Joel Jaeggli wrote: > On 8/11/10 12:29 PM, Franck Martin wrote: > > Nice to see this change.... > > > > APAC has been obliged to pay the cost to peer with the US (long > > distance links are expensive). Now that US wants to peer with Asia, > > pricing may become more balanced... > > I think the question is more like why am I being quoted $100 A megabit > in India for transit in India? Not why am I being charged for for the > transport cost across the pacific. Because the percentage of traffic that actually stays in India, as compared to that which transits the Pacific, is miniscule. If you're asking for enough bandwidth / throwing enough money around, I'm sure you could get an Indian-only deal, but you'd need to make it worth the while for the provider to setup the config, given that either way they'll be getting your money, and you won't be using a lot of transpacific traffic. Note also that it's unlikely that the provider will be getting a differentiated rate from their upstreams for internal traffic, and you may have to settle for peering-only access (if your chosen provider is connected to any peering points). - Matt -- Ruby's the only language I've ever used that feels like it was designed by a programmer, and not by a hardware engineer (Java, C, C++), an academic theorist (Lisp, Haskell, OCaml), or an editor of PC World (Python). -- William Morgan From ptbnat at yahoo.com Thu Aug 12 01:18:56 2010 From: ptbnat at yahoo.com (Natarajan Balasubramanian) Date: Thu, 12 Aug 2010 11:48:56 +0530 (IST) Subject: Chunghwa Telecom Tech Support Reg. Message-ID: <333256.71347.qm@web95106.mail.in2.yahoo.com> Hi All, Does anyone have the contact number for "Chunghwa Telecom's" Business Users - Technical Support number ? -Nat From ptbnat at yahoo.com Thu Aug 12 01:23:39 2010 From: ptbnat at yahoo.com (Natarajan Balasubramanian) Date: Thu, 12 Aug 2010 11:53:39 +0530 (IST) Subject: Chunghwa Telecom Tech Support Reg. In-Reply-To: <333256.71347.qm@web95106.mail.in2.yahoo.com> Message-ID: <637592.54186.qm@web95110.mail.in2.yahoo.com> Note: I need the Technical Support Contact number for "Chunghwa Telecom" in Taiwan. --- On Thu, 12/8/10, Natarajan Balasubramanian wrote: From: Natarajan Balasubramanian Subject: Chunghwa Telecom Tech Support Reg. To: nanog at nanog.org Date: Thursday, 12 August, 2010, 11:48 AM Hi All, Does anyone have the contact number for "Chunghwa Telecom's" Business Users - Technical Support number ? -Nat From yamu at ciklum.net Thu Aug 12 01:29:17 2010 From: yamu at ciklum.net (Yasir Munir Abbasi) Date: Thu, 12 Aug 2010 06:29:17 +0000 Subject: Chunghwa Telecom Tech Support Reg. In-Reply-To: <637592.54186.qm@web95110.mail.in2.yahoo.com> References: <333256.71347.qm@web95106.mail.in2.yahoo.com> <637592.54186.qm@web95110.mail.in2.yahoo.com> Message-ID: <261E17F810EEC548ACD322ED2E847CE309ADF4@exten02.kyiv.ciklum.net> 0800-080-100 Yasir Abbasi -----Original Message----- From: Natarajan Balasubramanian [mailto:ptbnat at yahoo.com] Sent: Thursday, August 12, 2010 11:24 AM To: nanog at nanog.org Subject: Re: Chunghwa Telecom Tech Support Reg. Note: I need the Technical Support Contact number for "Chunghwa Telecom" in Taiwan. --- On Thu, 12/8/10, Natarajan Balasubramanian wrote: From: Natarajan Balasubramanian Subject: Chunghwa Telecom Tech Support Reg. To: nanog at nanog.org Date: Thursday, 12 August, 2010, 11:48 AM Hi All, Does anyone have the contact number for "Chunghwa Telecom's" Business Users - Technical Support number ? -Nat From ptbnat at yahoo.com Thu Aug 12 01:39:02 2010 From: ptbnat at yahoo.com (Natarajan Balasubramanian) Date: Thu, 12 Aug 2010 12:09:02 +0530 (IST) Subject: Chunghwa Telecom Tech Support Reg. In-Reply-To: <261E17F810EEC548ACD322ED2E847CE309ADF4@exten02.kyiv.ciklum.net> Message-ID: <292032.79726.qm@web95116.mail.in2.yahoo.com> Hi Yasir, Thanks a lot for your immediate reply. I tried calling the number you provided, that does not lead to "Chunghwa Telecom" in Taiwan. However, it leads to some other organization and they are unable to understand when I speak in English :-( -Nat --- On Thu, 12/8/10, Yasir Munir Abbasi wrote: From: Yasir Munir Abbasi Subject: RE: Chunghwa Telecom Tech Support Reg. To: "ptbnat at yahoo.com" , "nanog at nanog.org" Date: Thursday, 12 August, 2010, 11:59 AM 0800-080-100 Yasir Abbasi -----Original Message----- From: Natarajan Balasubramanian [mailto:ptbnat at yahoo.com] Sent: Thursday, August 12, 2010 11:24 AM To: nanog at nanog.org Subject: Re: Chunghwa Telecom Tech Support Reg. Note: I need the Technical Support Contact number for "Chunghwa Telecom" in Taiwan. --- On Thu, 12/8/10, Natarajan Balasubramanian wrote: From: Natarajan Balasubramanian Subject: Chunghwa Telecom Tech Support Reg. To: nanog at nanog.org Date: Thursday, 12 August, 2010, 11:48 AM Hi All, Does anyone have the contact number for "Chunghwa Telecom's" Business Users - Technical Support number ? -Nat From harry.nanog at harry.lu Thu Aug 12 02:03:33 2010 From: harry.nanog at harry.lu (Harry Strongburg) Date: Thu, 12 Aug 2010 07:03:33 +0000 Subject: Chunghwa Telecom Tech Support Reg. In-Reply-To: <292032.79726.qm@web95116.mail.in2.yahoo.com> References: <261E17F810EEC548ACD322ED2E847CE309ADF4@exten02.kyiv.ciklum.net> <292032.79726.qm@web95116.mail.in2.yahoo.com> Message-ID: <20100812070333.GA26412@harryy.us> On Thu, Aug 12, 2010 at 12:09:02PM +0530, Natarajan Balasubramanian wrote: > Hi Yasir, > Thanks a lot for your immediate reply. I tried calling the number you provided, that does not lead to "Chunghwa Telecom" in Taiwan. However, it leads to some other organization and they are unable to understand when I speak in English :-( > -Nat Excuse my non-helpful reply, but why do you require a telephone contact number? Can you not email them and hope for a reply? (is at cht.com.tw should work) In my past experence dealing with companies who do not speak English over the telephone, you will not get any answers. From young at jsyoung.net Thu Aug 12 02:07:54 2010 From: young at jsyoung.net (Jeffrey S. Young) Date: Thu, 12 Aug 2010 17:07:54 +1000 Subject: off-topic: summary on Internet traffic growth History In-Reply-To: References: <53A6C7E936ED8544B1A2BC990D254F946FC6040B0B@MEMEXG1.HOST.local> <06D9EF2B-8D2E-4F7F-995C-4D7D3831FF57@gizmopartners.com> Message-ID: <351FCE2F-2D73-49F7-A9DF-AFCCE1312E55@jsyoung.net> MCI and BT had a long courtship. BT left MCI standing at the altar after neighborhoodMCI (a consumer last mile play) announced $400M in losses, twice. WorldCom swooped in after that. jy On 12/08/2010, at 12:12 PM, jim deleskie wrote: > CIP went with BT (Concert) I still clearly remember the very long > concall when we separated it from it BIPP connections. :) > > -jim > > On Wed, Aug 11, 2010 at 4:10 PM, Chris Boyd wrote: >> >> On Aug 11, 2010, at 1:13 PM, John Lee wrote: >> >>> MCI bought MFS-Datanet because MCI had the customers and MFS-Datanet had all of the fiber running to key locations at the time and could drastically cut MCI's costs. UUNET "merged" with MCI and their traffic was put on this same network. MCI went belly up and Verizon bought the network. >> >> Although not directly involved in the MCI Internet operations, I read all the announcements that came across the email when I worked at MCI from early 1993 to late 1998. >> >> My recollection is that Worldcom bought out MFS. UUnet was a later acquisition by the Worldcom monster (no, no biases here :-). While this was going on MCI was building and running what was called the BIPP (Basic IP Platform) internally. That product was at least reasonably successful, enough so that some gummint powers that be required divestiture of the BIPP from the company that would come out of the proposed acquisition of MCI by Worldcom. The regulators felt that Worldcom would have too large a share of the North American Internet traffic. The BIPP went with BT IIRC, and I think finally landed in Global Crossing's assets. >> >> --Chris >> > > From young at jsyoung.net Thu Aug 12 02:18:03 2010 From: young at jsyoung.net (Jeffrey S. Young) Date: Thu, 12 Aug 2010 17:18:03 +1000 Subject: off-topic: summary on Internet traffic growth History In-Reply-To: <2594B329-0822-4933-9D61-F14979ABC502@queuefull.net> References: <53A6C7E936ED8544B1A2BC990D254F946FC6040B0B@MEMEXG1.HOST.local> <06D9EF2B-8D2E-4F7F-995C-4D7D3831FF57@gizmopartners.com> <2594B329-0822-4933-9D61-F14979ABC502@queuefull.net> Message-ID: <514E739A-6E6D-4137-B4F3-5110E4693D19@jsyoung.net> N3 = new network nodes, BIPP wasn't that great a name either. The ASN was always 3561. jy On 12/08/2010, at 8:20 AM, Benson Schliesser wrote: > > On 11 Aug 10, at 2:10 PM, Chris Boyd wrote: > >> My recollection is that Worldcom bought out MFS. UUnet was a later acquisition by the Worldcom monster (no, no biases here :-). While this was going on MCI was building and running what was called the BIPP (Basic IP Platform) internally. That product was at least reasonably successful, enough so that some gummint powers that be required divestiture of the BIPP from the company that would come out of the proposed acquisition of MCI by Worldcom. The regulators felt that Worldcom would have too large a share of the North American Internet traffic. The BIPP went with BT IIRC, and I think finally landed in Global Crossing's assets. > > Actually, Cable & Wireless acquired the BIPP after regulators forced Worldcom to divest one of their networks. C&W developed a new network architecture as an evolution of BIPP called "N3", based on MPLS as an ATM replacement for TE. (Perhaps somebody that worked at C&W back then can comment on N3; I can't recall what it stood for.) After a few years, C&W reorganized their American operations into a separate entity, which subsequently went bankrupt. Savvis (my current employer) bought the assets out of bankruptcy court. We then upgraded the N3 network to support better QoS, higher capacity, etc, and call it the "ATN" (Application Transport Network). The current Savvis core network, AS3561, is thus the evolved offspring of the MCI Internet Services / Internet-MCI network. > > Of course, before all of this, MCI built the network as a commercial Internet platform in parallel to their ARPA network. That's before my time, unfortunately, so I don't know many details. For instance I'm uncertain how the ASN has changed over the years. Anybody with more history and/or corrections would be appreciated. > > Cheers, > -Benson > > > From dorian at blackrose.org Thu Aug 12 07:26:47 2010 From: dorian at blackrose.org (Dorian Kim) Date: Thu, 12 Aug 2010 08:26:47 -0400 Subject: Cost of transit and options in APAC In-Reply-To: References: <13485638.719.1281554976626.JavaMail.franck@franck-martins-macbook-pro.local> <4C62FFAE.1090608@bogus.com> <01FC6493-65A8-45D6-809A-06C65565F4B9@queuefull.net> <4C6320FA.80901@bogus.com> Message-ID: <20100812122647.GA5470@blackrose.org> On Wed, Aug 11, 2010 at 05:41:16PM -0500, Benson Schliesser wrote: > > On 11 Aug 10, at 5:15 PM, Joel Jaeggli wrote: > > >> Obviously I can't speak for the providers in question, but I'd guess > >> that the cost for transit in AP is strongly related to the cost of > >> long-haul transport. > > > > Start with something that can be effectively isolated from the > > transpacific path. > > > > Gotten a quote for a 1Gbe or 10Gbe between two cities in India recently? > > That could be useful. Sadly, I have no first-hand knowledge of these costs. How does in-country transport compare to trans-Pacific transport cost? (i.e. on a per Mbps per kilometer or similar metric) I assume it's cheaper in-country / in-region compared to trans-oceanic. Is this true? This is not an assumption you can make safely depending on the country and specific sub-region you are talking about. If you go back to mid 90s, the situation was much the same in Europe, which was why US East coast was the default location for IP traffic exchange for Europe until the costs started to change. -dorian From leland at taranta.discpro.org Thu Aug 12 07:32:25 2010 From: leland at taranta.discpro.org (Leland Vandervort) Date: Thu, 12 Aug 2010 14:32:25 +0200 Subject: IPv6 Server Load Balancing - DSR Message-ID: <6DC1F083-5885-4AA0-AA82-A537BE25DBC5@taranta.discpro.org> Dear Colleagues, I've been scratching my head over this for the past couple of months and have come up with blanks, and several weeks of scouring various resources on the net have not yielded anything more fruitful. I'm looking at server load balancing for IPv6 and specifically need DSR (direct server return). Additionally, I need to support both TCP and UDP. I have evaluated a number of different load balancing solutions purporting to support IPv6 with varying results (and costs)... a few examples: F5 : according to marketing blurb supposedly supports IPv6 in NAT and DSR mode, both UDP and TCP. Their documentation, however, has no mention of IPv6 capability. Other disadvantage = cost... Brocade/Foundry: Similar situation to F5 Zeus: IPv6 in NAT only, and even more expensive than F5. Exceliance Aloha: IPv6 in NAT only, and ONLY in TCP (no UDP) A few others also tested... including LVM/HAProxy (same situation as Exceliance Aloha), and others... Finally in the end, only OpenSolaris ILB seems to put all the checks in the right boxes for my requirements. But there is still a problem. 1. IPv4 TCP and UDP work fine in NAT, Half-NAT, and DSR 2. IPv6 I've managed to get working, complete with healthchecks, in TCP and UDP in NAT only although the documentation stipulates that DSR is also possible (but not HalfNAT for the moment). The problem with #2: Using the same server farm behind, but in dual-stack, and configuring ILB for TCP and UDP services using NAT, everything is fine. If I configure it for DSR, immediately it fails (both with and without healthchecks). Although from the ILB host itself, I can certainly do a manual heathcheck.. (e.g. telnet 80 and do GET / or HEAD / with no problems. Using ARP poisoning from the shell I can also perform the healthcheck on the real server via telnet using the virtual ip. The servers are configured normally for DSR.. with the virtual IP attached to a local dummy or loopback interface, and with IPv4 DSR works fine. Nevertheless, I've been unable to get DSR working with ILB -- and have found absolutely nothing around the net with working examples of IPv6 SLB with DSR. NAT mode works fine, but the real server loses visibility of the end user's IP as the requests come from the internal IP of the ILB host, and with a system that uses client IP address as part of the various criteria for session tracking, it creates a few problems... I am suspecting that the issue may be related to ND, as the behaviour is similar to the old story with doing DSR on real-servers using older linux distributions that do not by default disable proxy-ARP replies by the server for IP addresses on dummy or loopback interfaces, and of course the proxy ARP causes confusion to the load balancer and breaks the whole thing. But the real servers are recent Debian distributions, and both ipv4 ARP and ipv6 ND is disabled on the dummy interfaces, as is proxy ARP. Would anyone happen to have any useful pointers, tips, or other on how to resolve the issue? Many thanks in advance. Leland From simon.perreault at viagenie.ca Thu Aug 12 08:03:47 2010 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Thu, 12 Aug 2010 09:03:47 -0400 Subject: IPv6 Server Load Balancing - DSR In-Reply-To: <6DC1F083-5885-4AA0-AA82-A537BE25DBC5@taranta.discpro.org> References: <6DC1F083-5885-4AA0-AA82-A537BE25DBC5@taranta.discpro.org> Message-ID: <4C63F133.4020805@viagenie.ca> On 2010-08-12 08:32, Leland Vandervort wrote: > I'm looking at server load balancing for IPv6 and specifically need > DSR (direct server return). Additionally, I need to support both TCP > and UDP. This is easily done with OpenBSD. See here for starters: http://www.undeadly.org/cgi?action=article&sid=20080617010016 Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From kiwi at oav.net Thu Aug 12 08:05:26 2010 From: kiwi at oav.net (Xavier Beaudouin) Date: Thu, 12 Aug 2010 15:05:26 +0200 Subject: IPv6 Server Load Balancing - DSR In-Reply-To: <6DC1F083-5885-4AA0-AA82-A537BE25DBC5@taranta.discpro.org> References: <6DC1F083-5885-4AA0-AA82-A537BE25DBC5@taranta.discpro.org> Message-ID: <21216C06-8AEC-4C2A-93AE-BD32BDAA6198@oav.net> Hi Leland, Seems that hardware vendors doesn't like IPv6... for load balancing. I had a look to relayd from OpenBSD, and it seems this can be used a LoadBalancing with DSR... Even if they don't recommand this ... Maybe the is is the time to move from hardware / closed solutions to open ones.. ? Xavier From leland at taranta.discpro.org Thu Aug 12 08:11:03 2010 From: leland at taranta.discpro.org (Leland Vandervort) Date: Thu, 12 Aug 2010 15:11:03 +0200 Subject: IPv6 Server Load Balancing - DSR In-Reply-To: <21216C06-8AEC-4C2A-93AE-BD32BDAA6198@oav.net> References: <6DC1F083-5885-4AA0-AA82-A537BE25DBC5@taranta.discpro.org> <21216C06-8AEC-4C2A-93AE-BD32BDAA6198@oav.net> Message-ID: OpenSolaris ILB is open solution ;) but yea, that's what we've started looking at -- hence LVM / HAProxy as well.. (though LVM is IPv4 only, and HAProxy is NAT only for IPv6) does relayd support UDP as well as TCP or is it layer7 only like HAProxy ? In the case of ILB, I'm not convinced that it's a problem with the LB itself, but rather the idiosyncrasies of ND in IPv6 that is causing the problem.. but I may be wrong... at any rate, something's amiss ... cheers, Leland On 12 Aug 2010, at 15:05, Xavier Beaudouin wrote: > Hi Leland, > > Seems that hardware vendors doesn't like IPv6... for load balancing. > > I had a look to relayd from OpenBSD, and it seems this can be used a LoadBalancing with DSR... Even if they don't recommand this ... > > Maybe the is is the time to move from hardware / closed solutions to open ones.. ? > > Xavier From kiwi at oav.net Thu Aug 12 08:19:51 2010 From: kiwi at oav.net (Xavier Beaudouin) Date: Thu, 12 Aug 2010 15:19:51 +0200 Subject: IPv6 Server Load Balancing - DSR In-Reply-To: References: <6DC1F083-5885-4AA0-AA82-A537BE25DBC5@taranta.discpro.org> <21216C06-8AEC-4C2A-93AE-BD32BDAA6198@oav.net> Message-ID: <1CBF69B8-B1BE-4485-962C-71A9BCBA8F98@oav.net> Hi Leland, Le 12 ao?t 2010 ? 15:11, Leland Vandervort a ?crit : > OpenSolaris ILB is open solution ;) > > but yea, that's what we've started looking at -- hence LVM / HAProxy as well.. (though LVM is IPv4 only, and HAProxy is NAT only for IPv6) > > does relayd support UDP as well as TCP or is it layer7 only like HAProxy ? It does everything... :) L2 -> L7... > In the case of ILB, I'm not convinced that it's a problem with the LB itself, but rather the idiosyncrasies of ND in IPv6 that is causing the problem.. but I may be wrong... at any rate, something's amiss ... Maybe on some setup you should desactivate ND... Xavier From leland at taranta.discpro.org Thu Aug 12 08:22:14 2010 From: leland at taranta.discpro.org (Leland Vandervort) Date: Thu, 12 Aug 2010 15:22:14 +0200 Subject: IPv6 Server Load Balancing - DSR In-Reply-To: <1CBF69B8-B1BE-4485-962C-71A9BCBA8F98@oav.net> References: <6DC1F083-5885-4AA0-AA82-A537BE25DBC5@taranta.discpro.org> <21216C06-8AEC-4C2A-93AE-BD32BDAA6198@oav.net> <1CBF69B8-B1BE-4485-962C-71A9BCBA8F98@oav.net> Message-ID: <9B02A2C2-E0E5-4B94-93AB-FA7532D10323@taranta.discpro.org> On 12 Aug 2010, at 15:19, Xavier Beaudouin wrote: > >> In the case of ILB, I'm not convinced that it's a problem with the LB itself, but rather the idiosyncrasies of ND in IPv6 that is causing the problem.. but I may be wrong... at any rate, something's amiss ... > > Maybe on some setup you should desactivate ND... > Yea.. well. .that's the point... can't deactivate ND on the real interface of the server as that's required for the server itself.. but it, according to the kernel, deactivated on the dummy interface carrying the virtual IP of the server farm... exactly as is done for IPv4 and ARP manipulation. Hmmmmm... L. From mohacsi at niif.hu Thu Aug 12 08:24:23 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 12 Aug 2010 15:24:23 +0200 (CEST) Subject: IPv6 Server Load Balancing - DSR In-Reply-To: <4C63F133.4020805@viagenie.ca> References: <6DC1F083-5885-4AA0-AA82-A537BE25DBC5@taranta.discpro.org> <4C63F133.4020805@viagenie.ca> Message-ID: On Thu, 12 Aug 2010, Simon Perreault wrote: > On 2010-08-12 08:32, Leland Vandervort wrote: >> I'm looking at server load balancing for IPv6 and specifically need >> DSR (direct server return). Additionally, I need to support both TCP >> and UDP. > > This is easily done with OpenBSD. See here for starters: > > http://www.undeadly.org/cgi?action=article&sid=20080617010016 And FreeBSD: http://www.freshports.org/net/relayd/ > > Simon > -- > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org > > From robert.gallagher at heanet.ie Thu Aug 12 08:42:04 2010 From: robert.gallagher at heanet.ie (Rob Gallagher) Date: Thu, 12 Aug 2010 14:42:04 +0100 Subject: IPv6 Server Load Balancing - DSR In-Reply-To: <6DC1F083-5885-4AA0-AA82-A537BE25DBC5@taranta.discpro.org> References: <6DC1F083-5885-4AA0-AA82-A537BE25DBC5@taranta.discpro.org> Message-ID: <20100812144204.6c9133a5@headshop.heanet.ie> On Thu, 12 Aug 2010 14:32:25 +0200 Leland Vandervort wrote: > I'm looking at server load balancing for IPv6 and specifically need > DSR (direct server return). Additionally, I need to support both TCP > and UDP. IPVS has had IPv6 support for a while: http://www.mindbasket.com/ipvs/ We're using it on our mirror site, http://ftp.heanet.ie, with DSR for http, ftp and rsync load balancing. rg -- Rob Gallagher | Public Key: 0x1DD13A78 HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1. Registered in Ireland, no 275301 T: (+353-1) 6609040 F: (+353-1) 6603666 WWW: http://www.heanet.ie/ HEAnet National Networking Conference, 10-12 November 2010 - Registration is now open at: http://www.heanet.ie/conferences/2010/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From william.mccall at gmail.com Thu Aug 12 09:09:28 2010 From: william.mccall at gmail.com (William McCall) Date: Thu, 12 Aug 2010 09:09:28 -0500 Subject: off-topic: summary on Internet traffic growth History In-Reply-To: References: <53A6C7E936ED8544B1A2BC990D254F946FC6040B0B@MEMEXG1.HOST.local> <06D9EF2B-8D2E-4F7F-995C-4D7D3831FF57@gizmopartners.com> <4C62F9D5.4090309@verizonbusiness.com> Message-ID: VBNS is part of VzB. On 8/11/10, Marshall Eubanks wrote: > > > On Aug 11, 2010, at 3:28 PM, Randy Whitney wrote: > >> On 8/11/2010 3:10 PM, Chris Boyd wrote: >>> >>> On Aug 11, 2010, at 1:13 PM, John Lee wrote: >>> >>>> MCI bought MFS-Datanet because MCI had the customers and >>>> MFS-Datanet had all of the fiber running to key locations at the >>>> time and could drastically cut MCI's costs. UUNET "merged" with MCI >>>> and their traffic was put on this same network. MCI went belly up >>>> and Verizon bought the network. >>> >>> Although not directly involved in the MCI Internet operations, I read >>> all the announcements that came across the email when I worked at MCI >>> from early 1993 to late 1998. >>> >>> My recollection is that Worldcom bought out MFS. UUnet was a later >>> acquisition by the Worldcom monster (no, no biases here :-). While >>> this was going on MCI was building and running what was called the >>> BIPP (Basic IP Platform) internally. That product was at least >>> reasonably successful, enough so that some gummint powers that be >>> required divestiture of the BIPP from the company that would come out >>> of the proposed acquisition of MCI by Worldcom. The regulators felt >>> that Worldcom would have too large a share of the North American >>> Internet traffic. The BIPP went with BT IIRC, and I think finally >>> landed in Global Crossing's assets. > > What happened to VBNS in all of this ? > > Marshall > >>> >>> --Chris >> >> Correct order of (in)digestion UUNet > MFS > Worldcom >< MCI > Verizon. >> >> There were other multi-way acquisitions in-between as well (CNS, ANS, >> etc.) >> >> -Randy. >> >> >> > > > -- Sent from my mobile device William McCall, CCIE #25044 From jcdill.lists at gmail.com Thu Aug 12 10:32:44 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 12 Aug 2010 08:32:44 -0700 Subject: net-neutrality In-Reply-To: <5164.1281549053@localhost> References: <5164.1281549053@localhost> Message-ID: <4C64141C.4050908@gmail.com> Valdis.Kletnieks at vt.edu wrote: > On Wed, 11 Aug 2010 12:23:01 CDT, Jeff Harper said: > >> This is kind of like one person saying they're not going to listen to a >> radio station anymore. >> > > "And the only reason I'm singing you this song now is cause you may know > somebody in a similar situation, or you may be in a similar situation, and if > your in a situation like that there's only one thing you can do and that's walk > into the shrink wherever you are ,just walk in say "Shrink, You can get > anything you want, at Alice's restaurant.". And walk out. You know, if one > person, just one person does it they may think he's really sick and they won't > take him. And if two people, two people do it, in harmony, they may think > they're both faggots and they won't take either of them. And three people do > it, three, can you imagine, three people walking in singin a bar of Alice's > Restaurant and walking out. They may think it's an organization. And can you, > can you imagine fifty people a day,I said fifty people a day walking in singin > a bar of Alice's Restaurant and walking out. And friends they may thinks it's > a movement." > > Of course, that *does* require finding 49 other like-minded people. > > You may find these variations even more apt for this discussion: http://www.arlo.net/resources/lyrics/alices-nntp.shtml > I went over to the Commissar, said "Commissar, you got a lotta damn > gall to ask me if I've rehabilitated myself, I mean, I mean, I'm just > sittin' here, sittin' on the group H bench 'cause you want to know if > I'm *moral* enough to join a Company to grep mail, burn electronic books, > and censor feeds after bein' an NNTP hacker." He looked at me, said > "Kid, we don't like your kind, and we're gonna send your .newsrc down > to California..." > > And friends, somewhere in California, enshrined in some little directory, > is a study in ones and zeroes of my .newsrc. And the only reason I'm > singin' you this song is 'cause you may know somebody in a similar > situation, or *YOU* may be in a similar situation, and if you're in a > situation like that, there's only one thing you can do and that's post > a message to your company's internal newsgroup, saying "Commissar, you > can get anything you want on Alice's NNTP server." > > And log off. > > You know, if one person, just one person does it, they may think he's > really sick and won't fire him just yet, just send him down to a Training > Session until his brains are jellied up. And if two people, two people > do it, in harmony, they may think they're starting a cascade and will only > fire one of 'em to establish a precedent and put the fear-o-God in the > rest > of their workers. And three people, three, can you imagine, three people > logging on, posting a message containing a bar of Alice's NNTP Server and > walking out, they may think it's an organization. And can you imagine > fifty people a day, I said fifty people a day logging on, postin' a bar > of "Alice's NNTP Server" and logging off. And friends, they may think > it's a movement. > > And that's what it is, the Alice's NNTP Server Anti-Censorship Movement, > and all you got to do to join is quote it the next time it comes around > on the screen. > With feelin'. http://www.arlo.net/resources/lyrics/alice_flame.shtml > He looked at me and said, ``Kid, we don't like your kind! We're > gonna send your subnet mask off to rs.internic.net!'' And, friends, > somewhere in Washington, enshrined on some 5.25 inch floppy disk, > is a study in ones and zeros of my brain-damaged programming style... > > And the only reason I'm singin' you the song now is 'cause you may > know somebody in a similar situation. Or you may be in a similar > situation, and if you're in a situation like that, there's only > one thing you can do: > > [ CHORUS ] > > You know, if one person, just one person, does it, they may think > he's really dangerous and they won't flame him. > > And if two people do it, in harmony, they may think they're both > Perl hackers and they won't flame either of them. > > And if three people do it! Can you imagine three people loggin' > in, singin' a bar of ``Alice's Usenet Flame'' and loggin' out? They > may think it's an re-implementation of sendmail! > > And can you imagine fifty people a day? I said FIFTY people a day, > loggin' in, singin' a bar of ``Alice's Usenet Flame'' and loggin' > out? Friends, they may think it's a MOVEMENT, and that's what it > is: THE INTERNET GLOBAL ANTI-LOSSAGE MOVEMENT! And all you gotta > do to join is to sing it the next time it comes around on the > /var/spool/news/in.coming directory. > > With feelin'. From khomyakov.andrey at gmail.com Thu Aug 12 10:54:20 2010 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Thu, 12 Aug 2010 11:54:20 -0400 Subject: Policy Based Routing advice Message-ID: Hey all. I'm trying to setup a routing policy on a cat4503-E with Sup6-E and for some reason I can't see it taking effect. I'm definitely sourcing packets from 172.25.0.0/16 (the test machine had 172.25.24.25 address). For some reason the packets still go out towards the default gateway instead of what's specified in the route-map. The switch is running cat4500e-ENTSERVICESK9-M), Version 12.2(52)SG, RELEASE SOFTWARE (fc1) According to stats on the ACL and the route-map it's just not being hit for some reason. Applying the ACL directly to the interface (as an access-group) shows that the ACL is correct and I see hits, however, via the route map it's not being hit. I don't know what those "2 matches" are, but there definitely should be a lot more than 2. And in addition, I see the packets arriving on the firewall that is the "default gateway". Does anyone have any tips on why this might now work? ip access-list standard acl_Students permit 172.25.0.0 0.0.255.255 route-map Students-Route-Map permit 10 match ip address acl_Students set ip next-hop 192.168.168.22 interface GigabitEthernet2/6 no switchport ip address 192.168.250.1 255.255.255.252 ip pim dense-mode ip policy route-map Students-Route-Map interface GigabitEthernet2/14 no switchport ip address 192.168.168.21 255.255.255.252 no ip redirects no ip mroute-cache flowcontrol send desired cat4503#sh access-lists acl_Students Standard IP access list acl_Students 10 permit 172.25.0.0, wildcard bits 0.0.255.255 (2 matches) cat4503#sh route-map route-map Students-Route-Map, permit, sequence 10 Match clauses: ip address (access-lists): acl_Students Set clauses: ip next-hop 192.168.168.22 Policy routing matches: 2 packets, 180 bytes cat4503#sh ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via "static", distance 1, metric 0, candidate default path Redistributing via eigrp 179 Advertised by eigrp 179 Routing Descriptor Blocks: * 192.168.168.10 Route metric is 0, traffic share count is 1 -- Andrey Khomyakov [khomyakov.andrey at gmail.com] From owen at delong.com Thu Aug 12 11:28:01 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 12 Aug 2010 09:28:01 -0700 Subject: IPv6 Server Load Balancing - DSR In-Reply-To: <1CBF69B8-B1BE-4485-962C-71A9BCBA8F98@oav.net> References: <6DC1F083-5885-4AA0-AA82-A537BE25DBC5@taranta.discpro.org> <21216C06-8AEC-4C2A-93AE-BD32BDAA6198@oav.net> <1CBF69B8-B1BE-4485-962C-71A9BCBA8F98@oav.net> Message-ID: On Aug 12, 2010, at 6:19 AM, Xavier Beaudouin wrote: > Hi Leland, > > Le 12 ao?t 2010 ? 15:11, Leland Vandervort a ?crit : > >> OpenSolaris ILB is open solution ;) >> >> but yea, that's what we've started looking at -- hence LVM / HAProxy as well.. (though LVM is IPv4 only, and HAProxy is NAT only for IPv6) >> >> does relayd support UDP as well as TCP or is it layer7 only like HAProxy ? > > It does everything... :) L2 -> L7... > >> In the case of ILB, I'm not convinced that it's a problem with the LB itself, but rather the idiosyncrasies of ND in IPv6 that is causing the problem.. but I may be wrong... at any rate, something's amiss ... > > Maybe on some setup you should desactivate ND... > > Xavier If you're putting the DSR address on an interface other than loopback, you probably need to turn of DAD on the interface with the DSR address otherwise DAD will shut down that address on the interface when it sees other servers with the same address. Sometimes it will shut down all but one, sometimes it will shut down all. Owen From leland at taranta.discpro.org Thu Aug 12 11:40:23 2010 From: leland at taranta.discpro.org (Leland Vandervort) Date: Thu, 12 Aug 2010 18:40:23 +0200 Subject: IPv6 Server Load Balancing - DSR In-Reply-To: References: <6DC1F083-5885-4AA0-AA82-A537BE25DBC5@taranta.discpro.org> <21216C06-8AEC-4C2A-93AE-BD32BDAA6198@oav.net> <1CBF69B8-B1BE-4485-962C-71A9BCBA8F98@oav.net> Message-ID: <6686D31F-CEFA-4E48-BC8B-CDFD28BF031B@taranta.discpro.org> Hi Owen, The DSR address is indeed on a loopback in our case. lo Link encap:Local Loopback inet6 addr: ::1/128 Scope:Host inet6 addr: xxxx:xxxx:x:xxxx::xx/128 Scope:Global The mystery continues... Leland On 12 Aug 2010, at 18:28, Owen DeLong wrote: > > On Aug 12, 2010, at 6:19 AM, Xavier Beaudouin wrote: > >> Hi Leland, >> >> Le 12 ao?t 2010 ? 15:11, Leland Vandervort a ?crit : >> >>> OpenSolaris ILB is open solution ;) >>> >>> but yea, that's what we've started looking at -- hence LVM / HAProxy as well.. (though LVM is IPv4 only, and HAProxy is NAT only for IPv6) >>> >>> does relayd support UDP as well as TCP or is it layer7 only like HAProxy ? >> >> It does everything... :) L2 -> L7... >> >>> In the case of ILB, I'm not convinced that it's a problem with the LB itself, but rather the idiosyncrasies of ND in IPv6 that is causing the problem.. but I may be wrong... at any rate, something's amiss ... >> >> Maybe on some setup you should desactivate ND... >> >> Xavier > > If you're putting the DSR address on an interface other than loopback, you probably need to turn of DAD on the interface with the DSR address otherwise DAD > will shut down that address on the interface when it sees other servers with the same address. Sometimes it will shut down all but one, sometimes it will > shut down all. > > > Owen From marcoh at marcoh.net Thu Aug 12 12:23:04 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 12 Aug 2010 19:23:04 +0200 Subject: IPv6 Server Load Balancing - DSR In-Reply-To: <6DC1F083-5885-4AA0-AA82-A537BE25DBC5@taranta.discpro.org> References: <6DC1F083-5885-4AA0-AA82-A537BE25DBC5@taranta.discpro.org> Message-ID: Brocade basically sucks when it comes to loadbalancing IPv6, the old serveriron platform is EOL and a complete mess which offers some IPv6 support, but not much. The new ADX platform seems to be in a pre-alfa stage at the moment. So normally I would say stand clear, however we do run a (larger) usenet platform on v6 which uses DSR and that part works on the serveriron, running a pre-relase of the 11.0.0f software. Must admit we don't do anything fancy, it's all unprotected and statically routed, ACLs are all done on the reals and on the Juniper in front of the serveriron etc. But it seems to hold, haven't heard any complains yet. But be warned this is a really specifc subset of features. For regular operations like web we still have loads and loads of issues. Basically the other choice is F5. We are busy setting up a PoC with A10, who claim IPv6 support. Hopefully in a few weeks time they can be added to the list of potential suppliers. Other then these two I haven't come across any dedicated stuff and what's left is Linux/BSD based solutions. MarcoH From leland at taranta.discpro.org Thu Aug 12 12:34:18 2010 From: leland at taranta.discpro.org (Leland Vandervort) Date: Thu, 12 Aug 2010 19:34:18 +0200 Subject: IPv6 Server Load Balancing - DSR In-Reply-To: References: <6DC1F083-5885-4AA0-AA82-A537BE25DBC5@taranta.discpro.org> <21216C06-8AEC-4C2A-93AE-BD32BDAA6198@oav.net> <1CBF69B8-B1BE-4485-962C-71A9BCBA8F98@oav.net> <6686D31F-CEFA-4E48-BC8B-CDFD28BF031B@taranta.discpro.org> Message-ID: <95BE229C-4A2F-4E8F-AE6D-8B1AE07CA982@taranta.discpro.org> Well, Frankly our "culture" is very much open source, so if we can find something along those lines, then it would be preferred. (Hence looking at OpenSolaris and ILB). -- having said that, we do have both F5 and Foundry kit here, but it's all pre-IPv6 so doesn't have the support built in. Not really looking to replace what is in existence already for IPv4 with something new to do both, so really that reinforces the open-source avenue really. I think the biggest problem is really the DSR aspect for IPv6, since the OS/ILB solution works perfectly in NAT mode, and DSR works perfectly with IPv4 on this solution. So either I'm missing something critical on the "real" server configuration, or ILB's implementation of DSR for IPv6 doesn't really work. The "virtual" IP is bound to loopback on the real servers, exactly the same was as for IPv4. So other than something quirky going on with ND, or simply ILB not correctly rewriting the L2 frame, or there's something else more sinister afoot that I'm unable to put my finger on. Back to the drawing board... :) Thanks, Leland On 12 Aug 2010, at 19:23, William Cooper wrote: > I know there have been quite a few responses for both h/w and s/w > solutions, it's not clear > which your preference is of the two. I know there are various h/w > vendors that offer a s/w > solution (mostly in conjunction with some form of virtualization > environment), such as A10. > > I've been testing A10 for a while now, and they seem very keen on > developing parity between > v4 and v6 feature sets / performance. > > DSR is more or less a L2 trick that plays on some inherent weaknesses > and constraints > that are present with v4 local address resolution (don't mean to > preach to the chior); I think > most responses here have touched on the primary challenges of DSR with > v6. I'll be exploring > DSR with dual stack v4/6 in the near future, I'll let you know how > that turns out. > > Hmm... not sure how this helped. > > Regards, > > -Tony > > On Thu, Aug 12, 2010 at 12:40 PM, Leland Vandervort > wrote: >> Hi Owen, >> >> The DSR address is indeed on a loopback in our case. >> >> lo Link encap:Local Loopback >> inet6 addr: ::1/128 Scope:Host >> inet6 addr: xxxx:xxxx:x:xxxx::xx/128 Scope:Global >> >> >> >> The mystery continues... >> >> >> Leland >> >> >> On 12 Aug 2010, at 18:28, Owen DeLong wrote: >> >>> >>> On Aug 12, 2010, at 6:19 AM, Xavier Beaudouin wrote: >>> >>>> Hi Leland, >>>> >>>> Le 12 ao?t 2010 ? 15:11, Leland Vandervort a ?crit : >>>> >>>>> OpenSolaris ILB is open solution ;) >>>>> >>>>> but yea, that's what we've started looking at -- hence LVM / HAProxy as well.. (though LVM is IPv4 only, and HAProxy is NAT only for IPv6) >>>>> >>>>> does relayd support UDP as well as TCP or is it layer7 only like HAProxy ? >>>> >>>> It does everything... :) L2 -> L7... >>>> >>>>> In the case of ILB, I'm not convinced that it's a problem with the LB itself, but rather the idiosyncrasies of ND in IPv6 that is causing the problem.. but I may be wrong... at any rate, something's amiss ... >>>> >>>> Maybe on some setup you should desactivate ND... >>>> >>>> Xavier >>> >>> If you're putting the DSR address on an interface other than loopback, you probably need to turn of DAD on the interface with the DSR address otherwise DAD >>> will shut down that address on the interface when it sees other servers with the same address. Sometimes it will shut down all but one, sometimes it will >>> shut down all. >>> >>> >>> Owen >> >> >> From khomyakov.andrey at gmail.com Thu Aug 12 13:16:36 2010 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Thu, 12 Aug 2010 14:16:36 -0400 Subject: Policy Based Routing advice In-Reply-To: References: Message-ID: I bit more explanation: 172.25/16 is a hop away and the packets with that source IP will enter on Gi2/6 and need to exit Gi2/14. So it goes like that: 172.25/16 is vlan25 on the student router Gi0/1 has ip address 192.168.250.2 on the student router default route is towards 192.168.250.1 on the student router > On Thu, Aug 12, 2010 at 11:54 AM, Andrey Khomyakov < > khomyakov.andrey at gmail.com> wrote: > >> Hey all. I'm trying to setup a routing policy on a cat4503-E with Sup6-E >> and >> for some reason I can't see it taking effect. I'm definitely sourcing >> packets from 172.25.0.0/16 (the test machine had 172.25.24.25 address). >> For >> some reason the packets still go out towards the default gateway instead >> of >> what's specified in the route-map. The switch is running >> cat4500e-ENTSERVICESK9-M), Version 12.2(52)SG, RELEASE SOFTWARE (fc1) >> According to stats on the ACL and the route-map it's just not being hit >> for >> some reason. Applying the ACL directly to the interface (as an >> access-group) >> shows that the ACL is correct and I see hits, however, via the route map >> it's not being hit. I don't know what those "2 matches" are, but there >> definitely should be a lot more than 2. And in addition, I see the packets >> arriving on the firewall that is the "default gateway". >> >> Does anyone have any tips on why this might now work? >> >> >> ip access-list standard acl_Students >> permit 172.25.0.0 0.0.255.255 >> >> route-map Students-Route-Map permit 10 >> match ip address acl_Students >> set ip next-hop 192.168.168.22 >> >> interface GigabitEthernet2/6 >> no switchport >> ip address 192.168.250.1 255.255.255.252 >> ip pim dense-mode >> ip policy route-map Students-Route-Map >> >> interface GigabitEthernet2/14 >> no switchport >> ip address 192.168.168.21 255.255.255.252 >> no ip redirects >> no ip mroute-cache >> flowcontrol send desired >> >> cat4503#sh access-lists acl_Students >> Standard IP access list acl_Students >> 10 permit 172.25.0.0, wildcard bits 0.0.255.255 (2 matches) >> >> >> cat4503#sh route-map >> route-map Students-Route-Map, permit, sequence 10 >> Match clauses: >> ip address (access-lists): acl_Students >> Set clauses: >> ip next-hop 192.168.168.22 >> Policy routing matches: 2 packets, 180 bytes >> >> cat4503#sh ip route 0.0.0.0 >> Routing entry for 0.0.0.0/0, supernet >> Known via "static", distance 1, metric 0, candidate default path >> Redistributing via eigrp 179 >> Advertised by eigrp 179 >> Routing Descriptor Blocks: >> * 192.168.168.10 >> Route metric is 0, traffic share count is 1 >> >> -- >> Andrey Khomyakov >> [khomyakov.andrey at gmail.com] >> > > -- Andrey Khomyakov [khomyakov.andrey at gmail.com] From randy at psg.com Thu Aug 12 13:39:23 2010 From: randy at psg.com (Randy Bush) Date: Fri, 13 Aug 2010 03:39:23 +0900 Subject: Chunghwa Telecom Tech Support Reg. In-Reply-To: <292032.79726.qm@web95116.mail.in2.yahoo.com> References: <261E17F810EEC548ACD322ED2E847CE309ADF4@exten02.kyiv.ciklum.net> <292032.79726.qm@web95116.mail.in2.yahoo.com> Message-ID: > Thanks a lot for your immediate reply. I tried calling the number you > provided, that does not lead to "Chunghwa Telecom" in Taiwan. However, > it leads to some other organization and they are unable to understand > when I speak in English :-( try mandarin randy From lists at billfehring.com Thu Aug 12 14:10:07 2010 From: lists at billfehring.com (Bill Fehring) Date: Thu, 12 Aug 2010 12:10:07 -0700 Subject: Policy Based Routing advice In-Reply-To: References: Message-ID: Andrey, It looks like you're doing everything right here so this might seem like a dumb question, but how sure are you that it's not working? In my experience on the 4500, 6500, 3560/3750, those ACL/route-map counters sometimes don't work because of CEF and friends, and at best they count number of flows that matched the ACL, if even that. Before knowing this, once upon a time I was absolutely convinced that my policy routing wasn't working and it turns out that no, the counters had fooled me. Perhaps try a SPAN session on g2/14 and see whether or not the packets you expect are exiting that interface, or watch the interface counters. HTH, Bill On Thu, Aug 12, 2010 at 11:16, Andrey Khomyakov wrote: > I bit more explanation: 172.25/16 is a hop away and the packets with that > source IP will enter on Gi2/6 and need to exit Gi2/14. > So it goes like that: > > 172.25/16 is vlan25 on the student router > Gi0/1 has ip address 192.168.250.2 on the student router > default route is towards 192.168.250.1 on the student router > > > >> On Thu, Aug 12, 2010 at 11:54 AM, Andrey Khomyakov < >> khomyakov.andrey at gmail.com> wrote: >> >>> Hey all. I'm trying to setup a routing policy on a cat4503-E with Sup6-E >>> and >>> for some reason I can't see it taking effect. I'm definitely sourcing >>> packets from 172.25.0.0/16 (the test machine had 172.25.24.25 address). >>> For >>> some reason the packets still go out towards the default gateway instead >>> of >>> what's specified in the route-map. The switch is running >>> cat4500e-ENTSERVICESK9-M), Version 12.2(52)SG, RELEASE SOFTWARE (fc1) >>> According to stats on the ACL and the route-map it's just not being hit >>> for >>> some reason. Applying the ACL directly to the interface (as an >>> access-group) >>> shows that the ACL is correct and I see hits, however, via the route map >>> it's not being hit. I don't know what those "2 matches" are, but there >>> definitely should be a lot more than 2. And in addition, I see the packets >>> arriving on the firewall that is the "default gateway". >>> >>> Does anyone have any tips on why this might now work? >>> >>> >>> ip access-list standard acl_Students >>> ?permit 172.25.0.0 0.0.255.255 >>> >>> route-map Students-Route-Map permit 10 >>> ?match ip address acl_Students >>> ?set ip next-hop 192.168.168.22 >>> >>> interface GigabitEthernet2/6 >>> no switchport >>> ?ip address 192.168.250.1 255.255.255.252 >>> ?ip pim dense-mode >>> ?ip policy route-map Students-Route-Map >>> >>> interface GigabitEthernet2/14 >>> no switchport >>> ?ip address 192.168.168.21 255.255.255.252 >>> ?no ip redirects >>> ?no ip mroute-cache >>> ?flowcontrol send desired >>> >>> cat4503#sh access-lists acl_Students >>> Standard IP access list acl_Students >>> ? ?10 permit 172.25.0.0, wildcard bits 0.0.255.255 (2 matches) >>> >>> >>> cat4503#sh route-map >>> route-map Students-Route-Map, permit, sequence 10 >>> ?Match clauses: >>> ? ?ip address (access-lists): acl_Students >>> ?Set clauses: >>> ? ?ip next-hop 192.168.168.22 >>> ?Policy routing matches: 2 packets, 180 bytes >>> >>> cat4503#sh ip route 0.0.0.0 >>> Routing entry for 0.0.0.0/0, supernet >>> ?Known via "static", distance 1, metric 0, candidate default path >>> ?Redistributing via eigrp 179 >>> ?Advertised by eigrp 179 >>> ?Routing Descriptor Blocks: >>> ?* 192.168.168.10 >>> ? ? ?Route metric is 0, traffic share count is 1 >>> >>> -- >>> Andrey Khomyakov >>> [khomyakov.andrey at gmail.com] >>> >> >> > > > > -- > Andrey Khomyakov > [khomyakov.andrey at gmail.com] > From khomyakov.andrey at gmail.com Thu Aug 12 14:13:46 2010 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Thu, 12 Aug 2010 15:13:46 -0400 Subject: Policy Based Routing advice In-Reply-To: References: Message-ID: I did try an extended ACL and had the same result. The way I know that it's not working is that I see these packets arriving on a wrong interface on the firewall and therefor being dropped. I actually had to open a CR with Cisco and they verified the config and said nothing is wrong with it. They are escalating and will hopefully get back to me about this. Andrey From rgamino at gmail.com Thu Aug 12 14:25:58 2010 From: rgamino at gmail.com (Rogelio) Date: Thu, 12 Aug 2010 15:25:58 -0400 Subject: Policy Based Routing advice In-Reply-To: References: Message-ID: <3406A5B0-5D33-43AE-888E-271BE94D619A@gmail.com> Have you tried "set interface" instead of "set ip"? Sent from my iPhone On Aug 12, 2010, at 3:13 PM, Andrey Khomyakov wrote: > I did try an extended ACL and had the same result. > The way I know that it's not working is that I see these packets arriving on > a wrong interface on the firewall and therefor being dropped. > I actually had to open a CR with Cisco and they verified the config and said > nothing is wrong with it. They are escalating and will hopefully get back to > me about this. > > Andrey From khomyakov.andrey at gmail.com Thu Aug 12 14:33:01 2010 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Thu, 12 Aug 2010 15:33:01 -0400 Subject: Policy Based Routing advice In-Reply-To: <3406A5B0-5D33-43AE-888E-271BE94D619A@gmail.com> References: <3406A5B0-5D33-43AE-888E-271BE94D619A@gmail.com> Message-ID: I dont' think this will work. Here is the formal description of "set interface" from cisco.com: This action specifies that the packet is forwarded out of the local interface. The interface must be a Layer 3 interface (no switchports), and the destination address in the packet must lie within the IP network assigned to that interface. If the destination address for the packet does not lie within that network, the packet is dropped. Since in my case the packets are destined to random addresses on the webz, my understanding that this will effectively be a drop statement for them. But, no, I have not tried it. On Thu, Aug 12, 2010 at 3:25 PM, Rogelio wrote: > Have you tried "set interface" instead of "set ip"? > > > Sent from my iPhone > > On Aug 12, 2010, at 3:13 PM, Andrey Khomyakov > wrote: > > > I did try an extended ACL and had the same result. > > The way I know that it's not working is that I see these packets arriving > on > > a wrong interface on the firewall and therefor being dropped. > > I actually had to open a CR with Cisco and they verified the config and > said > > nothing is wrong with it. They are escalating and will hopefully get back > to > > me about this. > > > > Andrey > -- Andrey Khomyakov [khomyakov.andrey at gmail.com] From justin at justinshore.com Thu Aug 12 14:43:43 2010 From: justin at justinshore.com (Justin Shore) Date: Thu, 12 Aug 2010 14:43:43 -0500 Subject: Springnet Underground Message-ID: <4C644EEF.1020302@justinshore.com> Does anyone have any experience with the Springnet Underground in Springfield, MO? In case people don't know it's a working limestone mine. In the areas that have already been mined close to the entrance, they've sold or rented out space between the rock pillars that hold up the mine roof. The city of Springfield put in a data center and started selling services out of it that complimented their city-wide fiber plant. They've been suggested as a site for hosting a cabinet full of gear. I'm wondering what the connectivity options are for that facility and so far haven't been able to get a straight answer from anyone. For the most part it looks like the SprintNet folks want to sell you their own upstream which won't cut it for our needs. AT&T serves the area of course but I will not have them as my last mile (or any mile for that matter). Does L3 or any other large carrier have facilities there? Does anyone have any experience with the facility in general? Thanks Justin From jeffpaz at gmail.com Thu Aug 12 14:44:04 2010 From: jeffpaz at gmail.com (Jeffrey Pazahanick) Date: Thu, 12 Aug 2010 14:44:04 -0500 Subject: Policy Based Routing advice In-Reply-To: References: <3406A5B0-5D33-43AE-888E-271BE94D619A@gmail.com> Message-ID: A 'debug ip policy' should show if it's hitting or not... IP: s=30.0.0.1 (Ethernet0/0/1), d=40.0.0.7, len 100,FIB flow policy match IP: s=30.0.0.1 (Ethernet0/0/1), d=40.0.0.7, len 100,FIB PR flow accelerated! IP: s=30.0.0.1 (Ethernet0/0/1), d=40.0.0.7, g=10.0.0.8, len 100, FIB policy routed On Thu, Aug 12, 2010 at 2:33 PM, Andrey Khomyakov < khomyakov.andrey at gmail.com> wrote: > I dont' think this will work. Here is the formal description of "set > interface" from cisco.com: > > This action specifies that the packet is forwarded out of the local > interface. The interface must be a Layer 3 interface (no switchports), and > the destination address in the packet must lie within the IP network > assigned to that interface. If the destination address for the packet does > not lie within that network, the packet is dropped. > > > Since in my case the packets are destined to random addresses on the webz, > my understanding that this will effectively be a drop statement for them. > > But, no, I have not tried it. > > On Thu, Aug 12, 2010 at 3:25 PM, Rogelio wrote: > > > Have you tried "set interface" instead of "set ip"? > > > > > > Sent from my iPhone > > > > On Aug 12, 2010, at 3:13 PM, Andrey Khomyakov < > khomyakov.andrey at gmail.com> > > wrote: > > > > > I did try an extended ACL and had the same result. > > > The way I know that it's not working is that I see these packets > arriving > > on > > > a wrong interface on the firewall and therefor being dropped. > > > I actually had to open a CR with Cisco and they verified the config and > > said > > > nothing is wrong with it. They are escalating and will hopefully get > back > > to > > > me about this. > > > > > > Andrey > > > > > > -- > Andrey Khomyakov > [khomyakov.andrey at gmail.com] > From leslien at arin.net Thu Aug 12 14:51:17 2010 From: leslien at arin.net (Leslie Nobile) Date: Thu, 12 Aug 2010 15:51:17 -0400 Subject: Two /8s allocated to APNIC from IANA (49/8 and 101/8)] In-Reply-To: Message-ID: Forwarding on behalf of APNIC. _____________________________________________________ Two /8s allocated to APNIC from IANA (49/8 and 101/8) _____________________________________________________ Dear colleagues The information in this announcement is to enable the Internet community to update network configurations, such as routing filters, where required. APNIC received the following IPv4 address blocks from IANA in August 2010 and will be making allocations from these ranges in the near future: 49/8 101/8 Reachability and routability testing of the new prefixes will commence soon. The daily report will be published at the usual URL: http://www.ris.ripe.net/debogon For more information on the resources administered by APNIC, please see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, please see: http://www.apnic.net/db/min-alloc.html Please be aware, there are now just 14 /8s remaining in IANA's unallocated IPv4 address pool. Kind regards, Sunny -------------- next part -------------- A non-text attachment was scrubbed... Name: ATT00001..c Type: application/octet-stream Size: 136 bytes Desc: ATT00001..c URL: From rgamino at gmail.com Thu Aug 12 14:54:28 2010 From: rgamino at gmail.com (Rogelio) Date: Thu, 12 Aug 2010 15:54:28 -0400 Subject: Policy Based Routing advice In-Reply-To: References: <3406A5B0-5D33-43AE-888E-271BE94D619A@gmail.com> Message-ID: <320B6374-A5D5-468C-938E-0D3905259244@gmail.com> Hmmm... The reason I recommended that is because I think I remember reading somewhere that the "set ip" command does not work on point-to-point interfaces. The outbound interface in your config has a /30 assigned to it so maybe it is seeing it as a p-t-p interface? Do you have a "less preferred" route via that interface for the destination ip's? If not, I don't think your pbr will work either. Sent from my iPhone On Aug 12, 2010, at 3:33 PM, Andrey Khomyakov wrote: > I dont' think this will work. Here is the formal description of "set > interface" from cisco.com: > > This action specifies that the packet is forwarded out of the local > interface. The interface must be a Layer 3 interface (no switchports), and > the destination address in the packet must lie within the IP network > assigned to that interface. If the destination address for the packet does > not lie within that network, the packet is dropped. > > > Since in my case the packets are destined to random addresses on the webz, > my understanding that this will effectively be a drop statement for them. > > But, no, I have not tried it. > > On Thu, Aug 12, 2010 at 3:25 PM, Rogelio wrote: > >> Have you tried "set interface" instead of "set ip"? >> >> >> Sent from my iPhone >> >> On Aug 12, 2010, at 3:13 PM, Andrey Khomyakov >> wrote: >> >>> I did try an extended ACL and had the same result. >>> The way I know that it's not working is that I see these packets arriving >> on >>> a wrong interface on the firewall and therefor being dropped. >>> I actually had to open a CR with Cisco and they verified the config and >> said >>> nothing is wrong with it. They are escalating and will hopefully get back >> to >>> me about this. >>> >>> Andrey >> > > > > -- > Andrey Khomyakov > [khomyakov.andrey at gmail.com] From mjf246 at gmail.com Thu Aug 12 14:57:47 2010 From: mjf246 at gmail.com (Mikel Jimenez Fernandez) Date: Thu, 12 Aug 2010 21:57:47 +0200 Subject: Two /8s allocated to APNIC from IANA (49/8 and 101/8)] In-Reply-To: References: Message-ID: Good news for IPV6 fans! > Forwarding on behalf of APNIC. > > > > _____________________________________________________ > > Two /8s allocated to APNIC from IANA (49/8 and 101/8) > _____________________________________________________ > > > Dear colleagues > > The information in this announcement is to enable the Internet community to > update network configurations, such as routing filters, > where required. > > APNIC received the following IPv4 address blocks from IANA in August > 2010 and will be making allocations from these ranges in the near > future: > > 49/8 > 101/8 > > Reachability and routability testing of the new prefixes will commence > soon. The daily report will be published at the usual URL: > > http://www.ris.ripe.net/debogon > > For more information on the resources administered by APNIC, please > see: > > http://www.apnic.net/db/ranges.html > > For information on the minimum allocation sizes within address ranges > administered by APNIC, please see: > > http://www.apnic.net/db/min-alloc.html > > Please be aware, there are now just 14 /8s remaining in IANA's > unallocated IPv4 address pool. > > Kind regards, > Sunny > > From patrick at ianai.net Thu Aug 12 13:29:02 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 12 Aug 2010 14:29:02 -0400 Subject: Cost of transit and options in APAC In-Reply-To: <20100812020138.GB11895@hezmatt.org> References: <13485638.719.1281554976626.JavaMail.franck@franck-martins-macbook-pro.local> <4C62FFAE.1090608@bogus.com> <20100812020138.GB11895@hezmatt.org> Message-ID: <76E736EF-8DA8-41F3-8A4C-EEC11623C2FB@ianai.net> On Aug 11, 2010, at 10:01 PM, Matthew Palmer wrote: > On Wed, Aug 11, 2010 at 12:53:18PM -0700, Joel Jaeggli wrote: >> On 8/11/10 12:29 PM, Franck Martin wrote: >>> Nice to see this change.... >>> >>> APAC has been obliged to pay the cost to peer with the US (long >>> distance links are expensive). Now that US wants to peer with Asia, >>> pricing may become more balanced... >> >> I think the question is more like why am I being quoted $100 A megabit >> in India for transit in India? Not why am I being charged for for the >> transport cost across the pacific. > > Because the percentage of traffic that actually stays in India, as compared > to that which transits the Pacific, is miniscule. If you're asking for > enough bandwidth / throwing enough money around, I'm sure you could get an > Indian-only deal, but you'd need to make it worth the while for the provider > to setup the config, given that either way they'll be getting your money, > and you won't be using a lot of transpacific traffic. Note also that it's > unlikely that the provider will be getting a differentiated rate from their > upstreams for internal traffic, and you may have to settle for peering-only > access (if your chosen provider is connected to any peering points). You do not need to throw a lot of money around. Lots of places in Asia give you separate in-country and "international" rates, and charge you accordingly. People have been talking about distance-sensitive pricing for IP traffic for years, without realizing people have been doing it in Asia for years. Back to topic of why prices are high in some places (and it is not just Asia), it is trivial to prove objectively that monopoly power keeps prices ridiculously high. Before anyone jumps on me, there are many reasons for high prices. Monopoly power is only one, but clearly and obviously the biggest one. When I say "objectively", I mean it. Look at any country which has gone through any type of transition from "gov't owned monopoly telco" to "competition-based market". South Africa instantly springs to mind. Prices are still high, but have dropped, what, 75% in just a year or two once the monopoly power was broken? And this is after a decade or more of little to no decrease. Of course, this does not mean .za will have $1/Mbps transit like the US any time soon. As I said, there are other factors - geography, scale, local economy, even import policies, etc. But getting prices to go from US$2000/Mbps to, say, $100/Mbps is more important than the $100 -> $1 drop. (Hrmm, I wonder who will say "the first is only 20 times, the second is 100 times!" to prove me wrong? :) Plus there are a myriad of factors keeping that last step from happening, not just one. So wich do you think is more important, the monopoly power or the dozens of other factors? That said, this is not really on-topic for NANOG. So if you would like to argue the point, please e-mail privately, or let's take it to another list. End of day, the important thing is to break the monopoly. After that, prices will almost always drop, then you can work on other stuff. -- TTFN, patrick From bensons at queuefull.net Thu Aug 12 15:40:20 2010 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 12 Aug 2010 15:40:20 -0500 Subject: Cost of transit and options in APAC In-Reply-To: <20100812122647.GA5470@blackrose.org> References: <13485638.719.1281554976626.JavaMail.franck@franck-martins-macbook-pro.local> <4C62FFAE.1090608@bogus.com> <01FC6493-65A8-45D6-809A-06C65565F4B9@queuefull.net> <4C6320FA.80901@bogus.com> <20100812122647.GA5470@blackrose.org> Message-ID: <02815161-1DF1-44ED-8646-52E2DD2CD86A@queuefull.net> On 12 Aug 10, at 7:26 AM, Dorian Kim wrote: >> Sadly, I have no first-hand knowledge of these costs. How does in-country transport compare to trans-Pacific transport cost? (i.e. on a per Mbps per kilometer or similar metric) I assume it's cheaper in-country / in-region compared to trans-oceanic. Is this true? > > This is not an assumption you can make safely depending on the country and specific > sub-region you are talking about. That's fair; I'm not surprised to hear it. But I'm curious about the details. In specific cases like India and China, what is the underlying contributor to higher relative transport costs? (i.e. taxes, ROW fees, extraordinary shipping or operational costs, inadequate competition, low supply, greed, etc) Further, how does the situation compare to past examples like Europe? I doubt the AP region is forever doomed to exchange traffic via the US, but can't quite anticipate change without first understanding the current environment. Network interconnects are designed the way they are, today, for a reason. If anybody has insight they can share on the situation I would appreciate it. Cheers, -Benson From marcus at grmpf.org Thu Aug 12 16:20:30 2010 From: marcus at grmpf.org (Marcus Stoegbauer) Date: Thu, 12 Aug 2010 23:20:30 +0200 Subject: Reminder: DENOG 2 Call for Participation and Papers Message-ID: <4C64659E.2070005@grmpf.org> DENOG 2 - Call for Participation and Papers The second meeting of the German Network Operators Group (DENOG) will be held in Frankfurt, Germany on the 4th of November 2010. We are pleased to hereby invite applications for presentations or lightning talks to be held at this event. General Information =================== DENOG is a community for professionals within Germany who are operating, designing or researching the Internet. It provides a technical forum where those working on, with and for the Internet can come together to solve problems with every aspect of their (net)work. The meeting is designed to provide an opportunity for the exchange of information among network operators, engineers, researchers and other professionals close to the network community. More information about DENOG (in German) can be found at http://www2.denog.de/ Information about the meeting will be published at http://www.denog.de/. Meeting Countdown ================= What When ------------------------------------------------------ Publication of Call for Papers May 11th, 2010 Deadline for all submissions September 15th, 2010 Beginning of Registration Period End of August, 2010 Publication of final programme End of September, 2010 Deadline for receipt of final slides October 24th, 2010 Meeting Day November 4th, 2010 Topics for Presentations/Talks ============================== The day will be divided into several sessions. The number and length of presentations per session is not fixed, although due to time constraints we would prefer the length of the presentations to be between 10 to 30 minutes. However proposals for longer/shorter presentations or presentations whose subject falls outside of the topics below are also welcome; please do not hesitate to submit them. Lightning Talks --------------- In addition to the topics mentioned below we will reserve slots for lightning talks, which consist of a few slides and will not last longer than 5 minutes. Lightning talks can be submitted until October 29th, with the deadline for submission of the corresponding slides being November 3rd. Topic #1: Power Efficiency in Networks --------------------------------------- For operators of networks and data centres of any size power efficiency has become more important. Servers and network gear with high power consumption are expensive because of high operating and cooling power costs; also in many places supplying more power into the location is no longer possible. How are you dealing with power problems in your environment? How do you efficiently cool a rack/a room/a datacenter? Can a migration to VoIP help you save power? Topic #2: Social Networks, Cloud Services and Information Security ------------------------------------------------------------------ Social Networks are an essential working tool for networkers and cloud services are also becoming increasingly popular. The security of your information and data in these networks is a crucial aspect which we want to discuss in this session. Topic #3: Network Neutrality ---------------------------- In the US, Network Neutrality has been a subject of controversy and debate. Is an ISP allowed to sell "Internet access" which only offers access to a subset of the whole Internet? Is an ISP allowed to prioritise video streams from Company A while imposing a higher delay to video streams from Company B? In Germany Network Neutrality is mainly an issue for mobile networks and not extensively discussed thus far. But what kind of problems will an upcoming debate on Network Neutrality bring to German ISPs and is there a good way to address these problems? Topic #4: Peering ------------------ Everything about your peering experience. Why are you doing it? How are you doing it? Have you written any useful tools which others might find interesting? Topic #5: ISP BOF ----------------- "All things ISP". From Network/SLA Management (for or against it), abuse handling and log systems to data centre layout and planning (including power and cooling), everything that is interesting to you as an ISP can be presented or discussed within this topic. Language of Slides and Talks ============================ To appeal to an international audience we ask you to produce your slides in English, but the spoken language of the presentation itself can be either German or English. Submission Guidelines ===================== All submissions must have a strong technical bias and must not be solely promotional for your employer. Please remember that your presentations should be suitable for a target audience of technicians from varied backgrounds, working for companies whose sizes may vary considerably. To submit a proposal for a presentation, we request that you provide the following information as plain text or PDF format to : * the name of the presenter (and if applicable your affiliation) * a working email address * the name and number of the topic which will contain the presentation * the title of the presentation * its expected length (in minutes) * the preferred spoken language for the presentation * a short abstract of the presentation (not more than 200 words) We also welcome suggestions for specific presentations which you feel would be valuable to the DENOG community. Please be aware that your presentation will be published on the DENOG website after the event. From franck at genius.com Thu Aug 12 16:25:43 2010 From: franck at genius.com (Franck Martin) Date: Fri, 13 Aug 2010 09:25:43 +1200 (FJT) Subject: Cost of transit and options in APAC In-Reply-To: <76E736EF-8DA8-41F3-8A4C-EEC11623C2FB@ianai.net> Message-ID: <2905585.0.1281648339388.JavaMail.franck@franck-martins-macbook-pro.local> +10 Once you pass a threshold of affordability (by breaking the monopoly), then the network use explodes and other issues can be worked out by more or less by consumer pressure (and economies of scale)... You need to reach "Packet Storm" level. ----- Original Message ----- From: "Patrick W. Gilmore" To: "NANOG list" Sent: Friday, 13 August, 2010 6:29:02 AM Subject: Re: Cost of transit and options in APAC Back to topic of why prices are high in some places (and it is not just Asia), it is trivial to prove objectively that monopoly power keeps prices ridiculously high. Before anyone jumps on me, there are many reasons for high prices. Monopoly power is only one, but clearly and obviously the biggest one. When I say "objectively", I mean it. Look at any country which has gone through any type of transition from "gov't owned monopoly telco" to "competition-based market". South Africa instantly springs to mind. Prices are still high, but have dropped, what, 75% in just a year or two once the monopoly power was broken? And this is after a decade or more of little to no decrease. Of course, this does not mean .za will have $1/Mbps transit like the US any time soon. As I said, there are other factors - geography, scale, local economy, even import policies, etc. But getting prices to go from US$2000/Mbps to, say, $100/Mbps is more important than the $100 -> $1 drop. (Hrmm, I wonder who will say "the first is only 20 times, the second is 100 times!" to prove me wrong? :) Plus there are a myriad of factors keeping that last step from happening, not just one. So wich do you think is more important, the monopoly power or the dozens of other factors? That said, this is not really on-topic for NANOG. So if you would like to argue the point, please e-mail privately, or let's take it to another list. End of day, the important thing is to break the monopoly. After that, prices will almost always drop, then you can work on other stuff. -- TTFN, patrick From psirt at cisco.com Thu Aug 12 17:26:32 2010 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Thu, 12 Aug 2010 18:26:32 -0400 Subject: Cisco Security Advisory: Cisco IOS Software TCP Denial of Service Vulnerability Message-ID: <201008121826.tcp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software TCP Denial of Service Vulnerability Advisory ID: cisco-sa-20100812-tcp http://www.cisco.com/warp/public/707/cisco-sa-20100812-tcp.shtml Revision 1.0 For Public Release 2010 August 12 2130 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Cisco IOS Software Release, 15.1(2)T is affected by a denial of service (DoS) vulnerability during the TCP establishment phase. The vulnerability could cause embryonic TCP connections to remain in a SYNRCVD or SYNSENT state. Enough embryonic TCP connections in these states could consume system resources and prevent an affected device from accepting or initiating new TCP connections, including any TCP-based remote management access to the device. No authentication is required to exploit this vulnerability. An attacker does not need to complete a three-way handshake to trigger this vulnerability; therefore, this this vunerability can be exploited using spoofed packets. This vulnerability may be triggered by normal network traffic. Cisco has released Cisco IOS Software Release 15.1(2)T0a to address this vulnerability. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20100812-tcp.shtml. Affected Products ================= This vulnerability affects only Cisco IOS Software Release 15.1(2)T. No other Cisco IOS Software Releases are affected. Cisco IOS XE Software, Cisco IOS XR Software, and Cisco NX-OS Software are not affected by this vulnerability. Vulnerable Products +------------------ A Cisco device is vulnerable when it is running Cisco IOS Software Release 15.1(2)T. To determine the Cisco IOS Software Release that is running on a Cisco product, administrators can log in to the device and issue the "show version" command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software Release name. Other Cisco devices do not have the "show version" command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 15.1(2)T with an installed image name of C2800NM-ENTSERVICES-M: Router#show version Cisco IOS Software, 2800 Software (C2800NM-ENTSERVICES-M), Version 15.1(2)T, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2010 by Cisco Systems, Inc. Compiled Mon 19-Jul-10 16:38 by prod_rel_team Additional information about Cisco IOS Software Release naming conventions is available in the White Paper: Cisco IOS Reference Guide. Products Confirmed Not Vulnerable +-------------------------------- No other Cisco IOS Software versions are affected by this vulnerability. No other Cisco products are currently known to be affected by this vulnerability. Details ======= TCP provides reliable data transmission services in packet-switched network environments. TCP corresponds to the transport layer (Layer 4) of the OSI reference model. Among the services TCP provides are stream data transfer, reliability, efficient flow control, full-duplex operation, and multiplexing. When TCP connections are terminated in Cisco IOS Software, they are allocated a transmission control block (TCB). All allocated TCBs, associated TCP port numbers, and the TCP state are displayed in the output of the "show tcp brief all" command-line interface (CLI) command. Cisco IOS Software version 15.1(2)T contains a vulnerability that could cause an embryonic TCP connection to remain in SYNRCVD or SYNSENT state without a further TCP state transition. Examining the output of the "show tcp brief all" command multiple times will indicate if TCP sessions remain in one of these states. This vulnerability is triggered only by TCP traffic that is terminated by or originated from the device. Transit traffic will not trigger this vulnerability. Both connections to and from the router could trigger this vulnerability. An example of a connection to the router is that you may still be able to ping the device, but fail to establish a TELNET or SSH connection to the device. For example, an administrator may still be able to ping the device but fail to establish a Telnet or SSH connection to the device. Administrators who attempt a Telnet or a SSH connection to a remote device from the CLI prompt will encounter a hung session and the "Trying ..." prompt. The connection that is initiated or terminated by the router can be removed from the socket table by clearing the associated TCB with the "clear tcp tcb 0x
" command. Devices could be vulnerable if examining the output of the CLI command "debug ip tcp transactions", displays the error messages "connection queue limit reached: port " or "No wild listener: port ". Devices could also be vulnerable if output from repetitive show tcp brief all CLI commands indicates many TCBs in the state SYNRCVD or SYNSENT. The following example shows a device that has several HTTP, SSH, and Telnet sessions in the TCP SYNRCVD state: Example#show tcp brief all TCB Local Address Foreign Address (state) 07C2D6C8 192.168.0.2.443 192.168.0.5.11660 SYNRCVD 07C38128 192.168.0.2.23 192.168.0.5.35018 SYNRCVD 07C2DD60 192.168.0.2.443 192.168.0.5.19316 SYNRCVD 07C2A8A0 192.168.0.2.80 192.168.0.5.13818 SYNRCVD Any TCP sessions can be cleared by clearing the associated TCB with "clear tcp tcb 0x
". Alternatively Administrators can clear all TCBs at once by issuing "clear tcp tcb *". Note: This will clear all active and hung TCP connections. This vulnerability is documented in the Cisco bug ID CSCti18193. This vulnerability has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2010-2827. Some TCP application specific information is provided in the following sections: Telnet and SSH +------------- Telnet can not be explicitly disabled on a Cisco IOS device. Configuring "transport input none" on the vty lines of a vulnerable device will prevent it from being exploited on TCP port 23. However, if the Cisco IOS SSH server feature is configured on the device, "transport input none" will not prevent the device from being exploited on TCP port 22. Configuration of vty access control lists can partially mitigate this vulnerability because the vulnerability can be exploited using spoofed IP source addresses. Border Gateway Protocol +---------------------- Routers that are configured with Border Gateway Protocol (BGP) can be protected further by using the Generalized Time to Live (TTL) Security Mechanism (GTSM) feature. GTSM allows users to configure the expected TTL of a packet between a source and destination address. Packets that fail the GTSM check will be dropped before TCP processing occurs, which prevents an attacker from exploiting this vulnerability through BGP. GTSM is implemented with the command "ttl-security hops". Further information on protecting BGP can be found in "Protecting Border Gateway Protocol for the Enterprise" (http://www.cisco.com/web/about/security/intelligence/protecting_bgp.html#7). TCP MD5 Authentication for BGP does not prevent this vulnerability from being exploited. Vulnerability Scoring Details ============================= Cisco has provided a score for the vulnerability in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at: http://intellishield.cisco.com/security/alertmanager/cvss * CSCti18193 ("TCP connections never timeout in IOS 15.1(2)T") CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of this vulnerability may prevent some TCP applications on Cisco IOS Software from accepting any new connections. Exploitation could also prevent remote access to the affected system via the vtys. Remote access to the affected device via out-of-band connectivity to the console port should still be available. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS Software table (below) names a Cisco IOS release train. If a release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +---------------------------------------+ | Major | Availability of Repaired | | Release | Releases | |------------+--------------------------| | Affected | | | 12.x-Based | First Fixed Release | | Releases | | |------------+--------------------------| | 12.0 - | 12.0 through 12.4 based | | 12.4 | releases are not | | | affected | |------------+--------------------------| | Affected | | | 15.0-Based | First Fixed Release | | Releases | | |------------+--------------------------| | 15.0 | There are no affected | | | 15.0 based releases | |------------+--------------------------| | Affected | | | 15.1-Based | First Fixed Release | | Releases | | |------------+--------------------------| | | 15.1(2)T0a | | | | | | 15.1(2)T1; available on | | | 20-AUG-2010 | | 15.1T | | | | Releases prior to 15.1 | | | (2)T are not vulnerable. | | | The vulnerability is | | | first fixed in release | | | 15.1(2)T0a. | +---------------------------------------+ Workarounds =========== The only complete workaround to mitigate this vulnerability is to disable the specific features that make a device vulnerable, if this action is feasible. Allowing only legitimate devices to connect to affected devices will help limit exposure to this vulnerability. Refer to the following Control Plane Policing and Configuring Infrastructure Access Lists subsections for further details. Because a TCP three-way handshake is not required, the mitigation must be combined with anti-spoofing measures on the network edge to increase effectiveness. Additional mitigations that can be deployed on Cisco devices within the network are available in the Cisco Applied Mitigation Bulletin companion document for this advisory, which is available at the following link: http://www.cisco.com/warp/public/707/cisco-amb-20100812-tcp.shtml Cisco Guide to Harden Cisco IOS Devices +-------------------------------------- The Cisco Guide to Harden Cisco IOS Devices provides examples of many useful techniques to mitigate TCP state manipulation vulnerabilities. These include: * Infrastructure Access Control Lists (iACL) * Receive Access Control Lists (rACL) * Transit Access Control Lists (tACL) * vty Access Control Lists * Control Plane Policing (CoPP) * Control Plane Protection (CPPr) For more information on these topics, consult "Cisco Guide to Harden Cisco IOS Devices" (http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080120f48.shtml). CoPP +--- For devices that need to offer TCP services, administrators can use CoPP to block TCP traffic from untrusted sources that is destined to the affected device. Cisco IOS Software Releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T support the CoPP feature. CoPP may be configured on a device to protect the management and control planes and minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic sent to infrastructure devices in accordance with existing security policies and configurations. The following example can be adapted to specific network configurations: ! !-- The 192.168.1.0/24 network and the 172.16.1.1 host are trusted. !-- Everything else is not trusted. The following access list is used !-- to determine what traffic needs to be dropped by a control plane !-- policy (the CoPP feature.) If the access list matches (permit), !-- then traffic will be dropped. If the access list does not !-- match (deny), then traffic will be processed by the router. !-- Note that TCP ports 22 and 23 are examples; this !-- configuration needs to be expanded to include all used !-- TCP ports. ! access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 22 access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 23 access-list 100 deny tcp host 172.16.1.1 any eq 22 access-list 100 deny tcp host 172.16.1.1 any eq 23 access-list 100 permit tcp any any ! !-- Permit (Police or Drop)/Deny (Allow) all other Layer3 and Layer4 !-- traffic in accordance with existing security policies and !-- configurations for traffic that is authorized to be sent !-- to infrastructure devices. !-- Create a class map for traffic that will be policed by !-- the CoPP feature. ! class-map match-all drop-tcp-class match access-group 100 ! !-- Create a policy map that will be applied to the !-- Control Plane of the device, and add the "drop-tcp-traffic" !-- class map. ! policy-map control-plane-policy class drop-tcp-class drop ! !-- Apply the policy map to the control plane of the !-- device. ! control-plane service-policy input control-plane-policy Warning: Because a TCP three-way handshake is not required to exploit this vulnerability, it is possible to spoof the IP address of the sender, which could defeat access control lists (ACLs) that permit communication to these ports from trusted IP addresses. In the preceding CoPP example, the access control entries (ACEs) that match the potential exploit packets with the "permit" action result in these packets being discarded by the policy-map "drop" function, while packets that match the "deny" action (not shown) are not affected by the policy-map drop function. Additional information on the configuration and use of the CoPP feature can be found at "Control Plane Policing Implementation Best Practices" (http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html) and "Control Plane Policing" (http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html). Configuring iACLs +---------------- Although it is often difficult to block traffic that transits a network, it is possible to identify traffic that should never be allowed to target infrastructure devices and block that traffic at the border of your network. Infrastructure ACLs are considered a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for this specific vulnerability. The white paper "Protecting Your Core: Infrastructure Protection Access Control Lists" (http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801afc76.shtml) presents guidelines and recommended deployment techniques for infrastructure protection ACLs. BGP Considerations +---------------- GTSM can help prevent exploitation of this vulnerability by means of the BGP port because packets that originate from devices that do not pass the TTL check configured by GTSM are dropped before any TCP processing occurs. For information on GTSM refer to "BGP Support for TTL Security Check" (http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gt_btsh.html) and "BGP Time To Live Security Check" (http://www.cisco.com/web/about/security/intelligence/protecting_bgp.html#7). Embedded Event Manager (EEM) +--------------------------- A Cisco IOS Embedded Event Manager (EEM) policy that is based on Tool Command Language (Tcl) can be used on vulnerable Cisco IOS devices to identify and detect a hung, extended, or indefinite TCP connection that is caused by this vulnerability. The policy allows administrators to monitor TCP connections on a Cisco IOS device. When Cisco IOS EEM detects potential exploitation of this vulnerability, the policy can trigger a response by sending a syslog message or a Simple Network Management Protocol (SNMP) trap to clear the TCP connection. The example policy provided in this document is based on a Tcl script that monitors and parses the output from two commands at defined intervals, produces a syslog message when the monitor threshold reaches its configured value, and can reset the TCP connection. The Tcl script is available for download at the "Cisco Beyond: Embedded Event Manager (EEM) Scripting Community" (http://www.cisco.com/go/ciscobeyond) at the following link http://forums.cisco.com/eforum/servlet/EEM?page=eem&fn=script&scriptId=2041, and the device sample configuration is provided below. ! !-- Location where the Tcl script will be stored ! event manager directory user policy disk0:/eem ! !-- Define variable and set the monitoring interval !-- as an integer (expressed in seconds) ! event manager environment EEM_MONITOR_INTERVAL 60 ! !-- Define variable and set the threshold value as !-- an integer for the number of retransmissions !-- that determine if the TCP connection is hung !-- (a recommended value to use is 15) ! event manager environment EEM_MONITOR_THRESHOLD 15 ! !-- Define variable and set the value to "yes" to !-- enable the clearing of hung TCP connections ! event manager environment EEM_MONITOR_CLEAR yes ! !-- Define variable and set to the TCP connection !-- state or states that script will monitor, which !-- can be a single state or a space-separated list !-- of states ! event manager environment EEM_MONITOR_STATES SYNRCVD SYNSENT ! !-- Register the script as a Cisco EEM policy ! event manager policy monitor-sockets.tcl Obtaining Fixed Software ======================== Cisco has released free software updates that address this vulnerability. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. This vulnerability was reported to Cisco by a customer. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at: http://www.cisco.com/warp/public/707/cisco-sa-20100812-tcp.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +------------------------------------------------------------+ | Revision 1.0 | 2010-August-12 | Initial public release. | +------------------------------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt. +-------------------------------------------------------------------- Copyright 2008-2010 Cisco Systems, Inc. All rights reserved. +-------------------------------------------------------------------- Updated: Aug 12, 2010 Document ID: 112099 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkxkdOsACgkQ86n/Gc8U/uApYwCfeZAQ3FcneSd+MEaIn+qMV2zb bYgAn2Zg6rcHlDyLaPepO/C0hwINLk2v =5Pfg -----END PGP SIGNATURE----- From swmike at swm.pp.se Fri Aug 13 00:20:04 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 13 Aug 2010 07:20:04 +0200 (CEST) Subject: Cost of transit and options in APAC In-Reply-To: <02815161-1DF1-44ED-8646-52E2DD2CD86A@queuefull.net> References: <13485638.719.1281554976626.JavaMail.franck@franck-martins-macbook-pro.local> <4C62FFAE.1090608@bogus.com> <01FC6493-65A8-45D6-809A-06C65565F4B9@queuefull.net> <4C6320FA.80901@bogus.com> <20100812122647.GA5470@blackrose.org> <02815161-1DF1-44ED-8646-52E2DD2CD86A@queuefull.net> Message-ID: On Thu, 12 Aug 2010, Benson Schliesser wrote: > Further, how does the situation compare to past examples like Europe? Countries in Europe are all in different phases of competition and pricing. There is at least 10x difference in transit prices across Europe, with central and northern Europe being the cheapest, and southern and eastern being the most expensive. I agree totally with Mr Gilmore that it's all about competition. When there are 3+ (preferrably 4+) providers or something and the market is de-regulated then you get huge downward pressure on price and you soon hit levels of 5-20% operating margin and a mature market. I still remember back around 2000-2001 when we purchased 30 megs of transit from Ebone at around 120 USD per megabit/s, 2-3 years later the price was down to ~10-20 USD/megabit/s and then it's slowly decreased over time from that, basically as new faster technology came online so things could be done cheaper and at grander scale (you need the same amount of people to run a 155 megabit/s network as a 5*10G network, so price per bit goes down. APAC needs to go thru this as well, but things are generally still heavily regulated and the people are still adopting internet use instead of the situation in most of Europe and US where "everybody who wants Internet connection has one". It's when mass market deployment and deregulation happen together that sensible pricing occurs. Oh, competition needs to happen at all levels, from fiber in the ground to end user access. You can't have any single entity having a (de facto) monopoly/duopoly on any part of the chain. You need 4+ here as well (or a neutral party who just do one part and does it well, like municipal fiber rented at decent prices to anyone who wants to rent). -- Mikael Abrahamsson email: swmike at swm.pp.se From ashoat at cs.washington.edu Fri Aug 13 01:07:01 2010 From: ashoat at cs.washington.edu (Ashoat Tevosyan) Date: Thu, 12 Aug 2010 23:07:01 -0700 Subject: Pacific Northwest downtime? Message-ID: Hey guys, Anybody else in the Pacific Northwest notice some sites down? I'm using Comcast here at home, and I can't reach anything over at Hurricane Electric. I can confirm that HE is reachable from the University of Washington. Thanks, Ashoat From ashoat at cs.washington.edu Fri Aug 13 01:19:09 2010 From: ashoat at cs.washington.edu (Ashoat Tevosyan) Date: Thu, 12 Aug 2010 23:19:09 -0700 Subject: Pacific Northwest downtime? In-Reply-To: References: Message-ID: Never mind, back up! Apparently there was a problem at Comcast. Thanks, Ashoat On Thu, Aug 12, 2010 at 11:07 PM, Ashoat Tevosyan wrote: > Hey guys, > > Anybody else in the Pacific Northwest notice some sites down? I'm using > Comcast here at home, and I can't reach anything over at Hurricane Electric. > I can confirm that HE is reachable from the University of Washington. > > Thanks, > Ashoat > From john at hypergeek.net Fri Aug 13 01:32:16 2010 From: john at hypergeek.net (John A. Kilpatrick) Date: Thu, 12 Aug 2010 23:32:16 -0700 Subject: Pacific Northwest downtime? In-Reply-To: References: Message-ID: <93B6A0FD-03A5-4C57-BF33-AE95DB48E67A@hypergeek.net> Yeah, I saw it too. My traceroute was dying at an IP belonging to Global Crossing and the DNS looked like it was at 11 Great Oaks. I called Comcast to report it, but they just kept saying I should reboot my modem. On Aug 12, 2010, at 11:19 PM, Ashoat Tevosyan wrote: > Never mind, back up! Apparently there was a problem at Comcast. > > Thanks, > Ashoat > > On Thu, Aug 12, 2010 at 11:07 PM, Ashoat Tevosyan > wrote: > >> Hey guys, >> >> Anybody else in the Pacific Northwest notice some sites down? I'm using >> Comcast here at home, and I can't reach anything over at Hurricane Electric. >> I can confirm that HE is reachable from the University of Washington. >> >> Thanks, >> Ashoat >> -- John A. Kilpatrick john at hypergeek.net Email| http://www.hypergeek.net/ john-page at hypergeek.net Text pages| ICQ: 19147504 remember: no obstacles/only challenges From jeffw at he.net Fri Aug 13 01:36:22 2010 From: jeffw at he.net (Jeff Walter) Date: Thu, 12 Aug 2010 23:36:22 -0700 Subject: Pacific Northwest downtime? In-Reply-To: <93B6A0FD-03A5-4C57-BF33-AE95DB48E67A@hypergeek.net> References: <93B6A0FD-03A5-4C57-BF33-AE95DB48E67A@hypergeek.net> Message-ID: <4C64E7E6.2090001@he.net> We contacted GBLX and the issue was resolved shortly thereafter. Last time this happened one of their internal routers hung and someone kicked it. No idea if this was the same type of issue. In this case, more that just traffic between us and Comcast was affected, at least according to a friend of mine who's on Comcast. +---------------- H U R R I C A N E - E L E C T R I C ----------------+ | Jeff Walter http://www.he.net/ AS6939 Phone 510/580-4108 | | Network Engineer Colocation, Dedicated Cell 510/771-7036 | | jeffw at he.net Servers, Direct Connections Fax 510/580-4152 | +----------------- I N T E R N E T - S E R V I C E S -----------------+ On 8/12/2010 11:32 PM, John A. Kilpatrick wrote: > > Yeah, I saw it too. My traceroute was dying at an IP belonging to Global Crossing and the DNS looked like it was at 11 Great Oaks. I called Comcast to report it, but they just kept saying I should reboot my modem. > > On Aug 12, 2010, at 11:19 PM, Ashoat Tevosyan wrote: > >> Never mind, back up! Apparently there was a problem at Comcast. >> >> Thanks, >> Ashoat >> >> On Thu, Aug 12, 2010 at 11:07 PM, Ashoat Tevosyan >> wrote: >> >>> Hey guys, >>> >>> Anybody else in the Pacific Northwest notice some sites down? I'm using >>> Comcast here at home, and I can't reach anything over at Hurricane Electric. >>> I can confirm that HE is reachable from the University of Washington. >>> >>> Thanks, >>> Ashoat >>> > > -- > John A. Kilpatrick > john at hypergeek.net Email| http://www.hypergeek.net/ > john-page at hypergeek.net Text pages| ICQ: 19147504 > remember: no obstacles/only challenges > > -------------- next part -------------- A non-text attachment was scrubbed... Name: jeffw.vcf Type: text/x-vcard Size: 319 bytes Desc: not available URL: From jeffrey.lyon at blacklotus.net Fri Aug 13 01:36:43 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 13 Aug 2010 11:06:43 +0430 Subject: Pacific Northwest downtime? In-Reply-To: <93B6A0FD-03A5-4C57-BF33-AE95DB48E67A@hypergeek.net> References: <93B6A0FD-03A5-4C57-BF33-AE95DB48E67A@hypergeek.net> Message-ID: Did you wait 30 seconds before you plugged it back in? Jeff On Fri, Aug 13, 2010 at 11:02 AM, John A. Kilpatrick wrote: > > Yeah, I saw it too. ?My traceroute was dying at an IP belonging to Global Crossing and the DNS looked like it was at 11 Great Oaks. ?I called Comcast to report it, but they just kept saying I should reboot my modem. > > On Aug 12, 2010, at 11:19 PM, Ashoat Tevosyan wrote: > >> Never mind, back up! Apparently there was a problem at Comcast. >> >> Thanks, >> Ashoat >> >> On Thu, Aug 12, 2010 at 11:07 PM, Ashoat Tevosyan >> wrote: >> >>> Hey guys, >>> >>> Anybody else in the Pacific Northwest notice some sites down? I'm using >>> Comcast here at home, and I can't reach anything over at Hurricane Electric. >>> I can confirm that HE is reachable from the University of Washington. >>> >>> Thanks, >>> Ashoat >>> > > -- > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?John A. Kilpatrick > john at hypergeek.net ? ? ? ? ? ? ? ?Email| ? ? http://www.hypergeek.net/ > john-page at hypergeek.net ? ? ?Text pages| ? ? ? ? ?ICQ: 19147504 > ? ? ? ? ? ? ? ? ?remember: ?no obstacles/only challenges > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From john at hypergeek.net Fri Aug 13 01:39:42 2010 From: john at hypergeek.net (John A. Kilpatrick) Date: Thu, 12 Aug 2010 23:39:42 -0700 Subject: Pacific Northwest downtime? In-Reply-To: <4C64E7E6.2090001@he.net> References: <93B6A0FD-03A5-4C57-BF33-AE95DB48E67A@hypergeek.net> <4C64E7E6.2090001@he.net> Message-ID: On Aug 12, 2010, at 11:36 PM, Jeff Walter wrote: > In this case, more that just traffic between us and Comcast was affected, at least according to a friend of mine who's on Comcast. Yeah, things were wonky for a while. Like the application for programming my Harmony One couldn't contact Logitech's servers. But since my mail server is at he.net that was the big thing I noticed. :) But of course, step one, reboot my modem...*sigh* -- John A. Kilpatrick john at hypergeek.net Email| http://www.hypergeek.net/ john-page at hypergeek.net Text pages| ICQ: 19147504 remember: no obstacles/only challenges From franck at genius.com Fri Aug 13 01:41:34 2010 From: franck at genius.com (Franck Martin) Date: Fri, 13 Aug 2010 18:41:34 +1200 (FJT) Subject: Cost of transit and options in APAC In-Reply-To: Message-ID: <19800574.203.1281681690389.JavaMail.franck@franck-martins-macbook-pro.local> It always amaze me how the word de-regulated is so misused. When there is a monopoly the regulation is in fact very very light: Acme co is the monopoly and government cash in dividends/license fees and just check they don't do anything really silly. When there is competition this is when you have a heavy regulation, because all the players have now to play nicely with each others (access to each other network, anti competitive practices, keeping your number, roaming, inter-exchange, spectrum allocation,...). When competition comes the regulatory unit becomes bigger. In short competition increase regulation, it certainly does not decrease it. ----- Original Message ----- From: "Mikael Abrahamsson" To: "Benson Schliesser" Cc: "nanog" Sent: Friday, 13 August, 2010 5:20:04 PM Subject: Re: Cost of transit and options in APAC On Thu, 12 Aug 2010, Benson Schliesser wrote: > Further, how does the situation compare to past examples like Europe? Countries in Europe are all in different phases of competition and pricing. There is at least 10x difference in transit prices across Europe, with central and northern Europe being the cheapest, and southern and eastern being the most expensive. I agree totally with Mr Gilmore that it's all about competition. When there are 3+ (preferrably 4+) providers or something and the market is de-regulated then you get huge downward pressure on price and you soon hit levels of 5-20% operating margin and a mature market. From mpetach at netflight.com Fri Aug 13 01:42:53 2010 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 12 Aug 2010 23:42:53 -0700 Subject: Pacific Northwest downtime? In-Reply-To: <4C64E7E6.2090001@he.net> References: <93B6A0FD-03A5-4C57-BF33-AE95DB48E67A@hypergeek.net> <4C64E7E6.2090001@he.net> Message-ID: On Thu, Aug 12, 2010 at 11:36 PM, Jeff Walter wrote: > We contacted GBLX and the issue was resolved shortly thereafter. ?Last time > this happened one of their internal routers hung and someone kicked it. ?No > idea if this was the same type of issue. > > In this case, more that just traffic between us and Comcast was affected, at > least according to a friend of mine who's on Comcast. There are definite reports that it affected connectivity to some portions of Yahoo for some comcast users in the Bay Area as well. Matt *offers a new roll of duct tape to Comcast for their routers* From jeffw at he.net Fri Aug 13 01:52:06 2010 From: jeffw at he.net (Jeff Walter) Date: Thu, 12 Aug 2010 23:52:06 -0700 Subject: Pacific Northwest downtime? In-Reply-To: References: <93B6A0FD-03A5-4C57-BF33-AE95DB48E67A@hypergeek.net> <4C64E7E6.2090001@he.net> Message-ID: <4C64EB96.3050207@he.net> On 8/12/2010 11:42 PM, Matthew Petach wrote: > There are definite reports that it affected connectivity to some > portions of Yahoo > for some comcast users in the Bay Area as well. > > Matt > *offers a new roll of duct tape to Comcast for their routers* Just got confirmation from GBLX... Router seized. Perhaps some WD-40 is in order? +---------------- H U R R I C A N E - E L E C T R I C ----------------+ | Jeff Walter http://www.he.net/ AS6939 Phone 510/580-4108 | | Network Engineer Colocation, Dedicated Cell 510/771-7036 | | jeffw at he.net Servers, Direct Connections Fax 510/580-4152 | +----------------- I N T E R N E T - S E R V I C E S -----------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: jeffw.vcf Type: text/x-vcard Size: 319 bytes Desc: not available URL: From ken.gilmour at gmail.com Fri Aug 13 04:51:16 2010 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Fri, 13 Aug 2010 11:51:16 +0200 Subject: Anyone have a spare KVM in Equinix HK? Message-ID: Hi, This probably seems like an unusual request, but we urgently need to install some equipment in Equinix HK and are having problems applying some iLO licenses, Does anyone have a spare KVM in the datacenter there that we can purchase from you, rather than ordering one and drop shipping it which could take a few days... We only need a small, cheapo one with 8 ports or less (but network enabled). Thanks! Ken From Valdis.Kletnieks at vt.edu Fri Aug 13 07:04:07 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 13 Aug 2010 08:04:07 -0400 Subject: Pacific Northwest downtime? In-Reply-To: Your message of "Thu, 12 Aug 2010 23:52:06 PDT." <4C64EB96.3050207@he.net> References: <93B6A0FD-03A5-4C57-BF33-AE95DB48E67A@hypergeek.net> <4C64E7E6.2090001@he.net> <4C64EB96.3050207@he.net> Message-ID: <62773.1281701047@localhost> On Thu, 12 Aug 2010 23:52:06 PDT, Jeff Walter said: > Just got confirmation from GBLX... Router seized. Perhaps some WD-40 is > in order? No caffeine yet. Did you mean "router froze up", or "router taken into possession by creditors and/or law enforcement officials"? ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rs at seastrom.com Fri Aug 13 12:18:42 2010 From: rs at seastrom.com (Robert Seastrom) Date: Fri, 13 Aug 2010 13:18:42 -0400 Subject: Lightly used IP addresses Message-ID: <30FA2C29-F91B-4C2F-AD08-8EF49957C66A@seastrom.com> At the risk of getting called out for posting possibly operationally significant stuff in the middle of a massive retrospective about WCOM's acquisitions, here's a circleid post from a couple days ago from John Curran at ARIN. http://www.circleid.com/posts/psst_interested_in_some_lightly_used_ip_addresses/ Discuss. :-) Sent at 55 MPH or slower from my iPhone From johnl at iecc.com Fri Aug 13 12:36:52 2010 From: johnl at iecc.com (John Levine) Date: 13 Aug 2010 17:36:52 -0000 Subject: Lightly used IP addresses In-Reply-To: <30FA2C29-F91B-4C2F-AD08-8EF49957C66A@seastrom.com> Message-ID: <20100813173652.84198.qmail@joyce.lan> >http://www.circleid.com/posts/psst_interested_in_some_lightly_used_ip_addresses/ >Discuss. :-) I don't entirely understand the process. Here's the flow chart as far as I've figured it out: 1. A sells a /20 of IPv4 space to B for, say, $5,000 2. A tells ARIN to transfer the chunk to B 3. ARIN says no, B hasn't shown that they need it 4. A and B say screw it, and B announces the space anyway 5. ??? R's, John From brandon.galbraith at gmail.com Fri Aug 13 12:42:15 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Fri, 13 Aug 2010 12:42:15 -0500 Subject: Lightly used IP addresses In-Reply-To: <20100813173652.84198.qmail@joyce.lan> References: <30FA2C29-F91B-4C2F-AD08-8EF49957C66A@seastrom.com> <20100813173652.84198.qmail@joyce.lan> Message-ID: On Fri, Aug 13, 2010 at 12:36 PM, John Levine wrote: > I don't entirely understand the process. Here's the flow chart as far > as I've figured it out: > > 1. A sells a /20 of IPv4 space to B for, say, $5,000 > > 2. A tells ARIN to transfer the chunk to B > > 3. ARIN says no, B hasn't shown that they need it > > 4. A and B say screw it, and B announces the space anyway > > 5. ??? > > Alternate #4: A "rents" the space to B without ARIN knowing it, while A continues to claim that the space belongs to them. -- Brandon Galbraith Voice: 630.492.0464 From owen at delong.com Fri Aug 13 12:44:12 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 13 Aug 2010 10:44:12 -0700 Subject: Lightly used IP addresses In-Reply-To: <20100813173652.84198.qmail@joyce.lan> References: <20100813173652.84198.qmail@joyce.lan> Message-ID: <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> On Aug 13, 2010, at 10:36 AM, John Levine wrote: >> http://www.circleid.com/posts/psst_interested_in_some_lightly_used_ip_addresses/ >> Discuss. :-) > > I don't entirely understand the process. Here's the flow chart as far > as I've figured it out: > > 1. A sells a /20 of IPv4 space to B for, say, $5,000 > > 2. A tells ARIN to transfer the chunk to B > > 3. ARIN says no, B hasn't shown that they need it > > 4. A and B say screw it, and B announces the space anyway > > 5. ??? > > R's, > John 6. ARIN receives a fraud/abuse complaint that A's space is being used by B. 7. ARIN discovers that A is no longer using the space in accordance with their RSA 8. ARIN reclaims the space and A and B are left to figure out who owes what to whom. From ken at sizone.org Fri Aug 13 12:53:51 2010 From: ken at sizone.org (Ken Chase) Date: Fri, 13 Aug 2010 13:53:51 -0400 Subject: Lightly used IP addresses In-Reply-To: <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> Message-ID: <20100813175351.GU2582@sizone.org> On Fri, Aug 13, 2010 at 10:44:12AM -0700, Owen DeLong said: >6. ARIN receives a fraud/abuse complaint that A's space is being used by B. >7. ARIN discovers that A is no longer using the space in accordance with their RSA >8. ARIN reclaims the space and A and B are left to figure out who owes what to whom. > How does this step (8) work, this 'reclaiming'? /kc -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From jeffrey.lyon at blacklotus.net Fri Aug 13 12:53:56 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 13 Aug 2010 22:23:56 +0430 Subject: Lightly used IP addresses In-Reply-To: <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> Message-ID: 9. I could point out so many cases of "justification abuse" or outright fraudulent justification and I bet nothing would actually transpire. My two cents. Jeff On Fri, Aug 13, 2010 at 10:14 PM, Owen DeLong wrote: > > On Aug 13, 2010, at 10:36 AM, John Levine wrote: > >>> http://www.circleid.com/posts/psst_interested_in_some_lightly_used_ip_addresses/ >>> Discuss. ?:-) >> >> I don't entirely understand the process. ?Here's the flow chart as far >> as I've figured it out: >> >> 1. ?A sells a /20 of IPv4 space to B for, say, $5,000 >> >> 2. ?A tells ARIN to transfer the chunk to B >> >> 3. ?ARIN says no, B hasn't shown that they need it >> >> 4. ?A and B say screw it, and B announces the space anyway >> >> 5. ???? >> >> R's, >> John > > 6. ? ? ?ARIN receives a fraud/abuse complaint that A's space is being used by B. > 7. ? ? ?ARIN discovers that A is no longer using the space in accordance with their RSA > 8. ? ? ?ARIN reclaims the space and A and B are left to figure out who owes what to whom. > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From brandon.galbraith at gmail.com Fri Aug 13 12:54:21 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Fri, 13 Aug 2010 12:54:21 -0500 Subject: Lightly used IP addresses In-Reply-To: <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> Message-ID: On Fri, Aug 13, 2010 at 12:44 PM, Owen DeLong wrote: > 6. ARIN receives a fraud/abuse complaint that A's space is being used > by B. > 7. ARIN discovers that A is no longer using the space in accordance > with their RSA > 8. ARIN reclaims the space and A and B are left to figure out who owes > what to whom. > > So is there a fine line between "selling"/"renting" the space to B and providing 1Mbit of bandwidth over a GRE tunnel to B and allowing them to announce the space via any other transit provider? I'm just curious what the difference is (besides a bit of technical work with the latter). It will be interesting to see what happens as the last of the IPv4 space is exhausted. -- Brandon Galbraith Voice: 630.492.0464 From bmanning at vacation.karoshi.com Fri Aug 13 12:55:54 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 13 Aug 2010 17:55:54 +0000 Subject: Lightly used IP addresses In-Reply-To: <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> Message-ID: <20100813175554.GB7558@vacation.karoshi.com.> On Fri, Aug 13, 2010 at 10:44:12AM -0700, Owen DeLong wrote: > > On Aug 13, 2010, at 10:36 AM, John Levine wrote: > > >> http://www.circleid.com/posts/psst_interested_in_some_lightly_used_ip_addresses/ > >> Discuss. :-) > > > > I don't entirely understand the process. Here's the flow chart as far > > as I've figured it out: > > > > 1. A sells a /20 of IPv4 space to B for, say, $5,000 > > > > 2. A tells ARIN to transfer the chunk to B > > > > 3. ARIN says no, B hasn't shown that they need it > > > > 4. A and B say screw it, and B announces the space anyway > > > > 5. ??? > > > > R's, > > John > > 6. ARIN receives a fraud/abuse complaint that A's space is being used by B. > 7. ARIN discovers that A is no longer using the space in accordance with their RSA > 8. ARIN reclaims the space and A and B are left to figure out who owes what to whom. > > could you provide 4 numbers for me please? ) % of ARIN managed resource covered by standard RSA? ) % of ARIN managed legacy resource covered by legacy RSA? ) % of ARIN managed legacy resource not otherwise covered? ) % of ARIN region entities (A & B above) that have offices/relationships with other RIRs that have a divergent transfer process in place? I think your analysis might be true for my first bucket, am less sure it would work for the remaining three. --bill From trelane at trelane.net Fri Aug 13 12:58:29 2010 From: trelane at trelane.net (Andrew Kirch) Date: Fri, 13 Aug 2010 13:58:29 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> Message-ID: <4C6587C5.6010600@trelane.net> Jeff, Go for it. I've always wondered what ARIN had between it's legs. Andrew On 8/13/2010 1:53 PM, Jeffrey Lyon wrote: > 9. I could point out so many cases of "justification abuse" or > outright fraudulent justification and I bet nothing would actually > transpire. > > My two cents. > > Jeff > > > On Fri, Aug 13, 2010 at 10:14 PM, Owen DeLong wrote: >> On Aug 13, 2010, at 10:36 AM, John Levine wrote: >> >>>> http://www.circleid.com/posts/psst_interested_in_some_lightly_used_ip_addresses/ >>>> Discuss. :-) >>> I don't entirely understand the process. Here's the flow chart as far >>> as I've figured it out: >>> >>> 1. A sells a /20 of IPv4 space to B for, say, $5,000 >>> >>> 2. A tells ARIN to transfer the chunk to B >>> >>> 3. ARIN says no, B hasn't shown that they need it >>> >>> 4. A and B say screw it, and B announces the space anyway >>> >>> 5. ??? >>> >>> R's, >>> John >> 6. ARIN receives a fraud/abuse complaint that A's space is being used by B. >> 7. ARIN discovers that A is no longer using the space in accordance with their RSA >> 8. ARIN reclaims the space and A and B are left to figure out who owes what to whom. >> >> >> > > From Greg.Whynott at oicr.on.ca Fri Aug 13 12:59:51 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Fri, 13 Aug 2010 13:59:51 -0400 Subject: Lightly used IP addresses In-Reply-To: <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> Message-ID: <2D23038B-7146-4063-BA77-41DB2C1057B5@oicr.on.ca> how does ARIN or whomever deal with similar situations where someone is advertising un-allocated, un-assigned by ARIN IP space in NA? do they have a deal/agreement with the 'backbone' providers? -g >> > > 6. ARIN receives a fraud/abuse complaint that A's space is being used by B. > 7. ARIN discovers that A is no longer using the space in accordance with their RSA > 8. ARIN reclaims the space and A and B are left to figure out who owes what to whom. > > From bmanning at vacation.karoshi.com Fri Aug 13 12:59:15 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 13 Aug 2010 17:59:15 +0000 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> Message-ID: <20100813175915.GA8181@vacation.karoshi.com.> On Fri, Aug 13, 2010 at 10:23:56PM +0430, Jeffrey Lyon wrote: > 9. I could point out so many cases of "justification abuse" or > outright fraudulent justification and I bet nothing would actually > transpire. > > My two cents. > > Jeff > if you have data on abuse, please use the ARIN abuse reporting tools. https://www.arin.net/abuse.html --bill From aaron at wholesaleinternet.net Fri Aug 13 13:06:41 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Fri, 13 Aug 2010 13:06:41 -0500 Subject: Lightly used IP addresses In-Reply-To: <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> Message-ID: <02ba01cb3b12$4a1e4920$de5adb60$@net> On Aug 13, 2010, at 10:36 AM, John Levine wrote: >> http://www.circleid.com/posts/psst_interested_in_some_lightly_used_ip_addres ses/ >> Discuss. :-) > > I don't entirely understand the process. Here's the flow chart as far > as I've figured it out: > > 1. A sells a /20 of IPv4 space to B for, say, $5,000 > > 2. A tells ARIN to transfer the chunk to B > > 3. ARIN says no, B hasn't shown that they need it > > 4. A and B say screw it, and B announces the space anyway > > 5. ??? > > R's, > John Owen Said: 6. ARIN receives a fraud/abuse complaint that A's space is being used by B. 7. ARIN discovers that A is no longer using the space in accordance with their RSA 8. ARIN reclaims the space and A and B are left to figure out who owes what to whom. You know I love you Owen. :) 9. A sues ARIN for tortuous contract interference. 10. B sues ARIN for same. 11. C and D join the law suit. 12. Judges step in. 13. ARIN gets mired in lawsuit after lawsuit 14. Dogs and cats start living together From jeffnanog at hvnc.net Fri Aug 13 13:13:30 2010 From: jeffnanog at hvnc.net (JEff) Date: Fri, 13 Aug 2010 14:13:30 -0400 Subject: Lightly used IP addresses In-Reply-To: <02ba01cb3b12$4a1e4920$de5adb60$@net> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <02ba01cb3b12$4a1e4920$de5adb60$@net> Message-ID: <4C658B4A.3070603@hvnc.net> On 8/13/10 2:06 PM, Aaron Wendel wrote: > > You know I love you Owen. :) > > 9. A sues ARIN for tortuous contract interference. > 10. B sues ARIN for same. > 11. C and D join the law suit. > 12. Judges step in. > 13. ARIN gets mired in lawsuit after lawsuit > 14. Dogs and cats start living together Can we just cross the streams now, before the walls start bleeding? Jeff From johnl at iecc.com Fri Aug 13 13:15:51 2010 From: johnl at iecc.com (John R. Levine) Date: 13 Aug 2010 14:15:51 -0400 Subject: Lightly used IP addresses In-Reply-To: <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> Message-ID: >> I don't entirely understand the process. Here's the flow chart as far >> as I've figured it out: >> >> 1. A sells a /20 of IPv4 space to B for, say, $5,000 >> >> 2. A tells ARIN to transfer the chunk to B >> >> 3. ARIN says no, B hasn't shown that they need it >> >> 4. A and B say screw it, and B announces the space anyway >> >> 5. ??? > > 6. ARIN receives a fraud/abuse complaint that A's space is being used by B. > 7. ARIN discovers that A is no longer using the space in accordance with their RSA > 8. ARIN reclaims the space and A and B are left to figure out who owes what to whom. 9. A and B ignore ARIN's email and continue to announce what they've been announcing. 10. ARIN attempts to allocate the /20 to someone else, who is not amused. Note that at this point ARIN presumably has no more v4 space left, so a threat never to allocate more space to A or B isn't very scary. Given its limited practical leverage, ARIN is only effective insofar as its members and customers agree that playing by ARIN's rules is more beneficial than ignoring them. R's, John From cscora at apnic.net Fri Aug 13 13:19:28 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 14 Aug 2010 04:19:28 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201008131819.o7DIJSYZ011641@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 14 Aug, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 327733 Prefixes after maximum aggregation: 151079 Deaggregation factor: 2.17 Unique aggregates announced to Internet: 160689 Total ASes present in the Internet Routing Table: 34560 Prefixes per ASN: 9.48 Origin-only ASes present in the Internet Routing Table: 29983 Origin ASes announcing only one prefix: 14554 Transit ASes present in the Internet Routing Table: 4577 Transit-only ASes present in the Internet Routing Table: 101 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (41664) 21 Prefixes from unregistered ASNs in the Routing Table: 860 Unregistered ASNs in the Routing Table: 433 Number of 32-bit ASNs allocated by the RIRs: 727 Prefixes from 32-bit ASNs in the Routing Table: 904 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 176 Number of addresses announced to Internet: 2288066240 Equivalent to 136 /8s, 97 /16s and 30 /24s Percentage of available address space announced: 61.7 Percentage of allocated address space announced: 65.9 Percentage of available address space allocated: 93.7 Percentage of address space in use by end-sites: 84.2 Total number of prefixes smaller than registry allocations: 155492 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 79750 Total APNIC prefixes after maximum aggregation: 27336 APNIC Deaggregation factor: 2.92 Prefixes being announced from the APNIC address blocks: 76668 Unique aggregates announced from the APNIC address blocks: 33794 APNIC Region origin ASes present in the Internet Routing Table: 4155 APNIC Prefixes per ASN: 18.45 APNIC Region origin ASes announcing only one prefix: 1159 APNIC Region transit ASes present in the Internet Routing Table: 641 Average APNIC Region AS path length visible: 3.7 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 539648800 Equivalent to 32 /8s, 42 /16s and 99 /24s Percentage of available APNIC address space announced: 76.6 APNIC AS Blocks 4608-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, 14/8, 27/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 135111 Total ARIN prefixes after maximum aggregation: 69791 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 107970 Unique aggregates announced from the ARIN address blocks: 42371 ARIN Region origin ASes present in the Internet Routing Table: 13847 ARIN Prefixes per ASN: 7.80 ARIN Region origin ASes announcing only one prefix: 5310 ARIN Region transit ASes present in the Internet Routing Table: 1364 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 731174304 Equivalent to 43 /8s, 148 /16s and 213 /24s Percentage of available ARIN address space announced: 62.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 74801 Total RIPE prefixes after maximum aggregation: 43787 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 68193 Unique aggregates announced from the RIPE address blocks: 44831 RIPE Region origin ASes present in the Internet Routing Table: 14675 RIPE Prefixes per ASN: 4.65 RIPE Region origin ASes announcing only one prefix: 7553 RIPE Region transit ASes present in the Internet Routing Table: 2201 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 24 Number of RIPE addresses announced to Internet: 434991872 Equivalent to 25 /8s, 237 /16s and 115 /24s Percentage of available RIPE address space announced: 76.3 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 29552 Total LACNIC prefixes after maximum aggregation: 7056 LACNIC Deaggregation factor: 4.19 Prefixes being announced from the LACNIC address blocks: 28053 Unique aggregates announced from the LACNIC address blocks: 14979 LACNIC Region origin ASes present in the Internet Routing Table: 1321 LACNIC Prefixes per ASN: 21.24 LACNIC Region origin ASes announcing only one prefix: 407 LACNIC Region transit ASes present in the Internet Routing Table: 235 Average LACNIC Region AS path length visible: 3.9 Max LACNIC Region AS path length visible: 20 Number of LACNIC addresses announced to Internet: 76476928 Equivalent to 4 /8s, 142 /16s and 242 /24s Percentage of available LACNIC address space announced: 57.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7368 Total AfriNIC prefixes after maximum aggregation: 1881 AfriNIC Deaggregation factor: 3.92 Prefixes being announced from the AfriNIC address blocks: 5700 Unique aggregates announced from the AfriNIC address blocks: 1657 AfriNIC Region origin ASes present in the Internet Routing Table: 392 AfriNIC Prefixes per ASN: 14.54 AfriNIC Region origin ASes announcing only one prefix: 125 AfriNIC Region transit ASes present in the Internet Routing Table: 89 Average AfriNIC Region AS path length visible: 3.7 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 19938304 Equivalent to 1 /8s, 48 /16s and 60 /24s Percentage of available AfriNIC address space announced: 59.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1862 8410 495 Korea Telecom (KIX) 4755 1481 298 164 TATA Communications formerly 7545 1376 234 87 TPG Internet Pty Ltd 17488 1343 149 127 Hathway IP Over Cable Interne 17974 1216 292 74 PT TELEKOMUNIKASI INDONESIA 24560 1005 304 181 Bharti Airtel Ltd., Telemedia 9583 1003 74 487 Sify Limited 4808 899 1671 245 CNCGROUP IP network: China169 9829 818 687 34 BSNL National Internet Backbo 4134 787 22220 415 CHINANET-BACKBONE Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3856 3684 276 bellsouth.net, inc. 4323 2730 1116 393 Time Warner Telecom 19262 1946 4613 279 Verizon Global Networks 1785 1785 698 129 PaeTec Communications, Inc. 20115 1489 1526 653 Charter Communications 7018 1478 5734 952 AT&T WorldNet Services 6478 1289 255 145 AT&T Worldnet Services 2386 1284 553 907 AT&T Data Communications Serv 22773 1176 2858 61 Cox Communications, Inc. 11492 1175 209 90 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 449 2026 390 TDC Tele Danmark 30890 443 99 211 Evolva Telecom 702 414 1870 326 UUNET - Commercial IP service 8866 403 117 18 Bulgarian Telecommunication C 8551 401 353 46 Bezeq International 3320 376 7329 325 Deutsche Telekom AG 3301 373 1415 328 TeliaNet Sweden 34984 367 89 183 BILISIM TELEKOM 12479 352 576 5 Uni2 Autonomous System 3215 322 3218 94 France Telecom Transpac Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1527 3049 247 UniNet S.A. de C.V. 10620 1091 244 150 TVCABLE BOGOTA 28573 1067 833 111 NET Servicos de Comunicao S.A 6503 811 187 264 AVANTEL, S.A. 7303 788 408 99 Telecom Argentina Stet-France 22047 550 310 15 VTR PUNTO NET S.A. 14420 547 35 75 CORPORACION NACIONAL DE TELEC 7738 477 922 30 Telecomunicacoes da Bahia S.A 3816 474 208 98 Empresa Nacional de Telecomun 11172 447 99 76 Servicios Alestra S.A de C.V Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1168 445 10 TEDATA 24863 728 147 39 LINKdotNET AS number 36992 655 279 183 Etisalat MISR 3741 270 898 232 The Internet Solution 33776 206 12 12 Starcomms Nigeria Limited 2018 197 277 64 Tertiary Education Network 6713 195 186 16 Itissalat Al-MAGHRIB 29571 192 19 11 Ci Telecom Autonomous system 24835 188 78 9 RAYA Telecom - Egypt 16637 147 440 95 MTN Network Solutions Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3856 3684 276 bellsouth.net, inc. 4323 2730 1116 393 Time Warner Telecom 19262 1946 4613 279 Verizon Global Networks 4766 1862 8410 495 Korea Telecom (KIX) 1785 1785 698 129 PaeTec Communications, Inc. 8151 1527 3049 247 UniNet S.A. de C.V. 20115 1489 1526 653 Charter Communications 4755 1481 298 164 TATA Communications formerly 7018 1478 5734 952 AT&T WorldNet Services 7545 1376 234 87 TPG Internet Pty Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2730 2337 Time Warner Telecom 19262 1946 1667 Verizon Global Networks 1785 1785 1656 PaeTec Communications, Inc. 4766 1862 1367 Korea Telecom (KIX) 4755 1481 1317 TATA Communications formerly 7545 1376 1289 TPG Internet Pty Ltd 8151 1527 1280 UniNet S.A. de C.V. 17488 1343 1216 Hathway IP Over Cable Interne 8452 1168 1158 TEDATA 6478 1289 1144 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 22015 UNALLOCATED 8.22.137.0/24 14989 Broadview Networks 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 23054 UNALLOCATED 12.18.240.0/24 7018 AT&T WorldNet Servic 33198 UNALLOCATED 12.19.149.0/24 701 UUNET Technologies, 36178 UNALLOCATED 12.20.60.0/23 6128 Cablevision Systems 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 6453 Teleglobe Inc. 41.223.196.0/24 36990 Alkan Telecom Ltd 41.223.197.0/24 36990 Alkan Telecom Ltd 41.223.198.0/24 36990 Alkan Telecom Ltd Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:21 /9:10 /10:25 /11:67 /12:198 /13:412 /14:718 /15:1304 /16:11200 /17:5397 /18:9236 /19:18562 /20:23299 /21:23290 /22:30291 /23:29761 /24:170761 /25:1058 /26:1205 /27:741 /28:117 /29:47 /30:6 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2466 3856 bellsouth.net, inc. 4766 1488 1862 Korea Telecom (KIX) 4323 1393 2730 Time Warner Telecom 1785 1252 1785 PaeTec Communications, Inc. 17488 1086 1343 Hathway IP Over Cable Interne 11492 1083 1175 Cable One 18566 1068 1087 Covad Communications 8452 1057 1168 TEDATA 10620 1005 1091 TVCABLE BOGOTA 19262 913 1946 Verizon Global Networks Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:44 2:2 4:13 8:294 12:2016 13:7 14:1 15:21 16:3 17:9 20:6 24:1442 27:294 31:1 32:61 33:22 38:695 40:97 41:2504 44:3 46:23 47:16 52:12 55:7 56:2 57:28 58:780 59:508 60:460 61:1073 62:1059 63:1972 64:3730 65:2321 66:4026 67:1838 68:1102 69:2765 70:744 71:444 72:1944 73:2 74:2303 75:253 76:326 77:890 78:620 79:433 80:1015 81:801 82:499 83:488 84:689 85:1043 86:461 87:690 88:304 89:1526 90:99 91:2959 92:412 93:1000 94:1173 95:667 96:530 97:212 98:626 99:33 108:109 109:614 110:435 111:537 112:281 113:310 114:435 115:576 116:1094 117:654 118:490 119:889 120:139 121:725 122:1531 123:953 124:1129 125:1242 128:227 129:162 130:194 131:558 132:247 133:16 134:195 135:45 136:240 137:136 138:270 139:105 140:477 141:197 142:340 143:376 144:473 145:52 146:425 147:171 148:676 149:272 150:154 151:228 152:297 153:168 154:3 155:358 156:166 157:327 158:119 159:361 160:316 161:180 162:252 163:173 164:413 165:366 166:463 167:413 168:646 169:159 170:716 171:59 172:2 173:978 174:516 175:160 176:1 177:1 178:341 180:514 181:1 182:179 183:239 184:147 186:549 187:418 188:806 189:765 190:3899 192:5755 193:4732 194:3400 195:2790 196:1181 198:3567 199:3534 200:5354 201:1588 202:8016 203:8273 204:4035 205:2403 206:2484 207:3067 208:3881 209:3470 210:2546 211:1305 212:1719 213:1675 214:659 215:69 216:4679 217:1546 218:502 219:379 220:1139 221:402 222:316 223:2 End of report From ken at sizone.org Fri Aug 13 13:31:43 2010 From: ken at sizone.org (Ken Chase) Date: Fri, 13 Aug 2010 14:31:43 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> Message-ID: <20100813183143.GV2582@sizone.org> On Fri, Aug 13, 2010 at 02:15:51PM -0400, John R. Levine said: >>>I don't entirely understand the process. Here's the flow chart as far >>>as I've figured it out: >>> >>>1. A sells a /20 of IPv4 space to B for, say, $5,000 >>> >>>2. A tells ARIN to transfer the chunk to B >>> >>>3. ARIN says no, B hasn't shown that they need it >>> >>>4. A and B say screw it, and B announces the space anyway >>> >>>5. ??? >> >>6. ARIN receives a fraud/abuse complaint that A's space is being used >>by B. >>7. ARIN discovers that A is no longer using the space in accordance >>with their RSA >>8. ARIN reclaims the space and A and B are left to figure out who owes >>what to whom. > >9. A and B ignore ARIN's email and continue to announce what they've been >announcing. > >10. ARIN attempts to allocate the /20 to someone else, who is not amused. > >Note that at this point ARIN presumably has no more v4 space left, so a >threat never to allocate more space to A or B isn't very scary. Given its >limited practical leverage, ARIN is only effective insofar as its members >and customers agree that playing by ARIN's rules is more beneficial than >ignoring them. Right, and Im answering my own question here, for (8) about the reclaiming - what upstream is going to stop carrying prefixes from a downstream that's 'illegally' announcing them? Is this upstream going to cut that customer off and lose the revenue, just to satisfy ARIN's bleating? From what I gather, all that ARIN can do is remove the NS records for the i-a.a reverse zone for the offending block, making SMTP a little trickier from the block, but not much else. Unless I didnt see the other large sticks ARIN's carrying? I've never seen them send hired goons to anyone's door... yet? /kc -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From lists at memetic.org Fri Aug 13 13:34:37 2010 From: lists at memetic.org (Adam Armstrong) Date: Fri, 13 Aug 2010 19:34:37 +0100 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: References: <201007280038.o6S0cgTd020683@aurora.sol.net> Message-ID: <4C65903D.4020804@memetic.org> On 28/07/2010 15:17, Tony Finch wrote: > On Tue, 27 Jul 2010, Joe Greco wrote: >> >> Weren't the FCC and at&t recently suggesting that VoIP was the future of >> telephony? > > BT are currently upgrading the UK's phone system to VOIP. But it's running > on a private network. Aren't BT still failing to trust the new softswitches and still planning to stick with System X until the sun goes cold? adam. From nathan at atlasnetworks.us Fri Aug 13 13:49:35 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Fri, 13 Aug 2010 18:49:35 +0000 Subject: Lightly used IP addresses In-Reply-To: <20100813183143.GV2582@sizone.org> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> Message-ID: <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> > Is this upstream going to cut that customer off and > lose the revenue, just to satisfy ARIN's bleating? Isn't this a little bit like an SSL daemon? One which refuses to process a revocation list on the basis of the function of the certificate is useless. The revocation list only has authority if the agent asks for and processes it. Would you use this SSL daemon, knowing that it had this bug? I would consider a transit provider who subverted an ARIN revocation to be disreputable, and seek other sources of transit. Best Regards, Nathan Eisenberg Atlas Networks, LLC From tme at americafree.tv Fri Aug 13 13:59:04 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 13 Aug 2010 14:59:04 -0400 Subject: Lightly used IP addresses In-Reply-To: <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> Message-ID: On Aug 13, 2010, at 2:49 PM, Nathan Eisenberg wrote: >> Is this upstream going to cut that customer off and >> lose the revenue, just to satisfy ARIN's bleating? > > Isn't this a little bit like an SSL daemon? One which refuses to process a revocation list on the basis of the function of the certificate is useless. The revocation list only has authority if the agent asks for and processes it. Would you use this SSL daemon, knowing that it had this bug? > It seems to me that most people trust certificates even if there is no certificate authority at all, revocations or no. So if "you" means "the market," I would say the answer is yes. Regards Marshall > I would consider a transit provider who subverted an ARIN revocation to be disreputable, and seek other sources of transit. > > Best Regards, > Nathan Eisenberg > Atlas Networks, LLC > > > > From nenolod at systeminplace.net Fri Aug 13 13:59:14 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 13 Aug 2010 13:59:14 -0500 Subject: Lightly used IP addresses In-Reply-To: <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> Message-ID: <1281725954.6792.21.camel@petrie.dereferenced.org> On Fri, 2010-08-13 at 18:49 +0000, Nathan Eisenberg wrote: > > Isn't this a little bit like an SSL daemon? no. > One which refuses to process a revocation list on the basis of the > function of the certificate is useless. no, it's not. ssl as a form of identity assurance itself is what is useless. > The revocation list only has authority if the agent asks for and > processes it. most don't do this, because: - most SSL daemons don't serve the revocation lists; - most SSL agents don't know how to download the revocation lists from another source. see previous note about SSL being worthless for identity assurance. > Would you use this SSL daemon, knowing that it had this bug? i wouldn't care - see above points. > I would consider a transit provider who subverted an ARIN revocation > to be disreputable, and seek other sources of transit. how do you know if the ARIN revocation is proper? with the IPv4 exhaustion becoming very close to happening now, it is possible that ARIN could "go rogue." following a corporation (yes, ARIN is a corporation) as if you were a sheep will empower them to do precisely this in the future. william From Greg.Whynott at oicr.on.ca Fri Aug 13 14:00:20 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Fri, 13 Aug 2010 15:00:20 -0400 Subject: Lightly used IP addresses In-Reply-To: <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> Message-ID: <1ACD377D-B50A-4DB6-8DA4-87B8682D0367@oicr.on.ca> > > > I would consider a transit provider who subverted an ARIN revocation to be disreputable, and seek other sources of transit. easy to say, but the reality is you may chose not to do so due to logistical, monetary or management/boss reasons which trumps your constitutionally balanced nature. If someone who was downstream from this provider in a similar situation, I'd say there is a stronger propensity for them to not 'do the right thing'. which by the way isn't a law, so who says its right? its a set of guide lines a group of folks put together. -g From jcurran at arin.net Fri Aug 13 14:09:05 2010 From: jcurran at arin.net (John Curran) Date: Fri, 13 Aug 2010 15:09:05 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> Message-ID: <40FC3A44-767A-4372-8DF0-7A7E9C8FFF6F@arin.net> On Aug 13, 2010, at 2:15 PM, John R. Levine wrote: > ... > 10. ARIN attempts to allocate the /20 to someone else, who is not amused. > > Note that at this point ARIN presumably has no more v4 space left, so a threat never to allocate more space to A or B isn't very scary. Given its limited practical leverage, ARIN is only effective insofar as its members and customers agree that playing by ARIN's rules is more beneficial than ignoring them. Thank you John for saying this... As noted, ARIN's just trying to administer the policies that the community has developed. This means that we will revoke the address space for cases of fraud, and will reissue to one of you to use. Now, if that's not the desired outcome, the policies are subject to change via the public policy process. As it is, folks need to expect that they may receive address space that was revoked as a result of such misuse, or change the policies to have ARIN do something else. /John John Curran President and CEO ARIN From ken at sizone.org Fri Aug 13 14:12:56 2010 From: ken at sizone.org (Ken Chase) Date: Fri, 13 Aug 2010 15:12:56 -0400 Subject: Lightly used IP addresses In-Reply-To: <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> Message-ID: <20100813191256.GW2582@sizone.org> On Fri, Aug 13, 2010 at 06:49:35PM +0000, Nathan Eisenberg said: >> Is this upstream going to cut that customer off and >> lose the revenue, just to satisfy ARIN's bleating? > >Isn't this a little bit like an SSL daemon? One which refuses to process a revocation list on the basis of the function of the certificate is useless. The revocation list only has authority if the agent asks for and processes it. Would you use this SSL daemon, knowing that it had this bug? > >I would consider a transit provider who subverted an ARIN revocation to be disreputable, and seek other sources of transit. Assuming the public even found out about the situation. For ARIN to make good on this community goodwill, they'd have to (1) publish the disrepute of the upstream who refuses to stop announcing the rogue downstream's prefixes. Im not sure what step 2+ is going to be there, but I bet ARIN would become very unpopular with (1) above amongst its customers reselling bandwidth to other ARIN IPv4 block users. How many large carriers on this list would immediately halt announcing a downstream-in-good-financial-standing's prefixes just because ARIN say's they're delinquent? I bet most wont even answer this question to the list here - most likely dont have an official policy for this situation, and if they did, it's likely not going to be publically disclosed. (If any are willing to disclose such publically, I'd love to hear/see the policy's details.) /kc >Best Regards, >Nathan Eisenberg >Atlas Networks, LLC -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From jcurran at arin.net Fri Aug 13 14:17:50 2010 From: jcurran at arin.net (John Curran) Date: Fri, 13 Aug 2010 15:17:50 -0400 Subject: Lightly used IP addresses In-Reply-To: <20100813183143.GV2582@sizone.org> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> Message-ID: <357F6F92-0980-4142-80C2-512CFCC892B6@arin.net> On Aug 13, 2010, at 2:31 PM, Ken Chase wrote: > ... > Right, and Im answering my own question here, for (8) about the reclaiming - > what upstream is going to stop carrying prefixes from a downstream that's > 'illegally' announcing them? Is this upstream going to cut that customer off and > lose the revenue, just to satisfy ARIN's bleating? From what I gather, all that > ARIN can do is remove the NS records for the i-a.a reverse zone for the offending > block, making SMTP a little trickier from the block, but not much else. > > Unless I didnt see the other large sticks ARIN's carrying? I've never seen them > send hired goons to anyone's door... yet? Ken - ARIN maintains the WHOIS based on what the community develops for policies; what's happens in routing tables is entirely up to the ISP community. No "bleating" or "large sticks" here, just turning the policy crank and managing address space accordingly. ARIN pulls the address space, and then (after holddown) reissues it to another provider. WHOIS reflects this change, as does in-addr. Whether an ISP respect the information in WHOIS is likely to always be a "local decision"; ARIN's responsibility is to make sure that the information contained therein matches the community's policy not some hypothetical routing enforcement. There will be an ISP attempting to make use of that reassigned address space, and one could imagine that party being let down if the community says one thing in policy but does another when it comes to routing. /John John Curran President and CEO ARIN From leslie at craigslist.org Fri Aug 13 14:19:16 2010 From: leslie at craigslist.org (Leslie) Date: Fri, 13 Aug 2010 12:19:16 -0700 Subject: Lightly used IP addresses In-Reply-To: <2D23038B-7146-4063-BA77-41DB2C1057B5@oicr.on.ca> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <2D23038B-7146-4063-BA77-41DB2C1057B5@oicr.on.ca> Message-ID: <4C659AB4.6030401@craigslist.org> I've tried to deal with that a few times - mainly by writing up the first upstream AS. Usually they don't care (and every time I have noticed someone blatantly stealing space, it's been spammers). Good filtering at the transit provider border IMNSHO is the best way to solve this problem. Leslie On 8/13/10 10:59 AM, Greg Whynott wrote: > how does ARIN or whomever deal with similar situations where someone is advertising un-allocated, un-assigned by ARIN IP space in NA? do they have a deal/agreement with the 'backbone' providers? > > -g > > > >>> >> >> 6. ARIN receives a fraud/abuse complaint that A's space is being used by B. >> 7. ARIN discovers that A is no longer using the space in accordance with their RSA >> 8. ARIN reclaims the space and A and B are left to figure out who owes what to whom. >> >> > From ken at sizone.org Fri Aug 13 14:24:45 2010 From: ken at sizone.org (Ken Chase) Date: Fri, 13 Aug 2010 15:24:45 -0400 Subject: Lightly used IP addresses In-Reply-To: <357F6F92-0980-4142-80C2-512CFCC892B6@arin.net> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <357F6F92-0980-4142-80C2-512CFCC892B6@arin.net> Message-ID: <20100813192445.GY2582@sizone.org> On Fri, Aug 13, 2010 at 03:17:50PM -0400, John Curran said: >Ken - > > ARIN maintains the WHOIS based on what the community develops for > policies; what's happens in routing tables is entirely up to the > ISP community. No "bleating" or "large sticks" here, just turning > the policy crank and managing address space accordingly. > > ARIN pulls the address space, and then (after holddown) reissues it > to another provider. WHOIS reflects this change, as does in-addr. > Whether an ISP respect the information in WHOIS is likely to always > be a "local decision"; ARIN's responsibility is to make sure that > the information contained therein matches the community's policy > not some hypothetical routing enforcement. > > There will be an ISP attempting to make use of that reassigned > address space, and one could imagine that party being let down > if the community says one thing in policy but does another when > it comes to routing. > >/John > >John Curran >President and CEO >ARIN Thanks John - I realise this. I was merely putting on the hat of those who may try to bend the policies to their advantage through delinquent activity. The common good is at stake here, and I'd rather that ARIN did have some collective 'stick' to effectively apply itself or via its members. I too don't want to deal with announcements for the same prefix from multiple warring AS's or other side effects of the IPv4 crunch. I'm indicating (the probably obvious) that these pressures will certainly increase over time, and as one other member pointed out, the sticks may become neccessary - and the community will have to become more 'constitutionally ethical' in their handling of delinquents on ARIN's/the commmunity's behalf. Not sure what incentives are in play to encourage this, as it will become necessary in a shorter time than we may think. Thanks for your reply and clarifications. /kc -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From nathan at atlasnetworks.us Fri Aug 13 14:25:56 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Fri, 13 Aug 2010 19:25:56 +0000 Subject: Lightly used IP addresses In-Reply-To: <1ACD377D-B50A-4DB6-8DA4-87B8682D0367@oicr.on.ca> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> <1ACD377D-B50A-4DB6-8DA4-87B8682D0367@oicr.on.ca> Message-ID: <8C26A4FDAE599041A13EB499117D3C281647E400@ex-mb-1.corp.atlasnetworks.us> > If someone who was downstream from this provider in a similar situation, I'd > say there is a stronger propensity for them to not 'do the right thing'. which by > the way isn't a law, so who says its right? its a set of guide lines a group of > folks put together. But the reality is that you asserted your intention to follow those guidelines when you requested the allocation, did you not? If an upstream accepts announcements from a revoked block, what is to stop them from accepting announcements for an unallocated block? I realize this precariously borders on committing a slippery slope fallacy, but I think it's a valid question to ask - a provider is either 'in compliance' with the guidelines, or 'not in compliance' with them. Once you're 'not in compliance' a little bit, how can I have a valid trust relationship with you about the rest of it? > see previous note about SSL being worthless for identity assurance. Fair enough - serves me right for invoking analogy. > following a corporation (yes, ARIN is a corporation) as if you were a sheep will > empower them to do precisely this in the future. There's no sheepism here. The proposed situation represents a valid reason for revoking address space under the community developed guidelines. I don't see the problem with following those guidelines, do you? > How many large carriers on this list would immediately halt announcing a > downstream-in-good-financial-standing's prefixes just because ARIN say's > they're delinquent? That depends. I vote with my wallet. How many carriers want my business, and the business of other customers who (reasonably) expect compliance with the standing policies? Do you want to do business with someone who's willing to break the rules everyone else is playing by? Best Regards, Nathan Eisenberg Atlas Networks, LLC From jcurran at arin.net Fri Aug 13 14:43:11 2010 From: jcurran at arin.net (John Curran) Date: Fri, 13 Aug 2010 15:43:11 -0400 Subject: Lightly used IP addresses In-Reply-To: <20100813175554.GB7558@vacation.karoshi.com> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> Message-ID: <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> On Aug 13, 2010, at 1:55 PM, bmanning at vacation.karoshi.com wrote: > could you provide 4 numbers for me please? > > % of ARIN managed resource covered by standard RSA? > % of ARIN managed legacy resource covered by legacy RSA? > % of ARIN managed legacy resource not otherwise covered? > % of ARIN region entities (A & B above) that have offices/relationships > with other RIRs that have a divergent transfer process in place? Bill - We'll work on generating these numbers to the extent possible for the upcoming meeting; back in April, I noted that we had about 21% of the legacy space (by total IP address count) under an LRSA (6%) or RSA (15%). For now, this is first order estimate for your second and third questions. These numbers keep going up, so we'll need some work to generate current ones for the next meeting. Regarding the last one, that's very difficult to obtain; how do you see it impacting the overall outcome? /John John Curran President and CEO ARIN From sethm at rollernet.us Fri Aug 13 14:53:10 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 13 Aug 2010 12:53:10 -0700 Subject: Lightly used IP addresses In-Reply-To: References: <30FA2C29-F91B-4C2F-AD08-8EF49957C66A@seastrom.com> <20100813173652.84198.qmail@joyce.lan> Message-ID: <4C65A2A6.6050409@rollernet.us> On 8/13/10 10:42 AM, Brandon Galbraith wrote: > Alternate #4: A "rents" the space to B without ARIN knowing it, while A > continues to claim that the space belongs to them. > This already happens as we speak with "IP brokers". ~Seth From ken at sizone.org Fri Aug 13 14:54:26 2010 From: ken at sizone.org (Ken Chase) Date: Fri, 13 Aug 2010 15:54:26 -0400 Subject: Lightly used IP addresses In-Reply-To: <8C26A4FDAE599041A13EB499117D3C281647E400@ex-mb-1.corp.atlasnetworks.us> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> <1ACD377D-B50A-4DB6-8DA4-87B8682D0367@oicr.on.ca> <8C26A4FDAE599041A13EB499117D3C281647E400@ex-mb-1.corp.atlasnetworks.us> Message-ID: <20100813195426.GA2582@sizone.org> On Fri, Aug 13, 2010 at 07:25:56PM +0000, Nathan Eisenberg said: >But the reality is that you asserted your intention to follow those guidelines when you requested the allocation, did you not? >If an upstream accepts announcements from a revoked block, what is to stop them from accepting announcements for an unallocated block? I realize this precariously borders on committing a slippery slope fallacy, but I think it's a valid question to ask - a provider is either 'in compliance' with the guidelines, or 'not in compliance' with them. Once you're 'not in compliance' a little bit, how can I have a valid trust relationship with you about the rest of it? There's a difference - once the upstream is hooked on the revenue stream they're not going to want to interfere with it. They might pass along some threats from ARIN and/or levy their own, but I doubt they'd seriously make good on it and cut their own hand off and lose the revenue. That's for a deallocated block that was in good standing originally - this assumes the contract for transit with the upstream included someone there ensuring that the block was properly/legally allocated, and WHOIS/RADB/Swip/yadda and everything else was properly notated and setup. Going from good standing with a revenue stream for some months/years to bad is different from accepting a bogon customer at the very start of the arrangement. Lots of things would not lineup with a minimum of due dilligence, and I suspect that most providers with any ethical slant will refuse to provide service (scenario screams 'SPAMMER!' for one). That's alot different from shutting off a revenue stream that was working well (sans spam) for a year or more prior. >> following a corporation (yes, ARIN is a corporation) as if you were a sheep will >> empower them to do precisely this in the future. > >There's no sheepism here. The proposed situation represents a valid reason for revoking address space under the community developed guidelines. I don't see the problem with following those guidelines, do you? The reality is that following the guidelines is psychologically difficult in harder times as we're experiencing now. Without any real repercussions for the upstream for NOT cutting off the customer, balanced against the existing revenue stream from the delinquent (assuming they're not delinquent with their transit provider as well), it's not a hard calculation. I dont see much 'community' fallout occurring either, or we'd see it on this list. A few transit providers have very poor reputations in the community (y'all know who they are), and personally I won't purchase from them, but certainly none of them have garnered this reputation by not cutting off ARIN delinquents. It's just not publically available data - I dont think ARIN publishes this as I said, and if they did I suspect it'd be a pretty busy-yet-boring mailing list (with alot of screaming and name calling if it was open to public posting :). >> How many large carriers on this list would immediately halt announcing a >> downstream-in-good-financial-standing's prefixes just because ARIN say's >> they're delinquent? >That depends. I vote with my wallet. How many carriers want my business, and the business of other customers who (reasonably) expect compliance with the standing policies? Do you want to do business with someone who's willing to break the rules everyone else is playing by? IS everyone else playing by them? We dont really have data as I mentioned, or I don't at least, so if anyone can provide stats (ARIN? some bulk numbers without naming any names?) that'd be helpful in shaping this dicussion by identifying how large the issue really is. Number of requests to upstreams to halt announcements, and a mean and stddev on days-til-compliance for that action (or how many delinquents were succesfully scared into paying ARIN by an upstream's sternly worded warning would also be interesting). Unfortunately such stats would also be good hard data for gamblers to model the risk/reward profile on continuing to not pay. :) Shades of freakonomics game theory here... >Best Regards, >Nathan Eisenberg >Atlas Networks, LLC /kc -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From Valdis.Kletnieks at vt.edu Fri Aug 13 15:03:56 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 13 Aug 2010 16:03:56 -0400 Subject: Lightly used IP addresses In-Reply-To: Your message of "Fri, 13 Aug 2010 15:24:45 EDT." <20100813192445.GY2582@sizone.org> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <357F6F92-0980-4142-80C2-512CFCC892B6@arin.net> <20100813192445.GY2582@sizone.org> Message-ID: <78735.1281729836@localhost> On Fri, 13 Aug 2010 15:24:45 EDT, Ken Chase said: > I'm indicating (the probably obvious) that these pressures will certainly > increase over time, and as one other member pointed out, the sticks may become > neccessary - and the community will have to become more 'constitutionally > ethical' in their handling of delinquents on ARIN's/the commmunity's behalf. How long did it take to cut Intercage off for *lots* worse things? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bill at herrin.us Fri Aug 13 15:05:45 2010 From: bill at herrin.us (William Herrin) Date: Fri, 13 Aug 2010 16:05:45 -0400 Subject: Lightly used IP addresses In-Reply-To: <20100813173652.84198.qmail@joyce.lan> References: <30FA2C29-F91B-4C2F-AD08-8EF49957C66A@seastrom.com> <20100813173652.84198.qmail@joyce.lan> Message-ID: On Fri, Aug 13, 2010 at 1:36 PM, John Levine wrote: >>http://www.circleid.com/posts/psst_interested_in_some_lightly_used_ip_addresses/ > > I don't entirely understand the process. ?Here's the flow chart as far > as I've figured it out: > > 1. ?A sells a /20 of IPv4 space to B for, say, $5,000 > 2. ?A tells ARIN to transfer the chunk to B > 3. ?ARIN says no, B hasn't shown that they need it > 4. ?A and B say screw it, and B announces the space anyway 1. B applies for a block of IPv4 addresses from ARIN. 2. ARIN says: "You qualify for a /20. You have been added to the waiting list. You may also receive a transfer." 3. B finds A offering to sell a /20 on ebay or wherever. 4. A sells a /20 of IPv4 space to B for, say, $5,000 5. A tells ARIN to transfer the chunk to B 6. ARIN tells B: "A has authorized the transfer of x.y.z.0/20 to you. You previously qualified for a /20. Pay your registration fee at http://website to complete the transfer." 7. You pay. The /20 is transferred. It remains to be seen if / how well this works. But that's the basic plan. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bmanning at vacation.karoshi.com Fri Aug 13 15:06:58 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 13 Aug 2010 20:06:58 +0000 Subject: Lightly used IP addresses In-Reply-To: <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> Message-ID: <20100813200658.GC8181@vacation.karoshi.com.> On Fri, Aug 13, 2010 at 03:43:11PM -0400, John Curran wrote: > On Aug 13, 2010, at 1:55 PM, bmanning at vacation.karoshi.com wrote: > > could you provide 4 numbers for me please? > > > > % of ARIN managed resource covered by standard RSA? > > % of ARIN managed legacy resource covered by legacy RSA? > > % of ARIN managed legacy resource not otherwise covered? > > % of ARIN region entities (A & B above) that have offices/relationships > > with other RIRs that have a divergent transfer process in place? > > Bill - > > We'll work on generating these numbers to the extent > possible for the upcoming meeting; back in April, I noted > that we had about 21% of the legacy space (by total IP > address count) under an LRSA (6%) or RSA (15%). For now, > this is first order estimate for your second and third > questions. These numbers keep going up, so we'll need > some work to generate current ones for the next meeting. > Regarding the last one, that's very difficult to obtain; > how do you see it impacting the overall outcome? > > /John these questions were asked in response to Owens views on the ARIN reclaimation process in the case of documented transfers outside the existing ARIN processes. my assertion to Owen was that his views would apply directly to the folks under a standard RSA. My reading of the LRSA suggests that ARIN has a much narrower remit on recovery of resources covered by that document. the third camp was/is a much thornier patch of ground, fraught w/ peril if ARIN takes action on recovery, at least imho. #4, well that sounds like fruitful ground for inter-RIR coordination. for example, if 75% of the total resource under ARIN administration is legacy, then 25% is covered by the standard RSA. Within the 75%, 6% of it is under LRSA and 15% of it is under the standard RSA. if this characterization is in ballpark, then Owens view on reclaimation only holds for ~30% of the resource under ARIN administration. Correct? --bill From randy at psg.com Fri Aug 13 15:18:49 2010 From: randy at psg.com (Randy Bush) Date: Sat, 14 Aug 2010 05:18:49 +0900 Subject: Lightly used IP addresses In-Reply-To: <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> Message-ID: >> % of ARIN managed resource covered by standard RSA? >> % of ARIN managed legacy resource covered by legacy RSA? >> % of ARIN managed legacy resource not otherwise covered? >> % of ARIN region entities (A & B above) that have offices/relationships >> with other RIRs that have a divergent transfer process in place? > We'll work on generating these numbers to the extent > possible for the upcoming meeting; back in April, I noted > that we had about 21% of the legacy space (by total IP > address count) under an LRSA (6%) or RSA (15%). For now, > this is first order estimate for your second and third > questions. % of space and % of holders, please randy From avg at kotovnik.com Fri Aug 13 15:25:57 2010 From: avg at kotovnik.com (Vadim Antonov) Date: Fri, 13 Aug 2010 13:25:57 -0700 Subject: Lightly used IP addresses Message-ID: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> "Those who do not understand market are doomed to reimplementing it, badly". How come ARIN has any say at all if A wants to sell and B wants to buy? Trying to fend off the imaginary monopolistic hobgoblin? Or simply killing the incentive to actually do something about conservation and, yes, reingeneering the network to fix the address space shortage and prefix explosion? From randy at psg.com Fri Aug 13 15:35:00 2010 From: randy at psg.com (Randy Bush) Date: Sat, 14 Aug 2010 05:35:00 +0900 Subject: Lightly used IP addresses In-Reply-To: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> Message-ID: > How come ARIN has any say at all if A wants to sell and B wants to > buy? Trying to fend off the imaginary monopolistic hobgoblin? self-justification for arin's existence, flying people around to lotso meetings, fancy hotels, ... at the rirs, income and control are more important than the health and growth of the internet. basically, the rirs are another case of seemed like a good idea at the time. randy From jcurran at arin.net Fri Aug 13 15:35:31 2010 From: jcurran at arin.net (John Curran) Date: Fri, 13 Aug 2010 16:35:31 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> Message-ID: On Aug 13, 2010, at 4:18 PM, Randy Bush wrote: >> We'll work on generating these numbers to the extent >> possible for the upcoming meeting; back in April, I noted >> that we had about 21% of the legacy space (by total IP >> address count) under an LRSA (6%) or RSA (15%). For now, >> this is first order estimate for your second and third >> questions. > > % of space and % of holders, please I gave % of space in the April numbers above (the number of holders at that time was approximately 700 of estimated 18000) /John John Curran President and CEO ARIN From randy at psg.com Fri Aug 13 15:37:49 2010 From: randy at psg.com (Randy Bush) Date: Sat, 14 Aug 2010 05:37:49 +0900 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> Message-ID: >>> We'll work on generating these numbers to the extent >>> possible for the upcoming meeting; back in April, I noted >>> that we had about 21% of the legacy space (by total IP >>> address count) under an LRSA (6%) or RSA (15%). For now, >>> this is first order estimate for your second and third >>> questions. >> >> % of space and % of holders, please > > I gave % of space in the April numbers above i am literate, even at this hour > the number of holders at that time was approximately 700 of estimated > 18000 thanks. but i meant when you report at meeting, on web site, whatever. please report both, not just the one with the larger number. randy From jcurran at arin.net Fri Aug 13 15:41:53 2010 From: jcurran at arin.net (John Curran) Date: Fri, 13 Aug 2010 16:41:53 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> Message-ID: <31ED2902-4D70-48C8-ADF0-D325877DF09D@arin.net> On Aug 13, 2010, at 4:37 PM, Randy Bush wrote: > thanks. but i meant when you report at meeting, on web site, whatever. > please report both, not just the one with the larger number. Yes, will do. /John From randy at psg.com Fri Aug 13 15:42:49 2010 From: randy at psg.com (Randy Bush) Date: Sat, 14 Aug 2010 05:42:49 +0900 Subject: Lightly used IP addresses In-Reply-To: <31ED2902-4D70-48C8-ADF0-D325877DF09D@arin.net> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> <31ED2902-4D70-48C8-ADF0-D325877DF09D@arin.net> Message-ID: >> thanks. but i meant when you report at meeting, on web site, whatever. >> please report both, not just the one with the larger number. > Yes, will do. thanks randy From jcurran at arin.net Fri Aug 13 15:47:21 2010 From: jcurran at arin.net (John Curran) Date: Fri, 13 Aug 2010 16:47:21 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> Message-ID: <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> On Aug 13, 2010, at 4:35 PM, Randy Bush wrote: > >> How come ARIN has any say at all if A wants to sell and B wants to >> buy? Trying to fend off the imaginary monopolistic hobgoblin? > > self-justification for arin's existence, flying people around to lotso > meetings, fancy hotels, ... > > at the rirs, income and control are more important than the health and > growth of the internet. basically, the rirs are another case of seemed > like a good idea at the time. Vadim - We'll run the database anyway you (collectively) want us to... what policy would you prefer, and can you submit it as a proposal? (and to answer Randy - the only control over the administration is based on the policies adopted. Reduce the corpus of applicable policy if that is your desire.) /John John Curran President and CEO ARIN From randy at psg.com Fri Aug 13 15:52:08 2010 From: randy at psg.com (Randy Bush) Date: Sat, 14 Aug 2010 05:52:08 +0900 Subject: Lightly used IP addresses In-Reply-To: <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> Message-ID: > (and to answer Randy - the only control over the administration is based > on the policies adopted. Reduce the corpus of applicable policy if that > is your desire.) we created careers for junior policiy weenies. arin and other rirs have become well-funded playgrounds for the semi-clued who think they can and should tell others how to run their businesses, operate the internet, .. tough to put that crap back in the bottle. makes one think that the itu may not actually be worse. randy From jared at puck.nether.net Fri Aug 13 16:00:04 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 13 Aug 2010 17:00:04 -0400 Subject: Lightly used IP addresses In-Reply-To: <1ACD377D-B50A-4DB6-8DA4-87B8682D0367@oicr.on.ca> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> <1ACD377D-B50A-4DB6-8DA4-87B8682D0367@oicr.on.ca> Message-ID: <1A72F43E-CAC8-4B3A-841D-ADA399FCAF98@puck.nether.net> I know of several large providers that would stop routing such "rogue" space. Any provider that isn't prepared to deal with such a possible customer threat or problem you don't want to be associating with. They likely harbor other badness as well. It may take some time to catch up to them but we have seen more of these rogue elements end up with people refusing to sell to them or law enforcement taking some action. If your management does not realize they are buying from possible criminals, you get what you pay for. I've found a number of cases where providers are actually doing mitm and stealing SIP credentials for fraud. Make sure you actually have good controls and communication for when things hit the fan.... Jared Mauch On Aug 13, 2010, at 3:00 PM, Greg Whynott wrote: >> >> >> I would consider a transit provider who subverted an ARIN revocation to be disreputable, and seek other sources of transit. > > easy to say, but the reality is you may chose not to do so due to logistical, monetary or management/boss reasons which trumps your constitutionally balanced nature. > > If someone who was downstream from this provider in a similar situation, I'd say there is a stronger propensity for them to not 'do the right thing'. which by the way isn't a law, so who says its right? its a set of guide lines a group of folks put together. > > > -g > > > From johnl at iecc.com Fri Aug 13 16:04:00 2010 From: johnl at iecc.com (John Levine) Date: 13 Aug 2010 21:04:00 -0000 Subject: Lightly used IP addresses In-Reply-To: <4C659AB4.6030401@craigslist.org> Message-ID: <20100813210400.34663.qmail@joyce.lan> >I've tried to deal with that a few times - mainly by writing up the >first upstream AS. Usually they don't care (and every time I have >noticed someone blatantly stealing space, it's been spammers). Has there ever been a case where ARIN has tried to take a block back from a party to whom they had allocated it and doesn't want to give it back? My impression is that stolen space is all swamp or legacy or abandoned, but I really don't know. In case it's not obvious, I'm not advocating that people thumb their noses at ARIN, but I don't see any obvious way to avoid my scenario. R's, John From dwhite at olp.net Fri Aug 13 16:18:01 2010 From: dwhite at olp.net (Dan White) Date: Fri, 13 Aug 2010 16:18:01 -0500 Subject: Lightly used IP addresses In-Reply-To: <20100813210400.34663.qmail@joyce.lan> References: <4C659AB4.6030401@craigslist.org> <20100813210400.34663.qmail@joyce.lan> Message-ID: <20100813211800.GL2669@dan.olp.net> On 13/08/10?21:04?-0000, John Levine wrote: >>I've tried to deal with that a few times - mainly by writing up the >>first upstream AS. Usually they don't care (and every time I have >>noticed someone blatantly stealing space, it's been spammers). > >Has there ever been a case where ARIN has tried to take a block back >from a party to whom they had allocated it and doesn't want to give it >back? My impression is that stolen space is all swamp or legacy or >abandoned, but I really don't know. > >In case it's not obvious, I'm not advocating that people thumb their >noses at ARIN, but I don't see any obvious way to avoid my scenario. Make a public example of the situation. Assign such a block to an ARIN member with extensive legal resources who's willing to send some nasty letters out, and back it up with court action to establish legal precedence. Or ARIN could do so itself on the grounds of breach of contract. Of course, said block should clearly fall within ARIN's domain, backed up with a signed contract from the original party. -- Dan White From jcurran at arin.net Fri Aug 13 16:19:20 2010 From: jcurran at arin.net (John Curran) Date: Fri, 13 Aug 2010 17:19:20 -0400 Subject: Lightly used IP addresses In-Reply-To: <20100813200658.GC8181@vacation.karoshi.com.> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> <20100813200658.GC8181@vacation.karoshi.com.> Message-ID: <024484A8-FE17-4B2D-B059-5AAD4F4DC61B@arin.net> On Aug 13, 2010, at 4:06 PM, wrote: > > my assertion to Owen was that his views would apply directly > to the folks under a standard RSA. My reading of the > LRSA suggests that ARIN has a much narrower remit on recovery > of resources covered by that document. the third camp was/is > a much thornier patch of ground, fraught w/ peril if ARIN > takes action on recovery, at least imho. #4, well that sounds > like fruitful ground for inter-RIR coordination. > > for example, if 75% of the total resource under ARIN administration > is legacy, then 25% is covered by the standard RSA. Within the 75%, > 6% of it is under LRSA and 15% of it is under the standard RSA. > > if this characterization is in ballpark, then Owens view on > reclaimation only holds for ~30% of the resource under ARIN administration. The LRSA provides specific rights which could very likely preclude reclamation in some circumstances and result in the resources then remaining as-is with address holder, i.e., this would still prevent transfer contrary to the community policy but also prevent reissue. (this occurs in the LRSA under some circumstances recognizing the history of the legacy address space with the community). Okay, to try and get some numbers back into the thread: From Leslie's Registration Services report in Toronto, pages 6 and 9: First, I note that the 700 number I used from memory for number of organizations was not correct; I gave the total signed, approved, and pending. The number 444 signed is what corresponds to the 6% under LRSA. Nicely, the actual numbers are in the report, so we see 6.49 /8 equivalents space under LRSA, out of the total legacy space of 73 /8 equivalents (page 9). The RSA space is 33 /8 equivalents, and total inventory is 106 /8 equivalents. (Randy, does this level of reporting suffice for your purposes?) So, recasting final numbers back to the original context: 63% (66.5/106) of the address space managed by ARIN is Legacy-not-under-agreement, and ARIN's action with this space is governed by the policies adopted by the community. ARIN clearly could be in a difficult situation if policies adopted needlessly result in impact to these legacy address holders. 6% (6.5/106) of the address space managed by ARIN is Legacy-under-LRSA, and has specific contractual language which may take precedence over community adopted policy (and could both prevent transfers from completing and reclamation from occurring). 31% (33/106) of the address space managed by ARIN is per-RSA, and ARIN's action with this space is clearly governed by the policies adopted by the community. /John John Curran President and CEO ARIN From jcurran at arin.net Fri Aug 13 16:24:46 2010 From: jcurran at arin.net (John Curran) Date: Fri, 13 Aug 2010 17:24:46 -0400 Subject: Lightly used IP addresses In-Reply-To: <20100813211800.GL2669@dan.olp.net> References: <4C659AB4.6030401@craigslist.org> <20100813210400.34663.qmail@joyce.lan> <20100813211800.GL2669@dan.olp.net> Message-ID: <7E1697C4-5732-4DB6-82E0-99AEFDD9AE60@arin.net> On Aug 13, 2010, at 5:18 PM, Dan White wrote: > On 13/08/10 21:04 -0000, John Levine wrote: >>> I've tried to deal with that a few times - mainly by writing up the >>> first upstream AS. Usually they don't care (and every time I have >>> noticed someone blatantly stealing space, it's been spammers). >> >> Has there ever been a case where ARIN has tried to take a block back >> from a party to whom they had allocated it and doesn't want to give it >> back? My impression is that stolen space is all swamp or legacy or >> abandoned, but I really don't know. >> >> In case it's not obvious, I'm not advocating that people thumb their >> noses at ARIN, but I don't see any obvious way to avoid my scenario. > > Make a public example of the situation. Assign such a block to an ARIN > member with extensive legal resources who's willing to send some nasty > letters out, and back it up with court action to establish legal > precedence. > > Or ARIN could do so itself on the grounds of breach of contract. > > Of course, said block should clearly fall within ARIN's domain, backed up > with a signed contract from the original party. Yes, we have returns, revocations, and reclamations occurring routinely. They're covered in the same Toronto Registration services report that I referenced earlier on page 5. /John John Curran President and CEO ARIN From ken at sizone.org Fri Aug 13 16:25:44 2010 From: ken at sizone.org (Ken Chase) Date: Fri, 13 Aug 2010 17:25:44 -0400 Subject: Lightly used IP addresses In-Reply-To: <1A72F43E-CAC8-4B3A-841D-ADA399FCAF98@puck.nether.net> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> <1ACD377D-B50A-4DB6-8DA4-87B8682D0367@oicr.on.ca> <1A72F43E-CAC8-4B3A-841D-ADA399FCAF98@puck.nether.net> Message-ID: <20100813212544.GJ2582@sizone.org> On Fri, Aug 13, 2010 at 05:00:04PM -0400, Jared Mauch said: >I know of several large providers that would stop routing such "rogue" space. Really? They'd take a seriously delinquent (and we're only talking about non payment after several months to Arin, not spammers or other 'criminal' elements) that's still paying for their transit and cut off their prefix announcements? I dont know that that's true for most outfits in these tough times. Nixing a $5000 or $10000+ MRC revenue stream probably requires some hard thought at high levels in most outfits. >Any provider that isn't prepared to deal with such a possible customer threat or problem you don't want to be associating with. They likely harbor other badness as well. Possibly, but this isnt that much of a gateway drug. I know lots of companies in a financial crunch right now, and if losing the i-a.a reverse is the only effect of being late on a payment 'til the sun starts shining again' when their own customers start making good on old invoices, then I think many others would choose to delay paying ARIN instead. When things get tough, payables are readily triaged into high and low priority. Perhaps NOC peeps on this list arent exposed to such decisions made in other departments - we run a small operation here so we're all part of such things. Some harsh realities in business sometimes! In many cases I suspect ARIN ends up as low priority, without any criminal mindset in operation putting them there - some of these operators might even be altruistically thinking of their employees too - we know how fast service goes stale in a multi-day outtage - losing connectivity may mean employees are soon not paid and literally go hungry. So most outfits will pay their upstreams before ARIN - and they can keep their revenue streams going and pay their employees - and in the long run, one day maybe pay ARIN too. Who disagrees? Go from that example to paying for power/colo, phone, etc and tell me where ARIN is on your triage list during a cashflow event. >It may take some time to catch up to them but we have seen more of these rogue elements end up with people refusing to sell to them or law enforcement taking some action. I know of a few such entities that are semi-chronically late in paying ARIN, but they still havent taken on spammers or Chinese intelligence operations/cyberwar plaforms as customers yet, despite your broken broken window/gateway drug analogy. It aint all black and white, there's lots of gray out there, and organizations that are forced into unfortunate circumstance through current economics, possibly mismanagement and cluelessness too, but without any malice at work. >If your management does not realize they are buying from possible criminals, you get what you pay for. If the criminals all wore t shirts that said they're part of the club that'd be easy. When a company is having a cashflow issues, I'd say they're just in a very big club. If they manage to pay me, I dont ask any questions about the ethics of their triaging of other payables. >I've found a number of cases where providers are actually doing mitm and stealing SIP credentials for fraud. Make sure you actually have good controls and communication for when things hit the fan.... Examples of shitty fans, and controls? just want a better idea of what you're referring to. /kc -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From ken at sizone.org Fri Aug 13 16:29:26 2010 From: ken at sizone.org (Ken Chase) Date: Fri, 13 Aug 2010 17:29:26 -0400 Subject: Lightly used IP addresses In-Reply-To: <20100813211800.GL2669@dan.olp.net> References: <4C659AB4.6030401@craigslist.org> <20100813210400.34663.qmail@joyce.lan> <20100813211800.GL2669@dan.olp.net> Message-ID: <20100813212926.GK2582@sizone.org> On Fri, Aug 13, 2010 at 04:18:01PM -0500, Dan White said: >Make a public example of the situation. Assign such a block to an ARIN >member with extensive legal resources who's willing to send some nasty >letters out, and back it up with court action to establish legal >precedence. > >Or ARIN could do so itself on the grounds of breach of contract. > >Of course, said block should clearly fall within ARIN's domain, backed up >with a signed contract from the original party. Many of these outfits already have cashflow issue - suing them into the ground when they're already underwater is probably a cash-losing situation for ARIN. And I bet other orgs who are in good financial standing dont want to fund a suit against a judgement-proof org and lose money pushing lawyers around just for fun - not until IPs are worth $10+/IP/month at least, anyway. Then the lawsuits might be worth the investment. Pretty awesome: I see a new industry forming: IP REPO MEN. (Dont know if we can cast Emilio Estevez in th movie version, he's a bit too old now...) /kc -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From bmanning at vacation.karoshi.com Fri Aug 13 16:39:42 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 13 Aug 2010 21:39:42 +0000 Subject: Lightly used IP addresses In-Reply-To: <024484A8-FE17-4B2D-B059-5AAD4F4DC61B@arin.net> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> <20100813200658.GC8181@vacation.karoshi.com.> <024484A8-FE17-4B2D-B059-5AAD4F4DC61B@arin.net> Message-ID: <20100813213942.GD8181@vacation.karoshi.com.> On Fri, Aug 13, 2010 at 05:19:20PM -0400, John Curran wrote: > > > > if this characterization is in ballpark, then Owens view on > > reclaimation only holds for ~30% of the resource under ARIN administration. > > > 31% (33/106) of the address space managed by ARIN is per-RSA, > and ARIN's action with this space is clearly governed by the > policies adopted by the community. > > /John > Thanks for this John. My hope is that folks will try and avoid using the courts as the arbitor in the event of dispute over right to use. --bill From Greg.Whynott at oicr.on.ca Fri Aug 13 16:40:10 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Fri, 13 Aug 2010 17:40:10 -0400 Subject: Lightly used IP addresses In-Reply-To: <1A72F43E-CAC8-4B3A-841D-ADA399FCAF98@puck.nether.net> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> <1ACD377D-B50A-4DB6-8DA4-87B8682D0367@oicr.on.ca>, <1A72F43E-CAC8-4B3A-841D-ADA399FCAF98@puck.nether.net> Message-ID: I agree with you. the context around my statement is if the downstream believed or has some validity to a claim that they are being unjustly treated or over sighted by ARIN (or others). it wasn't about procuring blocks from a criminal, rather when ARIN says you are no longer entitled to the blocks they assigned the downstream customer, who believes they are. I'm not against ARIN, I think they have good intentions. I'd like to think so anyway. take care and have a great weekend, greg ________________________________________ From: Jared Mauch [jared at puck.nether.net] Sent: Friday, August 13, 2010 5:00 PM To: Greg Whynott Cc: Nathan Eisenberg; nanog at nanog.org Subject: Re: Lightly used IP addresses I know of several large providers that would stop routing such "rogue" space. Any provider that isn't prepared to deal with such a possible customer threat or problem you don't want to be associating with. They likely harbor other badness as well. It may take some time to catch up to them but we have seen more of these rogue elements end up with people refusing to sell to them or law enforcement taking some action. If your management does not realize they are buying from possible criminals, you get what you pay for. I've found a number of cases where providers are actually doing mitm and stealing SIP credentials for fraud. Make sure you actually have good controls and communication for when things hit the fan.... Jared Mauch On Aug 13, 2010, at 3:00 PM, Greg Whynott wrote: >> >> >> I would consider a transit provider who subverted an ARIN revocation to be disreputable, and seek other sources of transit. > > easy to say, but the reality is you may chose not to do so due to logistical, monetary or management/boss reasons which trumps your constitutionally balanced nature. > > If someone who was downstream from this provider in a similar situation, I'd say there is a stronger propensity for them to not 'do the right thing'. which by the way isn't a law, so who says its right? its a set of guide lines a group of folks put together. > > > -g > > > From randy at psg.com Fri Aug 13 16:46:10 2010 From: randy at psg.com (Randy Bush) Date: Sat, 14 Aug 2010 06:46:10 +0900 Subject: Lightly used IP addresses In-Reply-To: <024484A8-FE17-4B2D-B059-5AAD4F4DC61B@arin.net> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> Message-ID: to make it easiest to understand, i might grind it up into /24 equivalents and present as percentages Type % of all space % of type space % of total holders % of type holders RSA 31% no-RSA LRSA 6% no-LRSA ... From nathan at atlasnetworks.us Fri Aug 13 16:51:51 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Fri, 13 Aug 2010 21:51:51 +0000 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> <1ACD377D-B50A-4DB6-8DA4-87B8682D0367@oicr.on.ca>, <1A72F43E-CAC8-4B3A-841D-ADA399FCAF98@puck.nether.net> Message-ID: <8C26A4FDAE599041A13EB499117D3C281647E679@ex-mb-1.corp.atlasnetworks.us> > I'm not against ARIN, I think they have good intentions. I'd like to think so > anyway. Same here. I'm honestly surprised that there is as much dissention from this attitude as there seems to be... > Yes, we have returns, revocations, and reclamations occurring routinely. > They're covered in the same Toronto Registration services report that I > referenced earlier on page 5. > y/Nobile_RSD.pdf> John, thank you for the links. Interesting information there! Best Regards, Nathan Eisenberg Atlas Networks, LLC From cidr-report at potaroo.net Fri Aug 13 17:00:04 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Aug 2010 22:00:04 GMT Subject: BGP Update Report Message-ID: <201008132200.o7DM04Bu030458@wattle.apnic.net> BGP Update Report Interval: 05-Aug-10 -to- 12-Aug-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS3464 25838 2.5% 1174.5 -- ASC-NET - Alabama Supercomputer Network 2 - AS5536 21300 2.1% 213.0 -- Internet-Egypt 3 - AS23700 18395 1.8% 13.0 -- BM-AS-ID PT. Broadband Multimedia, Tbk 4 - AS35931 17042 1.7% 5680.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - AS35805 14085 1.4% 17.3 -- SILKNET-AS SILKNET ISP 6 - AS31204 13268 1.3% 510.3 -- SUNCOMMUNICATIONS-AS JV "Sun Communications" Autonomous System 7 - AS7552 9994 1.0% 13.1 -- VIETEL-AS-AP Vietel Corporation 8 - AS32528 9802 1.0% 2450.5 -- ABBOTT Abbot Labs 9 - AS3816 8831 0.9% 27.2 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 10 - AS9829 8773 0.9% 45.2 -- BSNL-NIB National Internet Backbone 11 - AS48754 8596 0.8% 8596.0 -- SOBIS-AS SOBIS SOLUTIONS SRL 12 - AS5800 8393 0.8% 40.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 13 - AS21017 7703 0.8% 770.3 -- VSI-AS VSI AS 14 - AS45464 7558 0.7% 184.3 -- NEXTWEB-AS-AP Room 201, TGU Bldg 15 - AS15802 7310 0.7% 10.4 -- DU-AS1 Emirates Integrated Telecommunications Company PJSC (EITC-DU) 16 - AS17488 7171 0.7% 18.6 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 17 - AS37204 7088 0.7% 708.8 -- TELONE 18 - AS36992 6632 0.7% 47.7 -- ETISALAT-MISR 19 - AS8452 6509 0.6% 13.4 -- TEDATA TEDATA 20 - AS17974 5823 0.6% 7.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS48754 8596 0.8% 8596.0 -- SOBIS-AS SOBIS SOLUTIONS SRL 2 - AS35931 17042 1.7% 5680.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 3 - AS11196 2978 0.3% 2978.0 -- NESTLE-USA - Nestle USA 4 - AS32528 9802 1.0% 2450.5 -- ABBOTT Abbot Labs 5 - AS53532 1565 0.1% 1565.0 -- KINGMETALS - King Architectural Metals 6 - AS3464 25838 2.5% 1174.5 -- ASC-NET - Alabama Supercomputer Network 7 - AS17819 4690 0.5% 1172.5 -- ASN-EQUINIX-AP Equinix Asia Pacific 8 - AS46715 1117 0.1% 1117.0 -- ENERGYNET-COM - EnergyNet.com, Inc. 9 - AS21017 7703 0.8% 770.3 -- VSI-AS VSI AS 10 - AS47593 766 0.1% 766.0 -- ATELECOM A-Telcom Ltd 11 - AS27027 744 0.1% 744.0 -- ANBELL ASN-ANBELL 12 - AS523 2201 0.2% 733.7 -- REDSTONE-AS - Headquarters, USAISC 13 - AS37204 7088 0.7% 708.8 -- TELONE 14 - AS11613 699 0.1% 699.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 15 - AS16906 1226 0.1% 613.0 -- El Salvador Network, S. A. 16 - AS48565 591 0.1% 591.0 -- POCZTAPOLSKA-AS Poczta Polska Spolka Akcyjna 17 - AS50257 1038 0.1% 519.0 -- A-MOBILE-AS JV A-Mobile Ltd. 18 - AS31204 13268 1.3% 510.3 -- SUNCOMMUNICATIONS-AS JV "Sun Communications" Autonomous System 19 - AS26383 3126 0.3% 446.6 -- CHILITECH - CHILITECH INTERNET SOLUTIONS, INC. 20 - AS27094 416 0.0% 416.0 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 129.66.128.0/17 12893 1.2% AS3464 -- ASC-NET - Alabama Supercomputer Network 2 - 129.66.0.0/17 12888 1.2% AS3464 -- ASC-NET - Alabama Supercomputer Network 3 - 63.211.68.0/22 9458 0.9% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - 91.212.23.0/24 8596 0.8% AS48754 -- SOBIS-AS SOBIS SOLUTIONS SRL 5 - 198.140.43.0/24 7559 0.7% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - 190.65.228.0/22 5735 0.5% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 7 - 130.36.34.0/24 4898 0.4% AS32528 -- ABBOTT Abbot Labs 8 - 130.36.35.0/24 4898 0.4% AS32528 -- ABBOTT Abbot Labs 9 - 95.32.192.0/18 3835 0.3% AS21017 -- VSI-AS VSI AS 10 - 95.32.128.0/18 3800 0.3% AS21017 -- VSI-AS VSI AS 11 - 41.34.29.0/24 3224 0.3% AS8452 -- TEDATA TEDATA 12 - 196.2.16.0/24 3144 0.3% AS10474 -- NETACTIVE 13 - 206.184.16.0/24 3044 0.3% AS174 -- COGENT Cogent/PSI 14 - 63.78.157.0/24 2978 0.3% AS11196 -- NESTLE-USA - Nestle USA 15 - 202.92.235.0/24 2498 0.2% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 16 - 216.126.136.0/22 2492 0.2% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 17 - 202.167.253.0/24 2342 0.2% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 18 - 202.177.223.0/24 2342 0.2% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 19 - 72.20.248.0/21 1968 0.2% AS26383 -- CHILITECH - CHILITECH INTERNET SOLUTIONS, INC. 20 - 143.138.107.0/24 1595 0.1% AS747 -- TAEGU-AS - Headquarters, USAISC Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Aug 13 17:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Aug 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201008132200.o7DM001r030439@wattle.apnic.net> This report has been generated at Fri Aug 13 21:11:36 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 Prefixes CIDR Agg 06-08-10 330860 204039 07-08-10 330883 203929 08-08-10 330806 204061 09-08-10 330840 204237 10-08-10 331016 204310 11-08-10 331070 204498 12-08-10 331297 204410 13-08-10 331362 204873 AS Summary 35099 Number of ASes in routing system 14911 Number of ASes announcing only one prefix 4495 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 96214848 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'). --- 13Aug10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 331680 204731 126949 38.3% All ASes AS6389 3855 284 3571 92.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4495 1840 2655 59.1% TWTC - tw telecom holdings, inc. AS19262 1946 279 1667 85.7% VZGNI-TRANSIT - Verizon Online LLC AS4766 1862 509 1353 72.7% KIXS-AS-KR Korea Telecom AS22773 1176 66 1110 94.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1508 433 1075 71.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS17488 1343 301 1042 77.6% HATHWAY-NET-AP Hathway IP Over Cable Internet AS5668 1129 89 1040 92.1% AS-5668 - CenturyTel Internet Holdings, Inc. AS18566 1087 63 1024 94.2% COVAD - Covad Communications Co. AS6478 1291 373 918 71.1% ATT-INTERNET3 - AT&T WorldNet Services AS8151 1463 568 895 61.2% Uninet S.A. de C.V. AS10620 1091 290 801 73.4% Telmex Colombia S.A. AS8452 1162 430 732 63.0% TEDATA TEDATA AS1785 1785 1090 695 38.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS7545 1401 717 684 48.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS7303 789 111 678 85.9% Telecom Argentina S.A. AS4808 899 279 620 69.0% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 677 72 605 89.4% MPX-AS Microplex PTY LTD AS7552 652 92 560 85.9% VIETEL-AS-AP Vietel Corporation AS4780 691 165 526 76.1% SEEDNET Digital United Inc. AS7018 1477 954 523 35.4% ATT-INTERNET4 - AT&T WorldNet Services AS24560 1005 491 514 51.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17676 574 75 499 86.9% GIGAINFRA Softbank BB Corp. AS3356 1152 665 487 42.3% LEVEL3 Level 3 Communications AS7011 1137 659 478 42.0% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS22047 550 76 474 86.2% VTR BANDA ANCHA S.A. AS28573 1067 602 465 43.6% NET Servicos de Comunicao S.A. AS7738 477 30 447 93.7% Telecomunicacoes da Bahia S.A. AS14420 547 104 443 81.0% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS36992 652 210 442 67.8% ETISALAT-MISR Total 38940 11917 27023 69.4% Top 30 total Possible Bogus Routes 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS6453 GLOBEINTERNET TATA Communications 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 49.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 101.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 116.68.136.0/21 AS28045 Pantel Communications 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.247.100.0/22 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.212.136.0/24 AS47316 ENGINE-NETWORKS-AS Engine Networks (Formerly Engine Technology S.r.l.) 178.212.137.0/24 AS47316 ENGINE-NETWORKS-AS Engine Networks (Formerly Engine Technology S.r.l.) 178.212.138.0/24 AS47316 ENGINE-NETWORKS-AS Engine Networks (Formerly Engine Technology S.r.l.) 178.212.139.0/24 AS47316 ENGINE-NETWORKS-AS Engine Networks (Formerly Engine Technology S.r.l.) 178.212.140.0/24 AS47316 ENGINE-NETWORKS-AS Engine Networks (Formerly Engine Technology S.r.l.) 178.212.141.0/24 AS47316 ENGINE-NETWORKS-AS Engine Networks (Formerly Engine Technology S.r.l.) 178.212.142.0/24 AS47316 ENGINE-NETWORKS-AS Engine Networks (Formerly Engine Technology S.r.l.) 178.212.143.0/24 AS47316 ENGINE-NETWORKS-AS Engine Networks (Formerly Engine Technology S.r.l.) 181.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.51.100.0/24 AS16953 ASCENT-MEDIA-GROUP-LLC - Ascent Media Group, LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 204.238.70.0/24 AS36826 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.196.24.0/22 AS33724 BIZNESSHOSTING - VOLICO 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.72.192.0/23 AS27375 IDS-TELECOM - IDS Telecom 206.72.194.0/23 AS27375 IDS-TELECOM - IDS Telecom 206.72.196.0/23 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 206.72.208.0/24 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.209.0/24 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 208.84.76.0/22 AS18561 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From ken at sizone.org Fri Aug 13 17:03:38 2010 From: ken at sizone.org (Ken Chase) Date: Fri, 13 Aug 2010 18:03:38 -0400 Subject: Lightly used IP addresses In-Reply-To: <20100813213942.GD8181@vacation.karoshi.com.> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> <20100813200658.GC8181@vacation.karoshi.com.> <024484A8-FE17-4B2D-B059-5AAD4F4DC61B@arin.net> <20100813213942.GD8181@vacation.karoshi.com.> Message-ID: <20100813220338.GN2582@sizone.org> On Fri, Aug 13, 2010 at 09:39:42PM +0000, bmanning at vacation.karoshi.com said: > Thanks for this John. My hope is that folks will try and > avoid using the courts as the arbitor in the event of > dispute over right to use. > >--bill Civil courts is one thing - criminal courts for fraudulent use might pack a bit more punch. Not sure if anyone wants to go down that road - once that happens I can see the levels of govt funding these courts wanting more control of the community if they're going to be footing the bill for policing it. I'm not a fan of 'series-of-tubes' types getting more involved in this, much less of it coming under the aegis of the 'cyberwar command centre'-or-whatever-it's- called ridiculousness that I'm sure would quickly be suggested. (Remember when simple hacking and phreaking suddenly became "terr'ism"? Namespace/terminology is everything in politics.) Something needs doing though - we personally were once the victims of another org we had a dispute with announcing our prefixes to AS701 through some legacy LOA for our block and nullrouting all incoming traffic. Not much we could do but whine and bleat at whoever would listen (was > 12 years ago, we didnt know about nanog in our clubie state at the time...). Calling 701 and asking them to shut it down was met with "we'd have to ask our superiors" and what not, and never resulted in anything. We even contacted the RCMP here in Canada, who were less clued than even we were. The offender eventually stopped 24-30 hours later and ultimately went unpunished. Can't even think of what the solution today would be other than posting to Nanog-l and bleating some more. Ideas? Without an officially sanctioned and seriously-operated 'policing' arm by and for the community, the community and individual members will remain victims of malicious activity of this nature. This does cover delinquent use for non-payment as well, all the way up to spammer and other criminal activity. Are there any BGP-related protocols that can be leveraged to provide this action, but are also resistant to tampering/exploit? (Im sure "yes" with a big "it's complicated"). I don't know what to suggest, but perhaps a more binding set of policies for ARIN members to engage in policing/responding to shutdown requests on the community's behalf and some penalties for not upholding agreements is in order. /kc -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From jared at puck.nether.net Fri Aug 13 17:21:56 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 13 Aug 2010 18:21:56 -0400 Subject: Lightly used IP addresses In-Reply-To: <20100813212544.GJ2582@sizone.org> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> <1ACD377D-B50A-4DB6-8DA4-87B8682D0367@oicr.on.ca> <1A72F43E-CAC8-4B3A-841D-ADA399FCAF98@puck.nether.net> <20100813212544.GJ2582@sizone.org> Message-ID: Sounds like your place is where the spammers should camp out.... Here I know we have eaten costs of term liability and cancelled contracts more than the dollar figures you have mentioned below to keep the net clean. Sad that it appears you may not be willing to put the money where your mouth is. If anyone sees us (2914) routing space of this sort and does not get a favorable response let me know in private. I will personally follow up on any issues. I may not be able to respond due to customer privacy issues but surely we need to be aware of badness so we can clean it up. Hope you are in the same position to clean up and terminate people that pose the risk to the Internet. Jared Mauch On Aug 13, 2010, at 5:25 PM, Ken Chase wrote: > On Fri, Aug 13, 2010 at 05:00:04PM -0400, Jared Mauch said: >> I know of several large providers that would stop routing such "rogue" space. > > Really? They'd take a seriously delinquent (and we're only talking about non > payment after several months to Arin, not spammers or other 'criminal' > elements) that's still paying for their transit and cut off their prefix > announcements? I dont know that that's true for most outfits in these tough > times. Nixing a $5000 or $10000+ MRC revenue stream probably requires some > hard thought at high levels in most outfits. > >> Any provider that isn't prepared to deal with such a possible customer > threat or problem you don't want to be associating with. They likely harbor > other badness as well. > > Possibly, but this isnt that much of a gateway drug. I know lots of companies > in a financial crunch right now, and if losing the i-a.a reverse is the only > effect of being late on a payment 'til the sun starts shining again' when > their own customers start making good on old invoices, then I think many > others would choose to delay paying ARIN instead. > > When things get tough, payables are readily triaged into high and low > priority. Perhaps NOC peeps on this list arent exposed to such decisions made > in other departments - we run a small operation here so we're all part of such > things. Some harsh realities in business sometimes! > > In many cases I suspect ARIN ends up as low priority, without any criminal > mindset in operation putting them there - some of these operators might even > be altruistically thinking of their employees too - we know how fast service > goes stale in a multi-day outtage - losing connectivity may mean employees are > soon not paid and literally go hungry. So most outfits will pay their > upstreams before ARIN - and they can keep their revenue streams going and pay > their employees - and in the long run, one day maybe pay ARIN too. Who > disagrees? Go from that example to paying for power/colo, phone, etc and tell > me where ARIN is on your triage list during a cashflow event. > >> It may take some time to catch up to them but we have seen more of these > rogue elements end up with people refusing to sell to them or law > enforcement taking some action. > > I know of a few such entities that are semi-chronically late in paying ARIN, > but they still havent taken on spammers or Chinese intelligence > operations/cyberwar plaforms as customers yet, despite your broken broken > window/gateway drug analogy. It aint all black and white, there's lots of gray > out there, and organizations that are forced into unfortunate circumstance > through current economics, possibly mismanagement and cluelessness too, but > without any malice at work. > >> If your management does not realize they are buying from possible > criminals, you get what you pay for. > > If the criminals all wore t shirts that said they're part of the club that'd be easy. > When a company is having a cashflow issues, I'd say they're just in a very big club. > If they manage to pay me, I dont ask any questions about the ethics of their triaging > of other payables. > >> I've found a number of cases where providers are actually doing mitm and > stealing SIP credentials for fraud. Make sure you actually have good > controls and communication for when things hit the fan.... > > Examples of shitty fans, and controls? just want a better idea of what you're referring > to. > > /kc > -- > Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA > Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From avg at kotovnik.com Fri Aug 13 17:33:00 2010 From: avg at kotovnik.com (Vadim Antonov) Date: Fri, 13 Aug 2010 15:33:00 -0700 Subject: Lightly used IP addresses In-Reply-To: <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> Message-ID: <4C65C81C.5060809@kotovnik.com> John - you do not get it... First of all, I don't want your organization to have ANY policy at all. Being just a title company for IP blocks is well and good - and can be easily done at maybe 1% of your budget. Title companies do not tell people if they can buy or sell, they just record the current ownership. They do not create controversy or conflict - in fact, their sole reason for existence is to reduce expenses involved in figuring out who has rights to what. Secondly, if you have delusion that you somehow represent me (or other Internet users), get rid of that delusion. Simply because you don't. I didn't vote for you, and gave your organization no right to claim to have my consent - individually or collectively. I'm not bound by any of your policies, and, as a matter of fact, I have no say in them (and do not have a wish to participate). Writing a petition to have a policy changed is something a serf does towards his lord, so I'll spare you the embarrassment of reading what I have to say to anybody suggesting this to me. ARIN as a policy-making body exists solely due to cluelessness of telco management. If the execs had any clue, they'd realize that there is NO such thing as owning a block of IP addresses - the real object is the contractual right to send packets to that address block over their networks. Because their customers generally want universal connectivity, they are forced to cooperate with each other - but, as everybody in this age of NATs, firewalls, and Great Walls knows, universal connectivity is just a myth. Coverage in connectivity can (and should) be a competitive discriminator, rather than absolutist one-size-fits-all regulatory pipe dream. What they have done is gave control over this right to a third party for no good reason whatsoever. (Yes, Randy, it did seem like a good idea - but, just like any other idea involving giving some people policy-making powers, - it was bound to go sour and start serving interests of these people rather than the interests of subjects of their rule-making). ISPs can increase their revenues by selling this right rather than _paying_ to ARIN for being able to exercise this right. All it takes is a bunch of reciprocity agreements saying, essentially, "we'll carry yours if you carry ours". As soon as one large ISP figures that out, this particular political house of cards will go down, quickly. With due respect, --vadim John Curran wrote: > On Aug 13, 2010, at 4:35 PM, Randy Bush wrote: > >>> How come ARIN has any say at all if A wants to sell and B wants to >>> buy? Trying to fend off the imaginary monopolistic hobgoblin? >>> >> self-justification for arin's existence, flying people around to lotso >> meetings, fancy hotels, ... >> >> at the rirs, income and control are more important than the health and >> growth of the internet. basically, the rirs are another case of seemed >> like a good idea at the time. >> > > Vadim - We'll run the database anyway you (collectively) want us to... > what policy would you prefer, and can you submit it as a proposal? > > (and to answer Randy - the only control over the administration is based > on the policies adopted. Reduce the corpus of applicable policy if that > is your desire.) > > /John > > John Curran > President and CEO > ARIN > > > > > > From kloch at kl.net Fri Aug 13 17:36:36 2010 From: kloch at kl.net (Kevin Loch) Date: Fri, 13 Aug 2010 18:36:36 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> Message-ID: <4C65C8F4.5070205@kl.net> Randy Bush wrote: >> (and to answer Randy - the only control over the administration is based >> on the policies adopted. Reduce the corpus of applicable policy if that >> is your desire.) > > we created careers for junior policiy weenies. arin and other rirs have > become well-funded playgrounds for the semi-clued who think they can and > should tell others how to run their businesses, operate the internet, .. Yet most of the bad ideas in the past 15 years have actually come from the IETF (TLA's, no end site multihoming, RA religion), some of which have actually been "fixed" by the RIR's. The RIR's provide uniqueness and have done a good job at that. Who cares how they make the sausage? - Kevin From jeroen at mompl.net Fri Aug 13 17:52:30 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 13 Aug 2010 15:52:30 -0700 Subject: Two /8s allocated to APNIC from IANA (49/8 and 101/8)] In-Reply-To: References: Message-ID: <4C65CCAE.70005@mompl.net> Mikel Jimenez Fernandez wrote: > Good news for IPV6 fans! >> Forwarding on behalf of APNIC. >> 2010 and will be making allocations from these ranges in the near >> future: >> >> 49/8 >> 101/8 More netblocks to block against spam I say. :-| Someone on another list posted this, you may wish to update your blocklists to include 209.153.64.0/19 since it's clearly all going to be used for snowshoe spam: "Sound Advice Limited SOUNDNET97 (NET-209-153-64-0-1) 209.153.64.0 - 209.153.127.255 Computers & Tele-Comm, Inc. SOUNDNET-SWIP-FOR-COMPUTERS-TELECOMM (NET-209-153-64-0-2) 209.153.64.0 - 209.153.95.255 209.153.64.0/19 6.64.153.209.in-addr.arpa domain name pointer manofthepeople.info. 7.64.153.209.in-addr.arpa domain name pointer manofthepeople.info. 8.64.153.209.in-addr.arpa domain name pointer manofthepeople.info. 9.64.153.209.in-addr.arpa domain name pointer manofthepeople.info. .... 10.65.153.209.in-addr.arpa domain name pointer hydrophthalmus.couponcupholder.com. 11.65.153.209.in-addr.arpa domain name pointer indispensability.couponcupholder.com. 12.65.153.209.in-addr.arpa domain name pointer lancinate.couponcupholder.com. 13.65.153.209.in-addr.arpa domain name pointer landwehr.couponcupholder.com. 14.65.153.209.in-addr.arpa domain name pointer moralize.couponcupholder.com. 15.65.153.209.in-addr.arpa domain name pointer mump.couponcupholder.com. .... 104.66.153.209.in-addr.arpa domain name pointer devilship.yellshowcoupons.com. 105.66.153.209.in-addr.arpa domain name pointer disclaimer.yellshowcoupons.com. 106.66.153.209.in-addr.arpa domain name pointer expressman.yellshowcoupons.com." Enjoy, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From kaze0010 at umn.edu Fri Aug 13 18:01:20 2010 From: kaze0010 at umn.edu (Haudy Kazemi) Date: Fri, 13 Aug 2010 18:01:20 -0500 Subject: off-topic: historical query concerning the Internet bubble In-Reply-To: References: <604794.12749.qm@web53002.mail.re2.yahoo.com> Message-ID: <4C65CEC0.9030808@umn.edu> Roland Perry wrote: > Kenny Sallee writes >> So the whole 'myth' of Internet doubling every 100 days to me is >> something someone (ODell it seems) made up to appease someone higher >> in the chain or a government committee that really doesn't get it. > > [Whether it was really 100 days, or 200 days...] a statistic like this > has very real operational significance, because it sets expectations > in the minds of senior management and investors that the new shiny > hardware (or leased line, or peering agreement...) you just put in > place isn't going to last "a lifetime", and will need > replacing/upgrading really quite soon. Part of this rapid hardware replacement cycle almost certainly had to do with the rapid growth in CPU capabilities in comparison to software. New classes of applications and capabilities were opening up just as fast as CPUs would allow. Many network appliances use embedded processors based on the same chips used in desktops or laptops of similar vintage. They run custom software and may have additional dedicated chips. Thus the development of the FrankenPix and custom Linksys wireless router firmwares. Today even a 3(+) year old machine can do a fine job running office tasks (given enough RAM), whereas in the late 90s/early 00s, a three year old PC was not likely to be able to run the then current software very well. Today CPUs have progressed so far ahead of most software that we're able to combine multiple systems into one through virtualization and still obtain good performance. Tasks formerly given to dedicated chips (RAID, sampling rate conversions, compression) are now commonly done on CPUs and GPUs. I also recall articles/webpages/blog-precursors talking about how many packets a particular CPU could route per second. The articles might have been in relation to building custom Linux based routers and router hybrids (such as router-bridges, adding QoS, etc.) I feel that recently many changes in information technology have become less revolutionary and more evolutionary as we look for the reasons to build newer/faster/stronger/better equipment. The rise of netbooks as low CPU/GPU power machines underlines the evolutionary changes. The next series of revolutionary changes are still waiting in the wings (compact/portable devices, realtime 3D, gaming, scientific, and rendering applications are still pushing the envelope). > Another meme at the time (at least in the UK) was the idea of > "Internet Time", where things happened four times as fast as "real > life". So you'd realise that things like a "five year plan" were > really only going to last just over a year. And, of course, policy and > law related to the Internet gets out of date four times as fast, too. I know organizations where equipment refresh/purchase cycles have been stretched from 3 years in the early 2000s to 5 years now, as they've observed both a slowing in need for the latest and greatest, as well as this being a response to budget pressures. Replacement periods are becoming less based on technological obsolescence than on equipment failures and end of warranties. From nathan at atlasnetworks.us Fri Aug 13 18:02:28 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Fri, 13 Aug 2010 23:02:28 +0000 Subject: Lightly used IP addresses In-Reply-To: <4C65C81C.5060809@kotovnik.com> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C281647E7AF@ex-mb-1.corp.atlasnetworks.us> > First of all, I don't want your organization to have ANY policy at all. Where'd you get your AS number, again? From jcurran at arin.net Fri Aug 13 18:08:50 2010 From: jcurran at arin.net (John Curran) Date: Fri, 13 Aug 2010 19:08:50 -0400 Subject: Lightly used IP addresses In-Reply-To: <4C65C81C.5060809@kotovnik.com> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> Message-ID: On Aug 13, 2010, at 6:33 PM, Vadim Antonov wrote: > John - you do not get it... > > First of all, I don't want your organization to have ANY policy at all. Unfortunately, Vadim, even "No Policy" *is* a policy. > Being just a title company for IP blocks is well and good - and can be > easily done at maybe 1% of your budget. Title companies do not tell > people if they can buy or sell, they just record the current ownership. > They do not create controversy or conflict - in fact, their sole reason > for existence is to reduce expenses involved in figuring out who has > rights to what. ARIN (and the other RIRs) performs address allocation, registration services, and membership services. One of the great questions we all face is how much real number resource policy development will be needed when you look out 5 to 10 years, in an environment when there's not any free pool allocations being made for IPv4, and most organizations have their initial IPv6 allocation. Is there really a need for twice annual RIR policy meetings and extensive IPv6 awareness outreach work? If those activities are reduced, and the role of an RIR becomes that of a title registry, there's no doubt that it can be done with a smaller organization. Note - you still need to decide where base registry policy happens (e.g. WHOIS publication/privacy, lawful cooperation, etc.) but this doesn't need to be in ARIN and could be left to your choice of some other association and/or determined by each local government). > ARIN as a policy-making body exists solely due to cluelessness of telco > management. If the execs had any clue, they'd realize that there is NO > such thing as owning a block of IP addresses - the real object is the > contractual right to send packets to that address block over their > networks. In general, telecommunications companies do assert that IP addresses are provided as a component of service and that there is no ownership right therein. This is fairly common in most contracts for ISP services. > ISPs can increase their revenues by selling this right rather than > _paying_ to ARIN for being able to exercise this right. All it takes is > a bunch of reciprocity agreements saying, essentially, "we'll carry > yours if you carry ours". As soon as one large ISP figures that out, > this particular political house of cards will go down, quickly. ISPs are already bundling this right (to use IP addresses) into their service contracts. I agree 100% that it would not be difficult at all for them to self-assert the IP addresses that they'll be using to one another (particularly post free pool depletion w.r.t IPv4) and have no need for an Internet Registry system. If that's how the community wants to do it and the result provides for effective management of the address space, then I think that's a great outcome: i.e. as always, there's no reason for ARIN to exist unless it serves a useful role to the community. For the present, the administration of the current needs-based allocation policy, the policy development process, and online automation work doesn't seem happen without a regional registry and involved community to drive it. > With due respect, Noted. /John John Curran President and CEO ARIN From jcurran at arin.net Fri Aug 13 18:10:05 2010 From: jcurran at arin.net (John Curran) Date: Fri, 13 Aug 2010 19:10:05 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> Message-ID: On Aug 13, 2010, at 5:46 PM, Randy Bush wrote: > to make it easiest to understand, i might grind it up into /24 > equivalents and present as percentages Acknowledged, /John From owen at delong.com Fri Aug 13 18:11:02 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 13 Aug 2010 16:11:02 -0700 Subject: Lightly used IP addresses In-Reply-To: <4C6587C5.6010600@trelane.net> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <4C6587C5.6010600@trelane.net> Message-ID: <8C014A4F-B930-4103-A961-4197A4042066@delong.com> If you know of actual fraud or abuse, please report it to ARIN. ARIN does investigate and attempt to resolve those issues. Owen On Aug 13, 2010, at 10:58 AM, Andrew Kirch wrote: > Jeff, > > Go for it. I've always wondered what ARIN had between it's legs. > > Andrew > > On 8/13/2010 1:53 PM, Jeffrey Lyon wrote: >> 9. I could point out so many cases of "justification abuse" or >> outright fraudulent justification and I bet nothing would actually >> transpire. >> >> My two cents. >> >> Jeff >> >> >> On Fri, Aug 13, 2010 at 10:14 PM, Owen DeLong wrote: >>> On Aug 13, 2010, at 10:36 AM, John Levine wrote: >>> >>>>> http://www.circleid.com/posts/psst_interested_in_some_lightly_used_ip_addresses/ >>>>> Discuss. :-) >>>> I don't entirely understand the process. Here's the flow chart as far >>>> as I've figured it out: >>>> >>>> 1. A sells a /20 of IPv4 space to B for, say, $5,000 >>>> >>>> 2. A tells ARIN to transfer the chunk to B >>>> >>>> 3. ARIN says no, B hasn't shown that they need it >>>> >>>> 4. A and B say screw it, and B announces the space anyway >>>> >>>> 5. ??? >>>> >>>> R's, >>>> John >>> 6. ARIN receives a fraud/abuse complaint that A's space is being used by B. >>> 7. ARIN discovers that A is no longer using the space in accordance with their RSA >>> 8. ARIN reclaims the space and A and B are left to figure out who owes what to whom. >>> >>> >>> >> >> > From owen at delong.com Fri Aug 13 18:16:31 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 13 Aug 2010 16:16:31 -0700 Subject: Lightly used IP addresses In-Reply-To: <20100813183143.GV2582@sizone.org> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> Message-ID: On Aug 13, 2010, at 11:31 AM, Ken Chase wrote: > On Fri, Aug 13, 2010 at 02:15:51PM -0400, John R. Levine said: >>>> I don't entirely understand the process. Here's the flow chart as far >>>> as I've figured it out: >>>> >>>> 1. A sells a /20 of IPv4 space to B for, say, $5,000 >>>> >>>> 2. A tells ARIN to transfer the chunk to B >>>> >>>> 3. ARIN says no, B hasn't shown that they need it >>>> >>>> 4. A and B say screw it, and B announces the space anyway >>>> >>>> 5. ??? >>> >>> 6. ARIN receives a fraud/abuse complaint that A's space is being used >>> by B. >>> 7. ARIN discovers that A is no longer using the space in accordance >>> with their RSA >>> 8. ARIN reclaims the space and A and B are left to figure out who owes >>> what to whom. >> >> 9. A and B ignore ARIN's email and continue to announce what they've been >> announcing. >> >> 10. ARIN attempts to allocate the /20 to someone else, who is not amused. >> >> Note that at this point ARIN presumably has no more v4 space left, so a >> threat never to allocate more space to A or B isn't very scary. Given its >> limited practical leverage, ARIN is only effective insofar as its members >> and customers agree that playing by ARIN's rules is more beneficial than >> ignoring them. > > Right, and Im answering my own question here, for (8) about the reclaiming - > what upstream is going to stop carrying prefixes from a downstream that's > 'illegally' announcing them? Is this upstream going to cut that customer off and > lose the revenue, just to satisfy ARIN's bleating? From what I gather, all that > ARIN can do is remove the NS records for the i-a.a reverse zone for the offending > block, making SMTP a little trickier from the block, but not much else. > ARIN can do quite a bit more if the resources are under RSA. If they are legacy resources (which I don't believe there are such things as legacy /20s), then, it's a bit murkier, but, I wouldn't completely count ARIN out. > Unless I didnt see the other large sticks ARIN's carrying? I've never seen them > send hired goons to anyone's door... yet? Contract law anyone? Perhaps you should re-read your RSAs. Owen From jcurran at arin.net Fri Aug 13 18:38:28 2010 From: jcurran at arin.net (John Curran) Date: Fri, 13 Aug 2010 19:38:28 -0400 Subject: Lightly used IP addresses In-Reply-To: <20100813220338.GN2582@sizone.org> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> <20100813200658.GC8181@vacation.karoshi.com> <024484A8-FE17-4B2D-B059-5AAD4F4DC61B@arin.net> <20100813213942.GD8181@vacation.karoshi.com> <20100813220338.GN2582@sizone.org> Message-ID: On Aug 13, 2010, at 6:03 PM, Ken Chase wrote: > > I don't know what to suggest, but perhaps a more binding set of policies for > ARIN members to engage in policing/responding to shutdown requests on the > community's behalf and some penalties for not upholding agreements is in > order. Ken - Be careful what you ask for... There is a fairly significant difference between ARIN administering number resources (as a trade association based on a body of openly-developed policy) and parties deciding not to engage in business with suppliers or customers except under certain conditions. Some countries prohibit discussions of collective business actions of any form, unless the government is involved to insure that the public interest is protected. As Vadim noted, you can certainly bilaterally negotiate with another ISP regarding the nature of the routes/IP addresses/traffic that you exchange, but you might want to seek counsel before trying such on a collective basis... /John John Curran President and CEO ARIN From bill at herrin.us Fri Aug 13 20:51:21 2010 From: bill at herrin.us (William Herrin) Date: Fri, 13 Aug 2010 21:51:21 -0400 Subject: Lightly used IP addresses In-Reply-To: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> Message-ID: On Fri, Aug 13, 2010 at 4:25 PM, Vadim Antonov wrote: > How come ARIN has any say at all if A wants to sell and > B wants to buy? Trying to fend off the imaginary > monopolistic hobgoblin? Because that portion of the address-using community, people just like you, that shows up and participates in ARIN's policy process has its collective brain wrapped around the concept of "justified need." That's how we've always allocated addresses, even before ARIN's inception, and that's how we continue to do it. And in complete fairness - why should folks who received vast tracts of addresses for little or no cost under a justified-need regime now have free reign to monetize their sale? It's one thing for B to pay A to re-architect part of his network in a way that shakes loose some addresses. It's quite another for A and B to swap addresses like it was a futures market. If you would have the "justified need" regime change, you have to learn it's history, how and why it came to be. And then you have to show up, subscribe to the PPML list, keep up with it, and advocate intelligently for new policy. And you have to bring people with you who are willing to make the same time investment. ARIN listens, but they listen to the folks who make the effort. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From randy at psg.com Fri Aug 13 21:55:42 2010 From: randy at psg.com (Randy Bush) Date: Sat, 14 Aug 2010 11:55:42 +0900 Subject: Lightly used IP addresses In-Reply-To: <4C65C81C.5060809@kotovnik.com> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> Message-ID: > John - you do not get it... vadim, i assure you curran gets it. he has been around as long as you and i. the problem is that he has become a fiduciary of an organization which sees its survival and growth as its principal goal, free business class travel for wannabe policy wonks as secondary, and and the well- being of the internet as tertiary. they're just another itu, except the clothing expenses are lower and the decision making process pretends to be more open, but isn't. and the drying up of the free source of integers which they lease to us for hefty fees is pretty scary to these organizations. and, as they were kinda forced to give out /32s in ipv6 space or be seen to be inhibiting the deployment of ipv6, a lot of folk will not be coming back for more v6 for a loooong while. so the rirs are desperately seeking means whereby they can suck more blood from the industry. and the industry blood is getting thinner and thinner, with the telcos redirecting their margin destroying talents from voice to data. how much should we be forced to pay for leasing integers that came for free? how much is the actual registry work (whois and in-addr) worth and why does a larger prefix cost more? the registry financial scam has never been adjusted for reality. and why in hell would i trust these organizations with any control of my routing via rpki certification? they have always said thay would never be involved in routing, but if they control the certification chain, they have a direct stranglehold they can use to extort fees. when the registry work was re-competed and taken from sri to netsol (i think it was called that at the time), rick adams [0] put in a no cost bid to do it all with automated scripts. hindsight tells me we should have supported that much more strongly. and folk who think that would not have scaled, need to know that the netsol lowball solution was mark and scott in a basement with a sun3 and a 56k line. if the iana could get out from under lawyers and domainer greed, and go back to simply being bookkeeper for the internet, they could do the automated solution today. well, with some months of setup. and we could get rid of 95% of the costs the rirs are sucking from our thinning bloodstreams. or a gutsy rir could lead the way. fat chance. randy -- [0] - for the n00bs, rick founded uunet but took his winnings and got out before the real slime got in. From randy at psg.com Fri Aug 13 22:01:07 2010 From: randy at psg.com (Randy Bush) Date: Sat, 14 Aug 2010 12:01:07 +0900 Subject: Lightly used IP addresses In-Reply-To: <4C65C8F4.5070205@kl.net> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C8F4.5070205@kl.net> Message-ID: > Yet most of the bad ideas in the past 15 years have actually come from > the IETF (TLA's, no end site multihoming, RA religion), some of which > have actually been "fixed" by the RIR's. no, they were fixed within the ietf. that's my blood you are taking about, and i know where and by whom it was spent. the fracking rirs, in the name of marla and and lee, actually went to the ietf last month with a proposal to push address policy back to the ietf from the ops. and they just did not get thomas's proposal to move more policy from ietf back to ops. randy From randy at psg.com Fri Aug 13 22:01:26 2010 From: randy at psg.com (Randy Bush) Date: Sat, 14 Aug 2010 12:01:26 +0900 Subject: Lightly used IP addresses In-Reply-To: <8C26A4FDAE599041A13EB499117D3C281647E7AF@ex-mb-1.corp.atlasnetworks.us> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <8C26A4FDAE599041A13EB499117D3C281647E7AF@ex-mb-1.corp.atlasnetworks.us> Message-ID: >> First of all, I don't want your organization to have ANY policy at all. > Where'd you get your AS number, again? sri From drc at virtualized.org Fri Aug 13 22:05:00 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 13 Aug 2010 20:05:00 -0700 Subject: Lightly used IP addresses In-Reply-To: <8C26A4FDAE599041A13EB499117D3C281647E679@ex-mb-1.corp.atlasnetworks.us> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> <1ACD377D-B50A-4DB6-8DA4-87B8682D0367@oicr.on.ca>, <1A72F43E-CAC8-4B3A-841D-ADA399FCAF98@puck.nether.net> <8C26A4FDAE599041A13EB499117D3C281647E679@ex-mb-1.corp.atlasnetworks.us> Message-ID: <7B82D0A5-96F0-48B0-8777-6DE165E9CF98@virtualized.org> Nathan, On Aug 13, 2010, at 2:51 PM, Nathan Eisenberg wrote: >> I'm not against ARIN, I think they have good intentions. I'd like to think so anyway. > Same here. I'm honestly surprised that there is as much dissention from this attitude as there seems to be... I suspect the issue arises when ARIN (or anyone else for that matter) attempts to assert dominion over resources folks consider their own. That is, in the original scenario John Levine posed: "1. A sells a /20 of IPv4 space to B for, say, $5,000 2. A tells ARIN to transfer the chunk to B 3. ARIN says no, B hasn't shown that they need it 4. A and B say screw it, and B announces the space anyway" I believe the point of contention lies in step 3. In the case of the 38% of the address space described by John Curran as "managed" by ARIN with an (L)RSA, there is contractual language that dictates ARIN has some authority to "say no". In the remaining 62% of the space (according to ARIN), presumably space allocated without any form of RSA, the issue is, at least to my mind, far less clear. In the face of this lack of clarity, when you have folks saying things like: "6. ARIN receives a fraud/abuse complaint that A's space is being used by B. 7. ARIN discovers that A is no longer using the space in accordance with their RSA 8. ARIN reclaims the space and A and B are left to figure out who owes what to whom." without proviso about whether an (L)RSA is applicable, it isn't particularly surprising that folks who can imagine themselves as (or at least sympathize with) A or B getting their dander up. In addition, as/after the IPv4 free pool is exhausted, there are going to be lots of folks who discover they have more address space than they really need as there are going to be lots of folks who are desperately in need of additional IPv4 addresses. This will result in address markets. Some people (e.g., I'm guessing Vadim) do not see a role for ARIN as mediator of an exchange between these two sets of folks. Others believe that there needs to be some 'regulator' of the market or (e.g.) speculators will swoop in and buy up all the allocated-but-unused IPv4 address space, resulting in those in desperate need of IPv4 addresses paying through the nose. Given the arguments between free vs. regulated markets generates much heat in pretty much every other economic discussion, I'd be surprised if it didn't occur in address markets. Regards, -drc From randy at psg.com Fri Aug 13 22:06:06 2010 From: randy at psg.com (Randy Bush) Date: Sat, 14 Aug 2010 12:06:06 +0900 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> <1ACD377D-B50A-4DB6-8DA4-87B8682D0367@oicr.on.ca> <1A72F43E-CAC8-4B3A-841D-ADA399FCAF98@puck.nether.net> <20100813212544.GJ2582@sizone.org> Message-ID: > Here I know we have eaten costs of term liability and cancelled > contracts more than the dollar figures you have mentioned below to > keep the net clean. Sad that it appears you may not be willing to put > the money where your mouth is. how noble of you. and how perceptive to equate legitimate address space use with criminality. i am deeply heartened that there a big kids like you to save the rest of us from evil. randy From jcurran at arin.net Fri Aug 13 22:23:52 2010 From: jcurran at arin.net (John Curran) Date: Fri, 13 Aug 2010 23:23:52 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> Message-ID: On Aug 13, 2010, at 10:55 PM, Randy Bush wrote: > ... > if the iana could get out from under lawyers and domainer greed, and go > back to simply being bookkeeper for the internet, they could do the > automated solution today. well, with some months of setup. and we > could get rid of 95% of the costs the rirs are sucking from our thinning > bloodstreams. or a gutsy rir could lead the way. fat chance. If the allocation and reassignment of address space has no policy associated with it, then there's no doubt that most of the registry functions can be automated, and there's no need for the associated policy development process, public policy meetings, travel, conference calls. Quite a bit of savings available there, but the community first has to decide on permanent policy (or lack thereof :-) for that automated world before we can reap the savings. /John John Curran President and CEO ARIN From randy at psg.com Fri Aug 13 22:32:06 2010 From: randy at psg.com (Randy Bush) Date: Sat, 14 Aug 2010 12:32:06 +0900 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> Message-ID: > If the allocation and reassignment of address space has no policy > associated with it, then there's no doubt that most of the registry > functions can be automated, and there's no need for the associated > policy development process, public policy meetings, travel, conference > calls. Quite a bit of savings available there, but the community > first has to decide on permanent policy (or lack thereof :-) for that > automated world before we can reap the savings. when the 'community' is defined as those policy wannabes who do the flying, take the cruise junkets, ... this is a self-perpetuating steaming load that is not gonna change. one start would be for arin to have the guts not to pay travel expenses of non-employees/contractors. randy From bmanning at vacation.karoshi.com Fri Aug 13 22:52:42 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 14 Aug 2010 03:52:42 +0000 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <8C26A4FDAE599041A13EB499117D3C281647E7AF@ex-mb-1.corp.atlasnetworks.us> Message-ID: <20100814035242.GA10362@vacation.karoshi.com.> On Sat, Aug 14, 2010 at 12:01:26PM +0900, Randy Bush wrote: > >> First of all, I don't want your organization to have ANY policy at all. > > Where'd you get your AS number, again? > > sri good thing SRI is still around. wonder what they would say if asked about the ASNs (and prefixes) they handed out way back when... :) --bill From johnl at iecc.com Fri Aug 13 23:00:19 2010 From: johnl at iecc.com (John Levine) Date: 14 Aug 2010 04:00:19 -0000 Subject: 600 acres and a mule, was Lightly used IP addresses In-Reply-To: Message-ID: <20100814040019.74171.qmail@joyce.lan> > And in complete fairness - why should folks who received vast tracts > of addresses for little or no cost under a justified-need regime now > have free reign to monetize their sale? All of the real estate in my part of New York traces back to Military Tract so and so. In the 1790s the state allocated two million acres on a justified-need basis, with the rule being that if you were a Revolutionary War veteran, that justified you getting 600 acres, free. You had to provide your own mule. Once the lots were all handed out, in subsequent transfers, nobody justified anything. If you want to sell and I want to buy, that's that and the county records it for a nominal clerical fee. You will doubtless find similar histories all over the country. IPv4 space is rapidly nearing the end of the homesteading era, and I suspect you're going to have as much luck insisting that future transfers obey the historic rules as my town would have had insisting that owners could subdivide only if they were selling to other veterans. To firm up my example of A selling to B a little, I was assuming there was nothing wrong with B other than that ARIN wasn't satisfied with the documentation they provided to show why they needed a /20. Maybe they're a startup, their VCs don't want them leaking their plans, and don't see why anyone needs any justification other than the bill of sale from A. (Yes, I realize there's ways to finesse this particular scenario. It's an example.) There's nothing hijacked here, the space wasn't allocated to anyone other than A who for some reason, such as loss of a customer, doesn't want it any more. Are networks going to treat this the same as someone hijacking space and hosting malware or sending fake drug spam? Really? From what I can tell, unless a range is emitting actively annoying traffic, there's no pushback about routing it at all. R's, John PS: If you disagree, tell me about 130.105.0.0/16, which belongs to the long defunct Open Software Foundation. From jeffrey.lyon at blacklotus.net Fri Aug 13 23:12:27 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 14 Aug 2010 08:42:27 +0430 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> <20100813200658.GC8181@vacation.karoshi.com> <024484A8-FE17-4B2D-B059-5AAD4F4DC61B@arin.net> <20100813213942.GD8181@vacation.karoshi.com> <20100813220338.GN2582@sizone.org> Message-ID: John et al, I have read many of your articles about the need to migrate to IPv6 and how failure to do so will impact business continuity sometime in the next 1 - 3 years. I've pressed our vendors to support IPv6 (note: keep in mind we're a DDoS mitigation firm, our needs extend beyond routers and switches) and found that it's a chicken and egg situation. Vendors are neglecting to support IPv6 because there is "no demand." I've pointed out your articles and demanded IPv6 support, some are promising results in the next several months. We will see. Meanwhile, there are hosting companies, dedicated server companies, etc. with /17 and /18 allocations who are either forging justification or wildly abusing the use of that space outside of the declared need. I know of at least a couple of companies roughly the same size as my own that fit this category. I'm actually a customer of one company that will sell a /24 without substantial justification (eg. just write "SSL web sites" in a block on the order form and you're good). Meanwhile, we have used a /21 since 2006 and to this day have not requested additional space. Instead we make more efficient use of space and avoid selling them in bulk to dedicated server customers or charge substantially for the space and let economics do the work for us. A disgusting number of companies are involved in: - Black hat SEO ("I need 2000 IP's from at least 20 different Class C's.","No","Why not, companies A, B, and C are offering this for $X") - IRC virtual host abuse ("My customers want 2 x Class C per shell server for their bots and vhosts","No","OK fine, we'll buy one from Company X for $Y") ARIN needs to investigate these companies and start reclaiming space. Pose as a customer, see if they'll sell you a /24 or shorter on a dedicated server for some arbitrary reason, and if so they're busted. >From there launch a full investigation and start reclaiming space. The other day I had a customer asking if he could buy a /16 for some ungodly reason. Best regards, Jeff On Sat, Aug 14, 2010 at 4:08 AM, John Curran wrote: > On Aug 13, 2010, at 6:03 PM, Ken Chase wrote: >> >> I don't know what to suggest, but perhaps a more binding set of policies for >> ARIN members to engage in policing/responding to shutdown requests on the >> community's behalf and some penalties for not upholding agreements is in >> order. > > Ken - > > Be careful what you ask for... There is a fairly significant difference > between ARIN administering number resources (as a trade association based > on a body of openly-developed policy) and parties deciding not to engage > in business with suppliers or customers except under certain conditions. > Some countries prohibit discussions of collective business actions of > any form, unless the government is involved to insure that the public > interest is protected. > > As Vadim noted, you can certainly bilaterally negotiate with another ISP > regarding the nature of the routes/IP addresses/traffic that you exchange, > but you might want to seek counsel before trying such on a collective basis... > > /John > > John Curran > President and CEO > ARIN > > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From randy at psg.com Fri Aug 13 23:13:28 2010 From: randy at psg.com (Randy Bush) Date: Sat, 14 Aug 2010 13:13:28 +0900 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C8F4.5070205@kl.net> Message-ID: > the fracking rirs, in the name of marla and and lee, actually went to > the ietf last month with a proposal to push address policy back to the > ietf from the ops. and they just did not get thomas's proposal to > move more policy from ietf back to ops. and, to continue the red herring with jc, i bet you 500 yen that arin paid their travel expenses to go to maastricht nl to do this stupid thing. randy From jcurran at arin.net Fri Aug 13 23:15:28 2010 From: jcurran at arin.net (John Curran) Date: Sat, 14 Aug 2010 00:15:28 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> Message-ID: <12C469D4-B9D7-46F9-ADD7-06917F522FBB@arin.net> On Aug 13, 2010, at 11:32 PM, Randy Bush wrote: >> If the allocation and reassignment of address space has no policy >> associated with it, then there's no doubt that most of the registry >> functions can be automated, and there's no need for the associated >> policy development process, public policy meetings, travel, conference >> calls. Quite a bit of savings available there, but the community >> first has to decide on permanent policy (or lack thereof :-) for that >> automated world before we can reap the savings. > > when the 'community' is defined as those policy wannabes who do the > flying, take the cruise junkets, ... this is a self-perpetuating > steaming load that is not gonna change. In theory, it's quite realistic to see it changing for IPv6 over time, since there is remarkable abundance even just the existing allocations made to date; we've no doubt already issues more IPv6 space that the entire Internet will need, and the only reason that an organization gets space from an RIR is the implication that such space will be routable. If ISPs were to hypothetically charge for use of a non-provider issues prefix and figure out a way to settle up for the routing impact, then there is already plenty of IPv6 space issued today, and one could seek an allocation from nearly anyone and know the cost for it be useable. Getting started via IPv6 would probably be easier than IPv4, but once running if shouldn't be too hard to make work for both. You can then completely eliminate routing driven constraints from the system, and get very close to vending machine with a pull handle for getting more addresses... > one start would be for arin to have the guts not to pay travel expenses > of non-employees/contractors. ARIN Suggestion process: If you submit it, I will bring it to the Board for consideration. In fairness, I will tell you that I'll also recommend to the that we continue to pay for the travel for the Advisory Council, unless and until there is no need for a policy development process. /John From randy at psg.com Fri Aug 13 23:17:57 2010 From: randy at psg.com (Randy Bush) Date: Sat, 14 Aug 2010 13:17:57 +0900 Subject: Lightly used IP addresses In-Reply-To: <12C469D4-B9D7-46F9-ADD7-06917F522FBB@arin.net> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <12C469D4-B9D7-46F9-ADD7-06917F522FBB@arin.net> Message-ID: >> one start would be for arin to have the guts not to pay travel >> expenses of non-employees/contractors. > > ARIN Suggestion process: > > > If you submit it, I will bring it to the Board for consideration. In > fairness, I will tell you that I'll also recommend to the that we > continue to pay for the travel for the Advisory Council, unless and > until there is no need for a policy development process. thanks for reaffirming that talking to arin is a waste of time. randy From jcurran at arin.net Fri Aug 13 23:23:11 2010 From: jcurran at arin.net (John Curran) Date: Sat, 14 Aug 2010 00:23:11 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <12C469D4-B9D7-46F9-ADD7-06917F522FBB@arin.net> Message-ID: On Aug 14, 2010, at 12:17 AM, Randy Bush wrote: > > thanks for reaffirming that talking to arin is a waste of time. If you're going to recommend that we not pay for travel for the ARIN AC, I'm going to recommend otherwise and point out that the AC members need to hear from the community, and that's often in person and at the joint ARIN/NANOG meetings, etc. I can't speak to the strength of your arguments for eliminating travel, but I will carry them to the Board as well, if you use the suggestion process. /John John Curran President and CEO ARIN From jeffrey.lyon at blacklotus.net Fri Aug 13 23:32:35 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 14 Aug 2010 09:02:35 +0430 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <12C469D4-B9D7-46F9-ADD7-06917F522FBB@arin.net> Message-ID: John, I will concur with Randy that much of the travel that ARIN funds is excessive. ARIN has a booth at trade shows so i'm going to guess that entire setup with travel costs about $20,000 - 50,000 per show. Why? To convince me to use ARIN for my IP space needs? To convince us to switch to IPv6? I'm not really understanding this, ARIN can hear from the community for free and without spending tens of thousands of dollars. Why can't we save that money and use it to provide tangible services, like providing advisory and implementation assistance for companies wanting to convert to IPv6? We could use it to fund investigations targeting IP space abuse (see my previous post a few minutes back). Best regards, Jeff On Sat, Aug 14, 2010 at 8:53 AM, John Curran wrote: > On Aug 14, 2010, at 12:17 AM, Randy Bush wrote: >> >> thanks for reaffirming that talking to arin is a waste of time. > > If you're going to recommend that we not pay for travel for the > ARIN AC, I'm going to recommend otherwise and point out that the > AC members need to hear from the community, and that's often in > person and at the joint ARIN/NANOG meetings, etc. I can't speak > to the strength of your arguments for eliminating travel, but I > will carry them to the Board as well, if you use the suggestion > process. > > /John > > John Curran > President and CEO > ARIN > > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From franck at genius.com Fri Aug 13 23:33:58 2010 From: franck at genius.com (Franck Martin) Date: Sat, 14 Aug 2010 16:33:58 +1200 (FJT) Subject: Lightly used IP addresses In-Reply-To: Message-ID: <32655709.176.1281760437814.JavaMail.franck@franck-martins-macbook-pro.local> Funny! On one hand people talk about ARIN providing IP allocation at nearly zero cost and on the other hand talking that ARIN goes after companies that use their allocation for abuse (which has a non trivial cost and potential expensive lawsuits)... Do you know what you want? From jcurran at arin.net Fri Aug 13 23:37:27 2010 From: jcurran at arin.net (John Curran) Date: Sat, 14 Aug 2010 00:37:27 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> <20100813200658.GC8181@vacation.karoshi.com> <024484A8-FE17-4B2D-B059-5AAD4F4DC61B@arin.net> <20100813213942.GD8181@vacation.karoshi.com> <20100813220338.GN2582@sizone.org> Message-ID: On Aug 14, 2010, at 12:12 AM, Jeffrey Lyon wrote: > ARIN needs to investigate these companies and start reclaiming space. > Pose as a customer, see if they'll sell you a /24 or shorter on a > dedicated server for some arbitrary reason, and if so they're busted. >> > From there launch a full investigation and start reclaiming space. Jeff - Yes and No. Yes, we'd like to know if you believe that an organization is forging their address space justification. We always do some cross-checking and verification but it is not foolproof. No, we will not pose as a customer, although we will verify some customer assignments and speak with them. If we find evidence of fraud in company's request to ARIN, we will perform resource review and have them return space to match what they should have received (as described in NRPM section 12). We will also make certain that future requests are very closely reviewed. Recognize that these creative hosting firms are also businesses with customers, and reclaiming IP space out from under them to impact customers isn't the intent of policy. We do occasionally have egregious acts (e.g. where the "ISP" turns out to be simply a purveyor of IP addresses to online marketing firms), and circumstances such as those are where reclamation is used. Does that clarify things? /John John Curran President and CEO ARIN From jeffrey.lyon at blacklotus.net Sat Aug 14 00:00:02 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 14 Aug 2010 09:30:02 +0430 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> <20100813200658.GC8181@vacation.karoshi.com> <024484A8-FE17-4B2D-B059-5AAD4F4DC61B@arin.net> <20100813213942.GD8181@vacation.karoshi.com> <20100813220338.GN2582@sizone.org> Message-ID: John, I have privately e-mailed you 5 x /18 and 3 x /19 that are being abused. If ARIN takes action against even one of these allocations I will commend you publicly. I'll go do the investigation for you if you need evidence. Best regards, Jeff On Sat, Aug 14, 2010 at 9:07 AM, John Curran wrote: > On Aug 14, 2010, at 12:12 AM, Jeffrey Lyon wrote: > >> ARIN needs to investigate these companies and start reclaiming space. >> Pose as a customer, see if they'll sell you a /24 or shorter on a >> dedicated server for some arbitrary reason, and if so they're busted. >>> >> From there launch a full investigation and start reclaiming space. > > Jeff - > > ?Yes and No. > > ?Yes, we'd like to know if you believe that an organization is > ?forging their address space justification. ?We always do some > ?cross-checking and verification but it is not foolproof. > > ?No, we will not pose as a customer, although we will verify some > ?customer assignments and speak with them. ?If we find evidence > ?of fraud in company's request to ARIN, we will perform resource > ?review and have them return space to match what they should have > ?received (as described in > ?NRPM section 12). ?We will also make certain that future requests > ?are very closely reviewed. ?Recognize that these creative hosting > ?firms are also businesses with customers, and reclaiming IP space > ?out from under them to impact customers isn't the intent of policy. > ?We do occasionally have egregious acts (e.g. where the "ISP" turns > ?out to be simply a purveyor of IP addresses to online marketing > ?firms), and circumstances such as those are where reclamation is > ?used. > > Does that clarify things? > /John > > John Curran > President and CEO > ARIN > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From drc at virtualized.org Sat Aug 14 00:00:24 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 13 Aug 2010 22:00:24 -0700 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> <20100813200658.GC8181@vacation.karoshi.com> <024484A8-FE17-4B2D-B059-5AAD4F4DC61B@arin.net> <20100813213942.GD8181@vacation.karoshi.com> <20100813220338.GN2582@sizone.org> Message-ID: On Aug 13, 2010, at 9:12 PM, Jeffrey Lyon wrote: > Vendors are neglecting to support IPv6 because there is "no demand." It would probably be useful to be public about which vendors are still saying there is no demand for IPv6. > Meanwhile, there are hosting companies, dedicated server companies, > etc. with /17 and /18 allocations who are either forging justification > or wildly abusing the use of that space outside of the declared need. It is and always has been trivial to come up with justifications for pretty much anything, regardless of reality. The RIRs do not have the staff or resources to go into requesters and audit them to verify they aren't lying through their teeth. The RIR system fundamentally relies on trust. Always has and always will. Customers of the RIRs must trust that the RIRs are "doing the right thing" and the RIRs must trust that their customers are not "abusing the system". In a world of plentiful resources, this works fine since the costs of abusing the system (on either side) generally outweigh the benefits. To state the obvious, we're (very) soon no longer going to be in a world of plentiful resources. I would be very surprised if the outcome in the addressing world is any different than any other situation where you have a scarce resource and lots of folks with need of that resource. You seem to be suggesting that ARIN (and presumably the other RIRs) invest more in policing the address space and otherwise regulating the market. How much are you willing to pay for that service? Regards, -drc From jcurran at arin.net Sat Aug 14 00:06:55 2010 From: jcurran at arin.net (John Curran) Date: Sat, 14 Aug 2010 01:06:55 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> <20100813200658.GC8181@vacation.karoshi.com> <024484A8-FE17-4B2D-B059-5AAD4F4DC61B@arin.net> <20100813213942.GD8181@vacation.karoshi.com> <20100813220338.GN2582@sizone.org> Message-ID: <5FFBBC71-9AC2-4264-9FEB-2BECF2186DEA@arin.net> On Aug 14, 2010, at 1:00 AM, Jeffrey Lyon wrote: > > John, > > I have privately e-mailed you 5 x /18 and 3 x /19 that are being > abused. If ARIN takes action against even one of these allocations I > will commend you publicly. I'll go do the investigation for you if you > need evidence. I'm not seeking commendation, but thanks for the thought. Whether action will be taken will be based on the findings, and while many people are indeed disappointed that we act less often than desired, I think folks understand why we need to be rather cautious in this area. /John John Curran President and CEO ARIN From randy at psg.com Sat Aug 14 00:06:57 2010 From: randy at psg.com (Randy Bush) Date: Sat, 14 Aug 2010 14:06:57 +0900 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> <20100813200658.GC8181@vacation.karoshi.com> <024484A8-FE17-4B2D-B059-5AAD4F4DC61B@arin.net> <20100813213942.GD8181@vacation.karoshi.com> <20100813220338.GN2582@sizone.org> Message-ID: > You seem to be suggesting that ARIN (and presumably the other RIRs) > invest more in policing the address space and otherwise regulating the > market. How much are you willing to pay for that service? and how would it make the internet any better? randy From jcurran at arin.net Sat Aug 14 00:19:27 2010 From: jcurran at arin.net (John Curran) Date: Sat, 14 Aug 2010 01:19:27 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <12C469D4-B9D7-46F9-ADD7-06917F522FBB@arin.net> Message-ID: <3029E2EB-EEB3-4E1B-A18F-D385BC99391B@arin.net> On Aug 14, 2010, at 12:32 AM, Jeffrey Lyon wrote: > > John, > > I will concur with Randy that much of the travel that ARIN funds is > excessive. ARIN has a booth at trade shows so i'm going to guess that > entire setup with travel costs about $20,000 - 50,000 per show. Why? > To convince me to use ARIN for my IP space needs? To convince us to > switch to IPv6? I'm not really understanding this, ARIN can hear from > the community for free and without spending tens of thousands of > dollars. > > Why can't we save that money and use it to provide tangible services, > like providing advisory and implementation assistance for companies > wanting to convert to IPv6? We could use it to fund investigations > targeting IP space abuse (see my previous post a few minutes back). This year ARIN has undertaken a major initiative in outreach specifically regarding IPv6, and this includes time of several ARIN staff, trade show participation, travel for volunteers from the AC or Board, PR firm, etc. I'd estimate this additional initiative to be near $500,000 in expense within ARIN's $15M/year budget. The goal is to get the message about impending IPv4 depletion and IPv6 transition out to more organizations in the region. One side effect of this is that hopefully you're seeing the IPv6 issue appearing quite a bit more in both trade and business press. While we may think that the IPv4/IPv6 situation is common knowledge, we are running into ISPs and hosting companies each day that believe we've got enough IPv4 addresses for many decades to come. Now, we're doing this because we've had people at the microphones at nearly every ARIN public meeting asking us to do more to increase the visibility of IPv4 depletion and IPv6, so this is definitely something that should get some more discussion at the next ARIN meeting if you feel otherwise. /John John Curran President and CEO ARIN p.s. Ongoing threads on ARIN financials should probably move over to ARIN-discuss sooner or later (out of respect to those on Nanog who didn't think they signed up for that on this operational list...) From jeffrey.lyon at blacklotus.net Sat Aug 14 00:21:38 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 14 Aug 2010 09:51:38 +0430 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> <20100813200658.GC8181@vacation.karoshi.com> <024484A8-FE17-4B2D-B059-5AAD4F4DC61B@arin.net> <20100813213942.GD8181@vacation.karoshi.com> <20100813220338.GN2582@sizone.org> Message-ID: I'm not sure it would make the internet better but it would reinforce integrity in a general sense. If we're to get away with lying on justification I might as well go grab a few /18's before the last /8 is issued. Jeff On Sat, Aug 14, 2010 at 9:36 AM, Randy Bush wrote: >> You seem to be suggesting that ARIN (and presumably the other RIRs) >> invest more in policing the address space and otherwise regulating the >> market. ?How much are you willing to pay for that service? > > and how would it make the internet any better? > > randy > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From randy at psg.com Sat Aug 14 00:23:10 2010 From: randy at psg.com (Randy Bush) Date: Sat, 14 Aug 2010 14:23:10 +0900 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> <20100813200658.GC8181@vacation.karoshi.com> <024484A8-FE17-4B2D-B059-5AAD4F4DC61B@arin.net> <20100813213942.GD8181@vacation.karoshi.com> <20100813220338.GN2582@sizone.org> Message-ID: > I'm not sure it would make the internet better then i don't want to pay for it. if you have not noticed, money is tight, and it ain't gonna get better. randy From bill at herrin.us Sat Aug 14 03:11:58 2010 From: bill at herrin.us (William Herrin) Date: Sat, 14 Aug 2010 04:11:58 -0400 Subject: 600 acres and a mule, was Lightly used IP addresses In-Reply-To: <20100814040019.74171.qmail@joyce.lan> References: <20100814040019.74171.qmail@joyce.lan> Message-ID: On Sat, Aug 14, 2010 at 12:00 AM, John Levine wrote: >> And in complete fairness - why should folks who received vast tracts >> of addresses for little or no cost under a justified-need regime now >> have free reign to monetize their sale? > > All of the real estate in my part of New York traces back to Military > Tract so and so. ?In the 1790s the state allocated two million acres > on a justified-need basis, with the rule being that if you were a > Revolutionary War veteran, that justified you getting 600 acres, free. > You had to provide your own mule. > > Once the lots were all handed out, in subsequent transfers, nobody > justified anything. John, Convincingly said here on an ISP mailing list. But what about the folks who were denied address assignments by ARIN policies over the last 15 years? Denied them based on the fiction that ISPs didn't own IP addresses, that they were merely holding the addresses in trust for the public they serve. With the IPv4 free pool almost totally allocated, what's our residual responsibility to the folks that we (and by we I mean you) deliberately prevented from getting addresses while forking over /9's to Verizon? It might have been wiser to handle IPv4 addresses in a property-like regime. It might yet be smarter to handle IPv6 addresses that way. But we didn't handle IPv4 addresses that way and now that the free pool is nearly empty there would be significant fairness issues with any plan to allow current registrants to treat their IPv4 address holdings as if they were fee simple real estate. Like those 600 acres and the mule. > If you want to sell and I want to buy, that's > that and the county records it for a nominal clerical fee. >?You will doubtless find similar histories all over the country. Taxes. Nearly everywhere real estate is owned. A non-trivial percentage of the land's sale value in real estate taxes year after year after year. Makes it tough to horde or under-utilize land. When paired with other progressive tax regimes that discourage leasing in favor of leveraged purchases, tends to balance early ownership inequities over time. Even Hawaii's ownership by the Doles, Baldwins and Robinsons is slowly falling to the relentless hammering of taxes. Ready to forge ahead with ownership, the rights of ownership and the great privilege that is property taxes in the IPv4 addressing realm? Be careful what you wish for. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From wavetossed at googlemail.com Sat Aug 14 06:23:02 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Sat, 14 Aug 2010 12:23:02 +0100 Subject: Question of privacy with reassigned resources In-Reply-To: References: <4C58A143.3080709@kenweb.org> <27955157.440.1280877264782.JavaMail.franck@franck-martins-macbook-pro.local> <18E841A3-EA3E-4B9D-9F54-0551B82AAA91@cs.columbia.edu> <61966.1281012596@localhost> <62914.1281014237@localhost> <63659.1281015448@localhost> <5097.1281020435@localhost> Message-ID: > Shall I go on? Regardless of what you may think about whether those > injured folks should be entitled to the information, the fact is that > they are entitled to it under ARIN policy developed based on public > consensus. Which means you injure them by denying it. Enough with the amateur lawyering! A minor inconvenience is NOT injury under the law. And in fact, if the organization is failing to disclose the customer information in order to direct all queries to their own address, where they can be handled by technically competent people, then the judge would laugh you out of court. It is common practice for ISPs to redact whois entries to only include the customer's city and state for the address. This is not fraud and has been going on for years. Every ISP should check their whois entries and make sure that any entries for apartments and people's homes are redacted to say nothing more that PRIVATE RESIDENCE. From bmanning at vacation.karoshi.com Sat Aug 14 06:27:50 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 14 Aug 2010 11:27:50 +0000 Subject: Question of privacy with reassigned resources In-Reply-To: References: <61966.1281012596@localhost> <62914.1281014237@localhost> <63659.1281015448@localhost> <5097.1281020435@localhost> Message-ID: <20100814112750.GA12390@vacation.karoshi.com.> On Sat, Aug 14, 2010 at 12:23:02PM +0100, Michael Dillon wrote: > > Shall I go on? Regardless of what you may think about whether those > > injured folks should be entitled to the information, the fact is that > > they are entitled to it under ARIN policy developed based on public > > consensus. Which means you injure them by denying it. > > Enough with the amateur lawyering! > > A minor inconvenience is NOT injury under the law. Pot, Kettle, Black. Thanks for that legal advice Michael. --bill From patrick at ianai.net Sat Aug 14 08:04:53 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 14 Aug 2010 09:04:53 -0400 Subject: Lightly used IP addresses In-Reply-To: <3029E2EB-EEB3-4E1B-A18F-D385BC99391B@arin.net> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <12C469D4-B9D7-46F9-ADD7-06917F522FBB@arin.net> <3029E2EB-EEB3-4E1B-A18F-D385BC99391B@arin.net> Message-ID: Watching people snark on mailing lists is occasionally entertaining. Watching them snark on the wrong mailing lists is usually less entertaining. Watching them snark on the wrong mailing list for 100+ posts when the things they are snarking about were voted on by themselves is getting a little silly. Watching them snark about the people they are snarking -to- trying to get them to participate in the process they are snarking -about- is pathetic. If you don't like the way ARIN does things, change them. I don't like people going to the IETF and trying to get the IETF to do things the operators should be doing. I talked to the AC & BoD members before I voted, and none of them mentioned this to me. I feel like snarking about that is valid, since I put in time & effort, but was still caught by surprise. But instead of snarking, I'm working to change that. How much time & effort was spent (wasted?) reading mailing lists that could have been used to put forth proposals to ARIN (or the other RIRs)? Which is more likely to get what you want? Oh, and about ARIN wasting money: Do you really think a 10% or even 50% reduction in ARIN fees will make -any- difference to the companies paying those fees? OTOH, I do believe a 50% reduction in ARIN fees will result in far less outreach, which means less community participation, which I feel is suboptimal. If you disagree, propose a change, get me & people who feel as I do outvoted, and things will change. What's more, I will not snark about the fact I got outvoted on NANOG. Or you can post to NANOG and see nothing change. Up to you. -- TTFN, patrick From owen at delong.com Sat Aug 14 10:05:44 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 14 Aug 2010 08:05:44 -0700 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C8F4.5070205@kl.net> Message-ID: <9A0C0575-2B8F-4CF3-8691-BD34669DC383@delong.com> On Aug 13, 2010, at 8:01 PM, Randy Bush wrote: >> Yet most of the bad ideas in the past 15 years have actually come from >> the IETF (TLA's, no end site multihoming, RA religion), some of which >> have actually been "fixed" by the RIR's. > > no, they were fixed within the ietf. that's my blood you are taking > about, and i know where and by whom it was spent. > I'm not sure what is meant by TLAs in this context, so, I'll leave that alone. The lack of end-site multihoming (more specifically the lack of PI for end-sites) was created by the IETF and resolved by the RIRs. The beginning of resolving this was ARIN proposal 2002-3. The RA religion still hasn't been solved. Owen From owen at delong.com Sat Aug 14 10:27:24 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 14 Aug 2010 08:27:24 -0700 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> <20100813200658.GC8181@vacation.karoshi.com> <024484A8-FE17-4B2D-B059-5AAD4F4DC61B@arin.net> <20100813213942.GD8181@vacation.karoshi.com> <20100813220338.GN2582@sizone.org> Message-ID: On Aug 13, 2010, at 9:12 PM, Jeffrey Lyon wrote: > John et al, > > I have read many of your articles about the need to migrate to IPv6 > and how failure to do so will impact business continuity sometime in > the next 1 - 3 years. I've pressed our vendors to support IPv6 (note: > keep in mind we're a DDoS mitigation firm, our needs extend beyond > routers and switches) and found that it's a chicken and egg situation. > Vendors are neglecting to support IPv6 because there is "no demand." > I've pointed out your articles and demanded IPv6 support, some are > promising results in the next several months. We will see. > I was at a trade show several months back. I watched a series of people walk up to a vendor and each, in turn, asked about IPv6 support. The vendor told each, in turn, "You're the only one asking for it." I walked up to the vendor and took my turn being told "You're the only one asking for it." I pointed out that I had seen the other people get the same answer. The sales person admitted he was caught red handed and explained "We're working on it, but, we don't have a definite date and so our marketing department has told us to downplay the demand and the importance until we have something more definitive." > Meanwhile, there are hosting companies, dedicated server companies, > etc. with /17 and /18 allocations who are either forging justification > or wildly abusing the use of that space outside of the declared need. Then those cases should be submitted to the fraud/abuse reporting process so they can be investigated and resolved. Owen From owen at delong.com Sat Aug 14 10:40:28 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 14 Aug 2010 08:40:28 -0700 Subject: Lightly used IP addresses In-Reply-To: <32655709.176.1281760437814.JavaMail.franck@franck-martins-macbook-pro.local> References: <32655709.176.1281760437814.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Aug 13, 2010, at 9:33 PM, Franck Martin wrote: > Funny! > > On one hand people talk about ARIN providing IP allocation at nearly zero cost and on the other hand talking that ARIN goes after companies that use their allocation for abuse (which has a non trivial cost and potential expensive lawsuits)... > > Do you know what you want? Let's clarify the definition of abuse in this context. We are not talking about people who use their IPs to abuse the network. We are talking about resource recipients who use their allocations or assignments in contravention to the policies under which they received them (and thus contrary to the RSA which they signed when they received them). Not that I don't think going after network abuse is worth while, it absolutely is, but, that's not within the current scope of ARIN policy. The community would need to come to consensus on a definition of abuse and the desire for ARIN to take on such a role before it would be possible. For now, ARIN's role is limited to the administration of the address space in the public trust. That includes taking action to resolve situations where addresses are being used in a manner contrary to the ARIN policies developed by the community. Owen From bclark at spectraaccess.com Sat Aug 14 10:47:25 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Sat, 14 Aug 2010 11:47:25 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> <20100813200658.GC8181@vacation.karoshi.com> <024484A8-FE17-4B2D-B059-5AAD4F4DC61B@arin.net> <20100813213942.GD8181@vacation.karoshi.com> <20100813220338.GN2582@sizone.org> Message-ID: <4C66BA8D.5060100@spectraaccess.com> On 08/14/2010 11:27 AM, Owen DeLong wrote: > I was at a trade show several months back. I watched a series of people > walk up to a vendor and each, in turn, asked about IPv6 support. The > vendor told each, in turn, "You're the only one asking for it." > > I walked up to the vendor and took my turn being told "You're the only > one asking for it." I pointed out that I had seen the other people get > the same answer. The sales person admitted he was caught red > handed and explained "We're working on it, but, we don't have a > definite date and so our marketing department has told us to downplay > the demand and the importance until we have something more > definitive." > What company was that? I find it rather odd that any marketing group in any company would tell a sales team to downplay a possible future migration path; especially in the case of IP6 which isn't a possible future migration strategy, but IS a future migration strategy. That's one company I don't want to do business with if that's what they are telling their sales team...shows lack of a road map and a total lack of any understanding of this industry! From bmanning at vacation.karoshi.com Sat Aug 14 10:51:27 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 14 Aug 2010 15:51:27 +0000 Subject: Lightly used IP addresses In-Reply-To: References: <32655709.176.1281760437814.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <20100814155127.GA12447@vacation.karoshi.com.> On Sat, Aug 14, 2010 at 08:40:28AM -0700, Owen DeLong wrote: > > On Aug 13, 2010, at 9:33 PM, Franck Martin wrote: > > > Funny! > > > > On one hand people talk about ARIN providing IP allocation at nearly zero cost and on the other hand talking that ARIN goes after companies that use their allocation for abuse (which has a non trivial cost and potential expensive lawsuits)... > > > > Do you know what you want? > > Let's clarify the definition of abuse in this context. We are not talking about people who use their IPs to abuse the network. We are talking about resource recipients who use their allocations or assignments in contravention to the policies under which they received them (and thus contrary to the RSA which they signed when they received them). > > Owen In the formal ARIN context, there is a distiction between abuse and fraud. abuse:: https://www.arin.net/abuse.html fraud:: https://www.arin.net/resources/fraud/index.html It would be helpful in clarifing the discussion if folks used the proper terminology. --bill From johnl at iecc.com Sat Aug 14 11:22:00 2010 From: johnl at iecc.com (John R. Levine) Date: 14 Aug 2010 12:22:00 -0400 Subject: 600 acres and a mule, was Lightly used IP addresses In-Reply-To: References: <20100814040019.74171.qmail@joyce.lan> Message-ID: > Convincingly said here on an ISP mailing list. But what about the > folks who were denied address assignments by ARIN policies over the > last 15 years? Denied them based on the fiction that ISPs didn't own > IP addresses, that they were merely holding the addresses in trust for > the public they serve. ... I dunno. What was New York's responsibility in the 1790s to guys who didn't join the army because they had to stay home and take care of their widowed mother and six younger sisters? I wouldn't for a moment claim that IPv4 space was a way that was uniformly fair or wise or close to ideal. But I don't think you're going to have much luck imposing fairness and wisdom retroactively on people who've already got the space. R's, John From bill at herrin.us Sat Aug 14 12:21:03 2010 From: bill at herrin.us (William Herrin) Date: Sat, 14 Aug 2010 13:21:03 -0400 Subject: 600 acres and a mule, was Lightly used IP addresses In-Reply-To: References: <20100814040019.74171.qmail@joyce.lan> Message-ID: On Sat, Aug 14, 2010 at 12:22 PM, John R. Levine wrote: > I wouldn't for a moment claim that IPv4 space was a way that was uniformly > fair or wise or close to ideal. ?But I don't think you're going to have much > luck imposing fairness and wisdom retroactively on people who've already got > the space. John. As things stand, IP addresses you've gained control of in the past decade and a half you gained under a contract in which you explicitly agreed that they not only didn't belong to you but that your continued control was subject to the general public's pleasure as expressed through regularly revised ARIN public policy. You won't tear that up like an Indian treaty without first overcoming a certain amount of push back from that disenfranchised public. If you want IPv4 addressing to enter a legal regime similar to real estate, I suggest that among other things you figure out how the taxes should work and write some guidance for the pols before they start figuring it out for themselves. If you don't construct the public policy from the bottom up, you can count on someone else building it from the top down and no newly defined form of property with a quantifiable value is likely to escape taxation. Bear in mind that as with real property, tax regimes which encourage a concentration of ownership by a few wealthy owners will tend to be viewed with suspicion and disdain. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jimi.thompson at gmail.com Sat Aug 14 12:27:14 2010 From: jimi.thompson at gmail.com (Jimi Thompson) Date: Sat, 14 Aug 2010 12:27:14 -0500 Subject: 40 acres and a mule, was Lightly used IP addresses In-Reply-To: Message-ID: It was 40 acres and a mule - FYI On 8/14/10 11:22 AM, "John R. Levine" wrote: >> Convincingly said here on an ISP mailing list. But what about the >> folks who were denied address assignments by ARIN policies over the >> last 15 years? Denied them based on the fiction that ISPs didn't own >> IP addresses, that they were merely holding the addresses in trust for >> the public they serve. ... > > I dunno. What was New York's responsibility in the 1790s to guys who > didn't join the army because they had to stay home and take care of their > widowed mother and six younger sisters? > > I wouldn't for a moment claim that IPv4 space was a way that was uniformly > fair or wise or close to ideal. But I don't think you're going to have > much luck imposing fairness and wisdom retroactively on people who've > already got the space. > > R's, > John > From joelja at bogus.com Sat Aug 14 12:30:04 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 14 Aug 2010 10:30:04 -0700 Subject: Lightly used IP addresses In-Reply-To: <9A0C0575-2B8F-4CF3-8691-BD34669DC383@delong.com> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C8F4.5070205@kl.net> <9A0C0575-2B8F-4CF3-8691-BD34669DC383@delong.com> Message-ID: <7464FE7B-5A98-4657-884C-E5BCB2B391FF@bogus.com> On Aug 14, 2010, at 8:05, Owen DeLong wrote: > On Aug 13, 2010, at 8:01 PM, Randy Bush wrote: > > The lack of end-site multihoming (more specifically the lack of PI for > end-sites) was created by the IETF and resolved by the RIRs. > The beginning of resolving this was ARIN proposal 2002-3. > > The RA religion still hasn't been solved. Neither for that matter has the dhcp religion. Autoconfiguration and bootstrapping were not solved problems for ipv4 inn 1994 and in some respects still aren't. The mind boggles that we consider the ipv4 situation so much better than the v6 case... > Owen > > > From owen at delong.com Sat Aug 14 12:25:57 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 14 Aug 2010 10:25:57 -0700 Subject: Lightly used IP addresses In-Reply-To: <4C66BA8D.5060100@spectraaccess.com> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> <20100813200658.GC8181@vacation.karoshi.com> <024484A8-FE17-4B2D-B059-5AAD4F4DC61B@arin.net> <20100813213942.GD8181@vacation.karoshi.com> <20100813220338.GN2582@sizone.org> <4C66BA8D.5060100@spectraaccess.com> Message-ID: <41B80BBB-0056-4B51-8752-D96706B36D24@delong.com> On Aug 14, 2010, at 8:47 AM, Bret Clark wrote: > On 08/14/2010 11:27 AM, Owen DeLong wrote: >> I was at a trade show several months back. I watched a series of people >> walk up to a vendor and each, in turn, asked about IPv6 support. The >> vendor told each, in turn, "You're the only one asking for it." >> >> I walked up to the vendor and took my turn being told "You're the only >> one asking for it." I pointed out that I had seen the other people get >> the same answer. The sales person admitted he was caught red >> handed and explained "We're working on it, but, we don't have a >> definite date and so our marketing department has told us to downplay >> the demand and the importance until we have something more >> definitive." >> > What company was that? I find it rather odd that any marketing group in any company would tell a sales team to downplay a possible future migration path; especially in the case of IP6 which isn't a possible future migration strategy, but IS a future migration strategy. That's one company I don't want to do business with if that's what they are telling their sales team...shows lack of a road map and a total lack of any understanding of this industry! I won't name names as that company has since changed their tune and there is nothing to be gained by publicly embarrassing them. Owen From scott.brim at gmail.com Sat Aug 14 12:31:18 2010 From: scott.brim at gmail.com (Scott Brim) Date: Sat, 14 Aug 2010 13:31:18 -0400 Subject: 40 acres and a mule, was Lightly used IP addresses In-Reply-To: References: Message-ID: <4C66D2E6.7060508@gmail.com> On 08/14/2010 13:27 EDT, Jimi Thompson wrote: > It was 40 acres and a mule - FYI That was Civil War, for freed slaves. Here in NY, war of independence veterans were given at least 100 acres each. See http://en.wikipedia.org/wiki/Central_New_York_Military_Tract From joelja at bogus.com Sat Aug 14 12:37:58 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 14 Aug 2010 10:37:58 -0700 Subject: 40 acres and a mule, was Lightly used IP addresses In-Reply-To: References: Message-ID: On Aug 14, 2010, at 10:27, Jimi Thompson wrote: > It was 40 acres and a mule - FYI No 40 acres was 1/4 of 1/4 of a section. That's 's Sherman's field order (1865) not the homestead act (which was 160). Or the circa 1790 activity referred to in this thread. Joel's iPad > > > On 8/14/10 11:22 AM, "John R. Levine" wrote: > >>> Convincingly said here on an ISP mailing list. But what about the >>> folks who were denied address assignments by ARIN policies over the >>> last 15 years? Denied them based on the fiction that ISPs didn't own >>> IP addresses, that they were merely holding the addresses in trust for >>> the public they serve. ... >> >> I dunno. What was New York's responsibility in the 1790s to guys who >> didn't join the army because they had to stay home and take care of their >> widowed mother and six younger sisters? >> >> I wouldn't for a moment claim that IPv4 space was a way that was uniformly >> fair or wise or close to ideal. But I don't think you're going to have >> much luck imposing fairness and wisdom retroactively on people who've >> already got the space. >> >> R's, >> John >> > > > From owen at delong.com Sat Aug 14 14:17:43 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 14 Aug 2010 12:17:43 -0700 Subject: Lightly used IP addresses In-Reply-To: <7464FE7B-5A98-4657-884C-E5BCB2B391FF@bogus.com> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C8F4.5070205@kl.net> <9A0C0575-2B8F-4CF3-8691-BD34669DC383@delong.com> <7464FE7B-5A98-4657-884C-E5BCB2B391FF@bogus.com> Message-ID: <2131AC1C-BF6C-457C-8DEB-B2B50CF4E333@delong.com> I think you mistake my meaning. I don't regard RA and SLAAC as a problem. I regard their limited capabilities as a minor issue. I regard the IETF religion that insists on preventing DHCPv6 from having a complete set of capabilities for some form of RA protectionism to be the largest problem. That was my meaning for RA religion. Owen Sent from my iPad On Aug 14, 2010, at 10:30 AM, Joel Jaeggli wrote: > > > On Aug 14, 2010, at 8:05, Owen DeLong wrote: >> On Aug 13, 2010, at 8:01 PM, Randy Bush wrote: >> >> The lack of end-site multihoming (more specifically the lack of PI for >> end-sites) was created by the IETF and resolved by the RIRs. >> The beginning of resolving this was ARIN proposal 2002-3. >> >> The RA religion still hasn't been solved. > > Neither for that matter has the dhcp religion. Autoconfiguration and bootstrapping were not solved problems for ipv4 inn 1994 and in some respects still aren't. The mind boggles that we consider the ipv4 situation so much better than the v6 case... > >> Owen >> >> >> From drc at virtualized.org Sat Aug 14 14:32:50 2010 From: drc at virtualized.org (David Conrad) Date: Sat, 14 Aug 2010 12:32:50 -0700 Subject: Lightly used IP addresses In-Reply-To: <20100814155127.GA12447@vacation.karoshi.com.> References: <32655709.176.1281760437814.JavaMail.franck@franck-martins-macbook-pro.local> <20100814155127.GA12447@vacation.karoshi.com.> Message-ID: Bill, On Aug 14, 2010, at 8:51 AM, bmanning at vacation.karoshi.com wrote: > In the formal ARIN context, there is a distiction between abuse and fraud. > > abuse:: https://www.arin.net/abuse.html This is a FAQ for folks who are accusing ARIN of abuse of network. With the possible exception of the last item in that FQA, it has nothing to do with the topic at hand. > fraud:: https://www.arin.net/resources/fraud/index.html This is the mechanism by which one reports fraud. > It would be helpful in clarifing the discussion if folks used the proper > terminology. Can you point to where ARIN defines exactly what they consider "abuse" and/or "fraud"? Thanks, -drc From bmanning at vacation.karoshi.com Sat Aug 14 15:40:53 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 14 Aug 2010 20:40:53 +0000 Subject: Lightly used IP addresses In-Reply-To: References: <32655709.176.1281760437814.JavaMail.franck@franck-martins-macbook-pro.local> <20100814155127.GA12447@vacation.karoshi.com.> Message-ID: <20100814204053.GB14053@vacation.karoshi.com.> On Sat, Aug 14, 2010 at 12:32:50PM -0700, David Conrad wrote: > Bill, > > On Aug 14, 2010, at 8:51 AM, bmanning at vacation.karoshi.com wrote: > > In the formal ARIN context, there is a distiction between abuse and fraud. > > > > abuse:: https://www.arin.net/abuse.html > > This is a FAQ for folks who are accusing ARIN of abuse of network. With the possible exception of the last item in that FQA, it has nothing to do with the topic at hand. > > > fraud:: https://www.arin.net/resources/fraud/index.html > > This is the mechanism by which one reports fraud. > > > It would be helpful in clarifing the discussion if folks used the proper > > terminology. > > Can you point to where ARIN defines exactly what they consider "abuse" and/or "fraud"? > > Thanks, > -drc The AC accepted draft proposal below has a definition of abuse in #b ---- Draft Policy 2010-11 Required Resource Reviews Version/Date: 20 July 2010 Policy statement: Replace the text "under sections 4-6" in section 12, paragraph 7 with "under paragraphs 12.4 through 12.6" Add to section 12 the following text: 10. Except as provided below, resource reviews are conducted at the discretion of the ARIN staff. In any of the circumstances mentioned below, a resource review must be initiated by ARIN staff: a. Report or discovery of an acquisition, merger, transfer, trade or sale in which the infrastructure and customer base of a network move from one organization to another organization, but, the applicable IP resources are not transferred. In this case, the organization retaining the IP resources must be reviewed. The organization receiving the customers may also be reviewed at the discretion of the ARIN staff. b. Upon receipt by ARIN of one or more credible reports of fraud or abuse of an IP address block. Abuse shall be defined as use of the block in violation of the RSA or other ARIN policies and shall not extend to include general reports of host conduct which are not within ARIN's scope. While fraud is outlined here: https://www.arin.net/resources/fraud/index.html Version 1.2 - 18 November 2009 This reporting process is to be used to notify ARIN of suspected Internet number resource abuse including the submission of falsified utilization or organization information, unauthorized changes to data in ARIN's WHOIS, hijacking of number resources in ARIN's database, or fraudulent transfers. This reporting process is NOT for reporting illegal or fraudulent Internet activity like network abuse, phishing, spam, identity theft, hacking, scams, or any other activity unrelated to the scope of ARIN's mission. ---- so fraud, from ARINs perspective seems to be: - submitting falsified untilization or org info - unauthorized changes to the data in ARINs whois - hijacking number resources in ARINs database - fraudulent transfers a kewpie doll for the first one to point out the circular dependencies! :) --bill From trelane at trelane.net Sat Aug 14 17:28:41 2010 From: trelane at trelane.net (Andrew Kirch) Date: Sat, 14 Aug 2010 18:28:41 -0400 Subject: 40 acres and a mule, was Lightly used IP addresses In-Reply-To: References: Message-ID: <4C671899.9010806@trelane.net> 40 Acres and a Mule were promised to every slave freed in the south by General Grant. It was later rescinded. 600 acres was promised to non-landowning general militia soldiers after the Revolutionary war. You're only off by ~100 years. Andrew On 8/14/2010 1:27 PM, Jimi Thompson wrote: > It was 40 acres and a mule - FYI > > > On 8/14/10 11:22 AM, "John R. Levine" wrote: > >>> Convincingly said here on an ISP mailing list. But what about the >>> folks who were denied address assignments by ARIN policies over the >>> last 15 years? Denied them based on the fiction that ISPs didn't own >>> IP addresses, that they were merely holding the addresses in trust for >>> the public they serve. ... >> I dunno. What was New York's responsibility in the 1790s to guys who >> didn't join the army because they had to stay home and take care of their >> widowed mother and six younger sisters? >> >> I wouldn't for a moment claim that IPv4 space was a way that was uniformly >> fair or wise or close to ideal. But I don't think you're going to have >> much luck imposing fairness and wisdom retroactively on people who've >> already got the space. >> >> R's, >> John >> > > From cgrundemann at gmail.com Sat Aug 14 18:03:59 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Sat, 14 Aug 2010 17:03:59 -0600 Subject: Lightly used IP addresses In-Reply-To: <20100813212544.GJ2582@sizone.org> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> <1ACD377D-B50A-4DB6-8DA4-87B8682D0367@oicr.on.ca> <1A72F43E-CAC8-4B3A-841D-ADA399FCAF98@puck.nether.net> <20100813212544.GJ2582@sizone.org> Message-ID: On Fri, Aug 13, 2010 at 15:25, Ken Chase wrote: > On Fri, Aug 13, 2010 at 05:00:04PM -0400, Jared Mauch said: > ?>I know of several large providers that would stop routing such "rogue" space. > > Really? They'd take a seriously delinquent (and we're only talking about non > payment after several months to Arin, not spammers or other 'criminal' > elements) that's still paying for their transit and cut off their prefix > announcements? I dont know that that's true for most outfits in these tough > times. Nixing a $5000 or $10000+ MRC revenue stream probably requires some > hard thought at high levels in most outfits. First, in this thread we are not talking about folks who have not paid ARIN their dues, we are talking about folks who "sell" addresses despite not being authorized to do so by ARIN - aka abuse/fraud. Either way, if ARIN finds strong enough reason to revoke numbers from Org A who is ISP X' customer, ARIN will eventually reassign those numbers. When ISP Y calls ISP X and says "hey, your customer Org A is advertising my customer Org B's address space." ISP X will check WHOIS, see that they are telling the truth and filter that block from Org A. If ISP X does not, they will likely see peering and transit options shrink rapidly. So in short - yes, really. ~Chris > > /kc > -- > Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA > Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From cgrundemann at gmail.com Sat Aug 14 18:10:56 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Sat, 14 Aug 2010 17:10:56 -0600 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> Message-ID: On Fri, Aug 13, 2010 at 21:32, Randy Bush wrote: > when the 'community' is defined as those policy wannabes who do the > flying, take the cruise junkets, ... this is a self-perpetuating > steaming load that is not gonna change. Yes, those definitions create a steaming load. But why is it that the folks actually participating in making policy are "wannabes" in your definition? I suggest the true definition of "community" includes at least *all* of the non-AC-member participants in the ARIN policy process; the folks who subscribe to the PPML and show up at meetings (or participate remotely at a greatly reduced cost but nearly equal voice). There are 15 AC members and around 150 participants at each meeting... That means that _most_ are *not* being funded by ARIN. For those who claim the system to not be open, I humbly provide myself as a test case. I am not one of the "good old boys" of ARIN (if there is such a thing) and I have never had ARIN pay my way to a meeting (or for a cruise junket). In fact I am far too young and inexperienced to possibly qualify as any kind of ruling elite who is handing down decrees from above. I have however contributed to the formation of several policies in the ARIN region and to the crafting of several others currently under discussion, one on a global level amongst all 5 RIRs. I attended a meeting, joined the mailing list and spoke up. Simple as that. I highly encourage everyone who has an opinion on Internet numbering policy to do the same. Cheers, ~Chris > one start would be for arin to have the guts not to pay travel expenses > of non-employees/contractors. > > randy > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From randy at psg.com Sat Aug 14 20:23:14 2010 From: randy at psg.com (Randy Bush) Date: Sun, 15 Aug 2010 10:23:14 +0900 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> Message-ID: for the embarrassing wannabe example of the month, marla and lee [0] at the last ietf is just such a shining example. at the mic, they state are from the arin ac and board, like it was their day job and they were speaking fo rarin ploicy. and they propose to roll back a decade of progress getting operatonal policy the out of the ietf. and they don't even understand why they got jumped or why thomas's preso was in the opposite direction and was widely supported. the arin ceo's response to my suggestion that this be curtailed? > If you submit it, I will bring it to the Board for consideration. In > fairness, I will tell you that I'll also recommend to the that we > continue to pay for the travel for the Advisory Council, unless and > until there is no need for a policy development process. or ask a grown-up who has the stomach to read the arin ppml list (i could only stomach it so long, and pulled). it is an embarrassment to the internet. randy -- [0] - sweet, well-meaning folk From randy at psg.com Sat Aug 14 20:26:44 2010 From: randy at psg.com (Randy Bush) Date: Sun, 15 Aug 2010 10:26:44 +0900 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> <1ACD377D-B50A-4DB6-8DA4-87B8682D0367@oicr.on.ca> <1A72F43E-CAC8-4B3A-841D-ADA399FCAF98@puck.nether.net> <20100813212544.GJ2582@sizone.org> Message-ID: > First, in this thread we are not talking about folks who have not paid > ARIN their dues, we are talking about folks who "sell" addresses > despite not being authorized to do so by ARIN - aka abuse/fraud. this is less clear-cut than you seem to think it is. but i suspect we will see it in court fairly soon. randy From frnkblk at iname.com Sat Aug 14 21:09:55 2010 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 14 Aug 2010 21:09:55 -0500 Subject: Lightly used IP addresses In-Reply-To: <20100813191256.GW2582@sizone.org> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> <20100813191256.GW2582@sizone.org> Message-ID: A possible stick for ARIN could be that any AS that advertises space for B and any network that uses that rogue AS would not receive resource requests/changes from ARIN. Perhaps too strong of a stick? Frank -----Original Message----- From: Ken Chase [mailto:ken at sizone.org] Sent: Friday, August 13, 2010 2:13 PM To: nanog at nanog.org Subject: Re: Lightly used IP addresses On Fri, Aug 13, 2010 at 06:49:35PM +0000, Nathan Eisenberg said: >> Is this upstream going to cut that customer off and >> lose the revenue, just to satisfy ARIN's bleating? > >Isn't this a little bit like an SSL daemon? One which refuses to process a revocation list on the basis of the function of the certificate is useless. The revocation list only has authority if the agent asks for and processes it. Would you use this SSL daemon, knowing that it had this bug? > >I would consider a transit provider who subverted an ARIN revocation to be disreputable, and seek other sources of transit. Assuming the public even found out about the situation. For ARIN to make good on this community goodwill, they'd have to (1) publish the disrepute of the upstream who refuses to stop announcing the rogue downstream's prefixes. Im not sure what step 2+ is going to be there, but I bet ARIN would become very unpopular with (1) above amongst its customers reselling bandwidth to other ARIN IPv4 block users. How many large carriers on this list would immediately halt announcing a downstream-in-good-financial-standing's prefixes just because ARIN say's they're delinquent? I bet most wont even answer this question to the list here - most likely dont have an official policy for this situation, and if they did, it's likely not going to be publically disclosed. (If any are willing to disclose such publically, I'd love to hear/see the policy's details.) /kc >Best Regards, >Nathan Eisenberg >Atlas Networks, LLC -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From frnkblk at iname.com Sat Aug 14 21:09:59 2010 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 14 Aug 2010 21:09:59 -0500 Subject: Lightly used IP addresses In-Reply-To: <20100813191256.GW2582@sizone.org> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> <20100813191256.GW2582@sizone.org> Message-ID: A possible stick for ARIN could be that any AS that advertises space for B and any network that uses that rogue AS would not receive resource requests/changes from ARIN. Perhaps too strong of a stick? Frank -----Original Message----- From: Ken Chase [mailto:ken at sizone.org] Sent: Friday, August 13, 2010 2:13 PM To: nanog at nanog.org Subject: Re: Lightly used IP addresses On Fri, Aug 13, 2010 at 06:49:35PM +0000, Nathan Eisenberg said: >> Is this upstream going to cut that customer off and >> lose the revenue, just to satisfy ARIN's bleating? > >Isn't this a little bit like an SSL daemon? One which refuses to process a revocation list on the basis of the function of the certificate is useless. The revocation list only has authority if the agent asks for and processes it. Would you use this SSL daemon, knowing that it had this bug? > >I would consider a transit provider who subverted an ARIN revocation to be disreputable, and seek other sources of transit. Assuming the public even found out about the situation. For ARIN to make good on this community goodwill, they'd have to (1) publish the disrepute of the upstream who refuses to stop announcing the rogue downstream's prefixes. Im not sure what step 2+ is going to be there, but I bet ARIN would become very unpopular with (1) above amongst its customers reselling bandwidth to other ARIN IPv4 block users. How many large carriers on this list would immediately halt announcing a downstream-in-good-financial-standing's prefixes just because ARIN say's they're delinquent? I bet most wont even answer this question to the list here - most likely dont have an official policy for this situation, and if they did, it's likely not going to be publically disclosed. (If any are willing to disclose such publically, I'd love to hear/see the policy's details.) /kc >Best Regards, >Nathan Eisenberg >Atlas Networks, LLC -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From frnkblk at iname.com Sat Aug 14 21:34:28 2010 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 14 Aug 2010 21:34:28 -0500 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> <20100813200658.GC8181@vacation.karoshi.com> <024484A8-FE17-4B2D-B059-5AAD4F4DC61B@arin.net> <20100813213942.GD8181@vacation.karoshi.com> <20100813220338.GN2582@sizone.org> Message-ID: This week I was told by my sales person at Red Condor that I'm the only one of his customers that is asking for IPv6. He sounded annoyed and it seemed like he was trying to make me feel bad for being the "only oddball" pushing the IPv6 feature requirement. I tried to explain to him that by this time next year IANA will likely have handed out all their IPv4 blocks and that I didn't have the time spend the first half of 2011 implementing IPv6 across my $DAYJOB network, but wanted to spread that work over time. To his credit, it's been on their to-do list for at least 6 months if not a year, it's just been pushed back several quarters. Frank -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Saturday, August 14, 2010 10:27 AM To: Jeffrey Lyon Cc: John Curran; nanog at nanog.org; Ken Chase Subject: Re: Lightly used IP addresses On Aug 13, 2010, at 9:12 PM, Jeffrey Lyon wrote: > John et al, > > I have read many of your articles about the need to migrate to IPv6 > and how failure to do so will impact business continuity sometime in > the next 1 - 3 years. I've pressed our vendors to support IPv6 (note: > keep in mind we're a DDoS mitigation firm, our needs extend beyond > routers and switches) and found that it's a chicken and egg situation. > Vendors are neglecting to support IPv6 because there is "no demand." > I've pointed out your articles and demanded IPv6 support, some are > promising results in the next several months. We will see. > I was at a trade show several months back. I watched a series of people walk up to a vendor and each, in turn, asked about IPv6 support. The vendor told each, in turn, "You're the only one asking for it." I walked up to the vendor and took my turn being told "You're the only one asking for it." I pointed out that I had seen the other people get the same answer. The sales person admitted he was caught red handed and explained "We're working on it, but, we don't have a definite date and so our marketing department has told us to downplay the demand and the importance until we have something more definitive." Owen From randy at psg.com Sat Aug 14 21:37:11 2010 From: randy at psg.com (Randy Bush) Date: Sun, 15 Aug 2010 11:37:11 +0900 Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> <20100813191256.GW2582@sizone.org> Message-ID: > A possible stick for ARIN could be that any AS that advertises space > for B and any network that uses that rogue AS would not receive > resource requests/changes from ARIN. Perhaps too strong of a stick? maybe you should not be searching for a stick. From jeffrey.lyon at blacklotus.net Sat Aug 14 21:46:56 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sun, 15 Aug 2010 07:16:56 +0430 Subject: 40 x /18's and an ASN - was Re: Lightly used IP addresses Message-ID: The vendor I referred to earlier that does not support IPv6 explained this in a private meeting, not a sales pitch. We already use their products extensively. The discussion was more to the tune of "we developed IPv6 support but stopped including it in the firmware releases because no one was using it." I informed them that we would use it so possibly by EOY we can have IPv6 support (note: I don't know if Telia and BandCon even support IPv6 yet? Yet another hurdle.) Jeff On Sun, Aug 15, 2010 at 7:04 AM, Frank Bulk wrote: > This week I was told by my sales person at Red Condor that I'm the only one > of his customers that is asking for IPv6. ?He sounded annoyed and it seemed > like he was trying to make me feel bad for being the "only oddball" pushing > the IPv6 feature requirement. ?I tried to explain to him that by this time > next year IANA will likely have handed out all their IPv4 blocks and that I > didn't have the time spend the first half of 2011 implementing IPv6 across > my $DAYJOB network, but wanted to spread that work over time. ?To his > credit, it's been on their to-do list for at least 6 months if not a year, > it's just been pushed back several quarters. > > Frank > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Saturday, August 14, 2010 10:27 AM > To: Jeffrey Lyon > Cc: John Curran; nanog at nanog.org; Ken Chase > Subject: Re: Lightly used IP addresses > > > On Aug 13, 2010, at 9:12 PM, Jeffrey Lyon wrote: > >> John et al, >> >> I have read many of your articles about the need to migrate to IPv6 >> and how failure to do so will impact business continuity sometime in >> the next 1 - 3 years. I've pressed our vendors to support IPv6 (note: >> keep in mind we're a DDoS mitigation firm, our needs extend beyond >> routers and switches) and found that it's a chicken and egg situation. >> Vendors are neglecting to support IPv6 because there is "no demand." >> I've pointed out your articles and demanded IPv6 support, some are >> promising results in the next several months. We will see. >> > I was at a trade show several months back. I watched a series of people > walk up to a vendor and each, in turn, asked about IPv6 support. The > vendor told each, in turn, "You're the only one asking for it." > > I walked up to the vendor and took my turn being told "You're the only > one asking for it." I pointed out that I had seen the other people get > the same answer. The sales person admitted he was caught red > handed and explained "We're working on it, but, we don't have a > definite date and so our marketing department has told us to downplay > the demand and the importance until we have something more > definitive." > > > > Owen > > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From patrick at zill.net Sat Aug 14 22:30:37 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Sat, 14 Aug 2010 23:30:37 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> Message-ID: <4C675F5D.6070408@zill.net> Randy Bush wrote: >> >> John - you do not get it... > > > > vadim, i assure you curran gets it. he has been around as long as you > > and i. the problem is that he has become a fiduciary of an organization > > which sees its survival and growth as its principal goal, free business > > class travel for wannabe policy wonks as secondary, and and the well- > > being of the internet as tertiary. they're just another itu, except the > > clothing expenses are lower and the decision making process pretends to > > be more open, but isn't. > > Question: Why does it cost $11 million or more per year (going to some $22 million per year after 2013) to run a couple of databases that are Internet-accessible? --Patrick From jcurran at arin.net Sat Aug 14 23:23:42 2010 From: jcurran at arin.net (John Curran) Date: Sun, 15 Aug 2010 00:23:42 -0400 Subject: Lightly used IP addresses In-Reply-To: <4C675F5D.6070408@zill.net> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> Message-ID: On Aug 14, 2010, at 11:30 PM, Patrick Giagnocavo wrote: > > Question: Why does it cost $11 million or more per year (going to some > $22 million per year after 2013) to run a couple of databases that are > Internet-accessible? Patrick - If this is a reference to ARIN, the budget is approximately $15M annually, and is not substantially changing any faster than expected for normal cost-of-living trends (If $22M is a reference to having both IPv4 and IPv6 fees, ARIN charges each organization only once for the larger of IPv4 or IPv6 registration services fee it makes use of) Even so, it's a fair question to ask why it costs $15M annual to run ARIN. That includes the costs for many tasks which might not be obvious, including running the legacy registry system (which handles SWIP email templates), the new ARIN Online system (which is quite a bit more elegant), the public WHOIS servers, bulk WHOIS and FTP services, IN-ADDR services, the public web sites, the polling & election systems, the billing/invoicing systems, and the staging, development/QA support for same, and the normal office infrastructure for things like email, mailing lists, replication, business record keeping, and archival. There's some engineering staff to keep all that running, registration services staff to handle incoming requests, member services for running the meetings, elections, and policy process, and outreach thats already been mentioned with respect to trade shows and press, but also includes engagement with our friends at the ITU, international bodies, and governments. The full budget is available in each year's annual report along with the audited financials, and can be found here: https://www.arin.net/about_us/corp_docs/annual_rprt.html Clearly, the budget can be increased or decreased based on the services desired by the community, and this typically discussed on the last day of the ARIN Public Policy & Member meeting (twice yearly) during the Financial Services report. In between meetings, this topic is probably best suited for the arin-discuss mailing list as opposed to the nanog list. FYI, /John John Curran President and CEO ARIN From Valdis.Kletnieks at vt.edu Sat Aug 14 23:24:16 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 15 Aug 2010 00:24:16 -0400 Subject: Lightly used IP addresses In-Reply-To: Your message of "Sat, 14 Aug 2010 17:03:59 MDT." References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> <1ACD377D-B50A-4DB6-8DA4-87B8682D0367@oicr.on.ca> <1A72F43E-CAC8-4B3A-841D-ADA399FCAF98@puck.nether.net> <20100813212544.GJ2582@sizone.org> Message-ID: <11434.1281846256@localhost> On Sat, 14 Aug 2010 17:03:59 MDT, Chris Grundemann said: > First, in this thread we are not talking about folks who have not paid > ARIN their dues, we are talking about folks who "sell" addresses > despite not being authorized to do so by ARIN - aka abuse/fraud. Psst.. Hey.. buddy. Over here... wanna score some gen-yoo-ine Rolex integers, cheap? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dougb at dougbarton.us Sat Aug 14 23:32:49 2010 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 14 Aug 2010 21:32:49 -0700 Subject: Lightly used IP addresses In-Reply-To: <11434.1281846256@localhost> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> <1ACD377D-B50A-4DB6-8DA4-87B8682D0367@oicr.on.ca> <1A72F43E-CAC8-4B3A-841D-ADA399FCAF98@puck.nether.net> <20100813212544.GJ2582@sizone.org> <11434.1281846256@localhost> Message-ID: <4C676DF1.9080205@dougbarton.us> On 08/14/2010 21:24, Valdis.Kletnieks at vt.edu wrote: > On Sat, 14 Aug 2010 17:03:59 MDT, Chris Grundemann said: >> First, in this thread we are not talking about folks who have not paid >> ARIN their dues, we are talking about folks who "sell" addresses >> despite not being authorized to do so by ARIN - aka abuse/fraud. > > Psst.. Hey.. buddy. Over here... wanna score some gen-yoo-ine Rolex integers, cheap? ... only if they're prime. -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From drc at virtualized.org Sun Aug 15 00:20:00 2010 From: drc at virtualized.org (David Conrad) Date: Sat, 14 Aug 2010 22:20:00 -0700 Subject: Lightly used IP addresses In-Reply-To: References: <32655709.176.1281760437814.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <0C9CEA66-35B4-4786-B752-1AD168A767F0@virtualized.org> Owen, On Aug 14, 2010, at 8:40 AM, Owen DeLong wrote: > Let's clarify the definition of abuse in this context. We are not talking about people who use their IPs to abuse the network. We are talking about resource recipients who use their allocations or assignments in contravention to the policies under which they received them (and thus contrary to the RSA which they signed when they received them). The challenge ARIN (and to a lesser extent, the other RIRs) faces is that in a very short time, we're going to have a system in which there will be folks barred from entering a market because they signed an RSA while at the same time, there will be others who will act without this restriction. I honestly don't see how this system will be stable and instability breeds all sorts of things (some perhaps positive, most probably negative). When resources were plentiful this dichotomy could be mostly ignored. Resources are soon not to be plentiful. It has been depressing to watch participants in ARIN (in particular) suggest all will be well if people would just sign away their rights via an LRSA, move to IPv6 overnight, abide by increasingly Byzantine rules, accept that folks were always under ARIN's policies and they just didn't know it, etc. Pragmatically speaking, it seems the most likely to be successful way of maintaining stability with the impending resource exhaustion state is to give up pretenses of being a regulatory agency and concentrate on the role of being a titles registry. I figure if the existing RIRs don't do it, someone else will. But perhaps I'm missing something since I too gave up on PPML some time back. Regards, -drc From swmike at swm.pp.se Sun Aug 15 01:38:07 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 15 Aug 2010 08:38:07 +0200 (CEST) Subject: participation in process (Re: Lightly used IP addresses) In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> Message-ID: On Sat, 14 Aug 2010, Chris Grundemann wrote: > I highly encourage everyone who has an opinion on Internet numbering > policy to do the same. The same goes for IETF and standards, there one doesn't have to go to meetings at all since most work is being done on/via mailing lists openly. -- Mikael Abrahamsson email: swmike at swm.pp.se From cgrundemann at gmail.com Sun Aug 15 01:42:02 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Sun, 15 Aug 2010 00:42:02 -0600 Subject: Lightly used IP addresses In-Reply-To: <11434.1281846256@localhost> References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813183143.GV2582@sizone.org> <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> <1ACD377D-B50A-4DB6-8DA4-87B8682D0367@oicr.on.ca> <1A72F43E-CAC8-4B3A-841D-ADA399FCAF98@puck.nether.net> <20100813212544.GJ2582@sizone.org> <11434.1281846256@localhost> Message-ID: On Sat, Aug 14, 2010 at 22:24, wrote: > Psst.. Hey.. buddy. Over here... wanna score some gen-yoo-ine Rolex integers, cheap? Right, because there is no reason to care about the uniqueness of integers used on the Internet... :/ ~Chris From jcurran at arin.net Sun Aug 15 04:53:58 2010 From: jcurran at arin.net (John Curran) Date: Sun, 15 Aug 2010 05:53:58 -0400 Subject: Lightly used IP addresses In-Reply-To: <0C9CEA66-35B4-4786-B752-1AD168A767F0@virtualized.org> References: <32655709.176.1281760437814.JavaMail.franck@franck-martins-macbook-pro.local> <0C9CEA66-35B4-4786-B752-1AD168A767F0@virtualized.org> Message-ID: On Aug 15, 2010, at 1:20 AM, David Conrad wrote: > It has been depressing to watch participants in ARIN (in particular) suggest all will be well if people would just sign away their rights via an LRSA, > ... Actually, you've got it backwards. The Legacy RSA provides specific contractual rights which take precedence over present policy or any policy that might be made which would otherwise limit such rights: "In the event of any inconsistency between the Policies and this Legacy Agreement, the terms of this Legacy Agreement will prevail, including but not limited to those Policies adopted after this Legacy Agreement is executed." Without signing an LRSA, it's just status quo, which is also seems to fine option at present for those who like things they way they are. The specific LRSA right that most folks are interested in include: "ARIN will take no action to reduce the services provided for Included Number Resources that are not currently being utilized by the Legacy Applicant.", and additional the $100 annual fee, and with an annual cap on any increases. The Legacy RSA is a voluntary way for legacy block holders to have certainty regarding the registry services including WHOIS, in-addr, etc. It's entirely voluntary, for those who prefer to have contractual rights for an otherwise uncertain situation. > Pragmatically speaking, it seems the most likely to be successful way of maintaining stability with the impending resource exhaustion state is to give up pretenses of being regulatory agency and concentrate on the role of being a titles registry. Focusing on becoming a title registry is easily done if the community adopts policy to such effect, but it is an exercise to reader whether that increases or decreases stability depending on the exact policies. The specified transfer policy that developed by the community allows those who needs addresses to receive them from anyone holding them, and keeps ARIN out of the financials of the transaction and focused on recording it. Yes, we do require that the resources first be under RSA/LRSA, because we research each legacy block through that process to make sure we're not otherwise recording a hijacked address block as valid. Pragmatically speaking, I would note that such validation is nearly the textbook role for a "title" registry, and attempts to record transfers without first doing the historical scrub will nearly guarantee instability. (Followups for this really should be to PPML.) /John John Curran President and CEO ARIN From randy at psg.com Sun Aug 15 05:06:52 2010 From: randy at psg.com (Randy Bush) Date: Sun, 15 Aug 2010 19:06:52 +0900 Subject: Lightly used IP addresses In-Reply-To: References: <32655709.176.1281760437814.JavaMail.franck@franck-martins-macbook-pro.local> <0C9CEA66-35B4-4786-B752-1AD168A767F0@virtualized.org> Message-ID: > Actually, you've got it backwards. The Legacy RSA provides specific > contractual rights which take precedence over present policy or any > policy that might be made which would otherwise limit such rights: gosh, i must have completely misread section nine as we say in our family, i smell cows. randy From jcurran at istaff.org Sun Aug 15 05:16:47 2010 From: jcurran at istaff.org (John Curran) Date: Sun, 15 Aug 2010 06:16:47 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <32655709.176.1281760437814.JavaMail.franck@franck-martins-macbook-pro.local> <0C9CEA66-35B4-4786-B752-1AD168A767F0@virtualized.org> Message-ID: <41C542CB-ABA5-4BBF-90EC-798F3BFCE89E@istaff.org> On Aug 15, 2010, at 6:06 AM, Randy Bush wrote: > >> Actually, you've got it backwards. The Legacy RSA provides specific >> contractual rights which take precedence over present policy or any >> policy that might be made which would otherwise limit such rights: > > gosh, i must have completely misread section nine Seeking contractual rights contrary to IETF RFCs 2008 and 2150? > as we say in our family, i smell cows. No comment. /John From randy at psg.com Sun Aug 15 05:18:12 2010 From: randy at psg.com (Randy Bush) Date: Sun, 15 Aug 2010 19:18:12 +0900 Subject: Lightly used IP addresses In-Reply-To: <41C542CB-ABA5-4BBF-90EC-798F3BFCE89E@istaff.org> References: <32655709.176.1281760437814.JavaMail.franck@franck-martins-macbook-pro.local> <0C9CEA66-35B4-4786-B752-1AD168A767F0@virtualized.org> <41C542CB-ABA5-4BBF-90EC-798F3BFCE89E@istaff.org> Message-ID: >> gosh, i must have completely misread section nine > Seeking contractual rights contrary to IETF RFCs 2008 and 2150? legacy space predates those, and they are not contracts. randy From randy at psg.com Sun Aug 15 05:21:50 2010 From: randy at psg.com (Randy Bush) Date: Sun, 15 Aug 2010 19:21:50 +0900 Subject: Lightly used IP addresses In-Reply-To: <41C542CB-ABA5-4BBF-90EC-798F3BFCE89E@istaff.org> References: <32655709.176.1281760437814.JavaMail.franck@franck-martins-macbook-pro.local> <0C9CEA66-35B4-4786-B752-1AD168A767F0@virtualized.org> <41C542CB-ABA5-4BBF-90EC-798F3BFCE89E@istaff.org> Message-ID: >> gosh, i must have completely misread section nine > Seeking contractual rights contrary to IETF RFCs 2008 and 2150? oh, and if you feel that you have those rights by other means than the lrsa, then why is section nine in the lrsa. just remove it. and then maybe more than a few percent of the legacy holders might actually be interested. your lawyer is gonna kill you. randy From jcurran at arin.net Sun Aug 15 05:49:12 2010 From: jcurran at arin.net (John Curran) Date: Sun, 15 Aug 2010 06:49:12 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <32655709.176.1281760437814.JavaMail.franck@franck-martins-macbook-pro.local> <0C9CEA66-35B4-4786-B752-1AD168A767F0@virtualized.org> <41C542CB-ABA5-4BBF-90EC-798F3BFCE89E@istaff.org> Message-ID: <59CA4D8B-93EC-433F-BBE0-1743BC2E2830@arin.net> On Aug 15, 2010, at 6:21 AM, Randy Bush wrote: > >>> gosh, i must have completely misread section nine >> Seeking contractual rights contrary to IETF RFCs 2008 and 2150? > > oh, and if you feel that you have those rights by other means than the > lrsa, then why is section nine in the lrsa. just remove it. Easy to do, you can either: 1) Change the appropriate policy language (NRPM 6.4.1) via the ARIN policy development process, in which case the LRSA will be updated as noted, or 2) If you feel that you'd prefer a different forum, you can address this on a more global basis (since each RIR has similar language regarding addresses) by going through the IETF and revising the RFCs, which will likely result in the RIRs all reviewing their documents accordingly. Either route requires that the community comes to a consensus on the change and can give you the results you seek. Or you can enjoy the status quo. /John John Curran President and CEO ARIN p.s. If you want to continue to discuss, can we shortly move this to PPML or ARIN-Discuss for the sake of those not interested in these matters who have different expectations from their NANOG list subscription? From randy at psg.com Sun Aug 15 06:28:25 2010 From: randy at psg.com (Randy Bush) Date: Sun, 15 Aug 2010 20:28:25 +0900 Subject: Lightly used IP addresses In-Reply-To: <59CA4D8B-93EC-433F-BBE0-1743BC2E2830@arin.net> References: <32655709.176.1281760437814.JavaMail.franck@franck-martins-macbook-pro.local> <0C9CEA66-35B4-4786-B752-1AD168A767F0@virtualized.org> <41C542CB-ABA5-4BBF-90EC-798F3BFCE89E@istaff.org> <59CA4D8B-93EC-433F-BBE0-1743BC2E2830@arin.net> Message-ID: >>>> gosh, i must have completely misread section nine >>> Seeking contractual rights contrary to IETF RFCs 2008 and 2150? >> oh, and if you feel that you have those rights by other means than the >> lrsa, then why is section nine in the lrsa. just remove it. > Easy to do, you can either: > 1) Change the appropriate policy language (NRPM 6.4.1) via the ARIN policy > development process, in which case the LRSA will be updated as noted, or > 2) If you feel that you'd prefer a different forum, you can address this on a > more global basis (since each RIR has similar language regarding addresses) > by going through the IETF and revising the RFCs, which will likely result > in the RIRs all reviewing their documents accordingly. oh. was section nine of the lrsa done by the policy process? please stop using the community consensus meme to cover for what you, your lawyer, and your board came up with in a back room. > p.s. If you want to continue to discuss, can we shortly move this to > PPML no thanks. randy From randy at psg.com Sun Aug 15 06:34:19 2010 From: randy at psg.com (Randy Bush) Date: Sun, 15 Aug 2010 20:34:19 +0900 Subject: Lightly used IP addresses In-Reply-To: References: <32655709.176.1281760437814.JavaMail.franck@franck-martins-macbook-pro.local> <0C9CEA66-35B4-4786-B752-1AD168A767F0@virtualized.org> <41C542CB-ABA5-4BBF-90EC-798F3BFCE89E@istaff.org> <59CA4D8B-93EC-433F-BBE0-1743BC2E2830@arin.net> Message-ID: and, may i remind you, that the actual point was > On Aug 15, 2010, at 1:20 AM, David Conrad wrote: >> It has been depressing to watch participants in ARIN (in particular) >> suggest all will be well if people would just sign away their rights >> via an LRSA, > Actually, you've got it backwards. The Legacy RSA provides specific > contractual rights which take precedence over present policy or any > policy that might be made which would otherwise limit such rights: and when i pointed out section nine, you dove for the red herrings. the fact is that the lrsa does require the legacy holder to sign away rights. and if you assert that they have no special/different rights, then why is that clause there? randy From jcurran at arin.net Sun Aug 15 07:36:10 2010 From: jcurran at arin.net (John Curran) Date: Sun, 15 Aug 2010 08:36:10 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <32655709.176.1281760437814.JavaMail.franck@franck-martins-macbook-pro.local> <0C9CEA66-35B4-4786-B752-1AD168A767F0@virtualized.org> <41C542CB-ABA5-4BBF-90EC-798F3BFCE89E@istaff.org> <59CA4D8B-93EC-433F-BBE0-1743BC2E2830@arin.net> Message-ID: <476EA2D1-2ED9-4B5B-AE0E-C2C2F3629592@arin.net> On Aug 15, 2010, at 7:28 AM, Randy Bush wrote: > oh. was section nine of the lrsa done by the policy process? No, although it's been presented at multiple Public Policy and Member meetings, and has enjoying extensive discussion on the mailing lists. (It's been extensively revised based on the feedback received - see http://www.mail-archive.com/arin-announce at arin.net/msg00105.html) (later followup from Randy - consolidated response) > the fact is that the lrsa does require the legacy holder to sign away > rights. and if you assert that they have no special/different rights, > then why is that clause there? Section 9 is present in the LRSA because it matches the RSA (so that all address holders are the same basic terms to the extent practical) As noted earlier, the LRSA provides specific contractual rights including precluding ARIN from reducing the services provided for legacy address space, but a legacy holder trying to theorize property rights is working under a set of assumptions likely incompatible with ARIN's mission and articles of incorporation that call for actual management and stewardship of Internet number resources. As noted, the other RIRs have similar language, as do the IETF BCP RFCs in this space. The earlier you go back, the clearer intent of the community on this point, as were Jon's actions as the IANA. While this may not be convenient for folks today who wish otherwise, it does not change reality. I've suggested the RIR processes or the IETF as a way of bringing about the change you want based on community consensus (this is the Internet style of addressing it); feel free to add your choice of multinational organizations or governments if you want to more choices with different decision processes. /John John Curran President and CEO ARIN >> p.s. If you want to continue to discuss, can we shortly move this to PPML > > no thanks. p.p.s. My apologies to the list (for my having to respond to direct queries and thus continue the thread here) From randy at psg.com Sun Aug 15 07:54:10 2010 From: randy at psg.com (Randy Bush) Date: Sun, 15 Aug 2010 21:54:10 +0900 Subject: Lightly used IP addresses In-Reply-To: <476EA2D1-2ED9-4B5B-AE0E-C2C2F3629592@arin.net> References: <32655709.176.1281760437814.JavaMail.franck@franck-martins-macbook-pro.local> <0C9CEA66-35B4-4786-B752-1AD168A767F0@virtualized.org> <41C542CB-ABA5-4BBF-90EC-798F3BFCE89E@istaff.org> <59CA4D8B-93EC-433F-BBE0-1743BC2E2830@arin.net> <476EA2D1-2ED9-4B5B-AE0E-C2C2F3629592@arin.net> Message-ID: >> oh. was section nine of the lrsa done by the policy process? > No so, if we think it should be changed we should go through a process which was not used to put it in place. can you even say "level playing field?" > Section 9 is present in the LRSA because it matches the RSA (so that > all address holders are the same basic terms to the extent practical) so, on the one hand, you claim legacy holders have no property rights. yet you ask they sign an lrsa wherein they relinquish the rights you say they don't have. amazing. i wonder if that could be construed as an acknowledgement that they actually have those rights. when did the lawyers and the twisty mentality get control? randy, heading for sleep -- p.s. apologies to folk for any suggestion they might have to dirty themselves by joining the ppml list From bill at herrin.us Sun Aug 15 10:14:08 2010 From: bill at herrin.us (William Herrin) Date: Sun, 15 Aug 2010 11:14:08 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> Message-ID: On Sun, Aug 15, 2010 at 12:23 AM, John Curran wrote: > https://www.arin.net/about_us/corp_docs/annual_rprt.html >?In > between meetings, this topic is probably best suited for the arin-discuss mailing > list as opposed to the nanog list. John, Is arin-discuss still a closed members-only list? I pay ARIN every year for my AS# registration but the last time I asked to join arin-discuss, I was refused because I wasn't a LIR, thus not a member. Please: don't ask folks to take discussions of public concern to a closed forum. On Sun, Aug 15, 2010 at 5:53 AM, John Curran wrote: > On Aug 15, 2010, at 1:20 AM, David Conrad wrote: >> It has been depressing to watch participants in ARIN >> (in particular) suggest all will be well if people would just >> sign away their rights via an LRSA, > > Actually, you've got it backwards. The Legacy RSA provides specific > contractual rights which take precedence over present policy or any > policy that might be made which would otherwise limit such rights: A strict (albeit ridiculous) reading of the LRSA says that if I bit-torrent some music using my LRSA-covered IP addresses and lose in court (4.d.ii) ARIN can terminate the contract (14.b.i) and revoke the numbers (14.e.i). In fact, any way I run afoul of ARIN's ever changing policies (15.d) leads to 14.b and 14.e.1. Not that ARIN would, of course, but the contract gives them the power. https://www.arin.net/resources/agreements/legacy_rsa.pdf Absent the LRSA, the status quo leaves ARIN unable to revoke and reassign legacy IP addresses without placing itself at major risk, requiring a litigious rather than contractual resolution to exactly what rights ARIN and the legacy registrants have. My defacto rights are less certain but rather more extensive than what the LRSA offers. On Sun, Aug 15, 2010 at 7:34 AM, Randy Bush wrote: > the fact is that the lrsa does require the legacy holder to sign away > rights. and if you assert that they have no special/different rights, > then why is [section 9] there? Because that's intended to be part of the price, Randy. In exchange for gaining enforceable rights with respect to ARIN's provision of services, you quit any claim to your legacy addresses as property, just like with all the addresses allocated in the last decade and a half. The other part of the price was supposed to be the $100 annual fee. Unfortunately, the LRSA contains another price which I personally consider too high: voluntary termination revokes the IP addresses instead of restoring the pre-contract status quo. Without that balancing check to the contract, I think a steady creep in what ARIN requires of the signatory is inevitable... and the affirmative actions ARIN can require the registrant to perform in order to maintain the contract are nearly unlimited. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Sun Aug 15 10:23:33 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 15 Aug 2010 11:23:33 -0400 Subject: participation in process (Re: Lightly used IP addresses) In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> Message-ID: Sent from my iPad On Aug 15, 2010, at 2:38 AM, Mikael Abrahamsson wrote: > On Sat, 14 Aug 2010, Chris Grundemann wrote: > >> I highly encourage everyone who has an opinion on Internet numbering policy to do the same. > > The same goes for IETF and standards, there one doesn't have to go to meetings at all since most work is being done on/via mailing lists openly. > Most of the policy work in ARIN is done openly on PPML. However, the meetings (which can be attended remotely) are also quite useful, much as with IETF. Owen From owen at delong.com Sun Aug 15 10:33:34 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 15 Aug 2010 11:33:34 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <32655709.176.1281760437814.JavaMail.franck@franck-martins-macbook-pro.local> <0C9CEA66-35B4-4786-B752-1AD168A767F0@virtualized.org> <41C542CB-ABA5-4BBF-90EC-798F3BFCE89E@istaff.org> <59CA4D8B-93EC-433F-BBE0-1743BC2E2830@arin.net> <476EA2D1-2ED9-4B5B-AE0E-C2C2F3629592@arin.net> Message-ID: Sent from my iPad On Aug 15, 2010, at 8:54 AM, Randy Bush wrote: >>> oh. was section nine of the lrsa done by the policy process? >> No > > so, if we think it should be changed we should go through a process > which was not used to put it in place. can you even say "level playing > field?" > >> Section 9 is present in the LRSA because it matches the RSA (so that >> all address holders are the same basic terms to the extent practical) > > so, on the one hand, you claim legacy holders have no property rights. > yet you ask they sign an lrsa wherein they relinquish the rights you say > they don't have. > A contract which clarifies that you still don't have rights you never had does not constitute relinquishing those non-existent rights no matter how many times you repeat yourself. > amazing. i wonder if that could be construed as an acknowledgement that > they actually have those rights. > > when did the lawyers and the twisty mentality get control? > > randy, heading for sleep > > -- > > p.s. apologies to folk for any suggestion they might have to dirty > themselves by joining the ppml list From owen at delong.com Sun Aug 15 10:44:18 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 15 Aug 2010 11:44:18 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> Message-ID: <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> Sent from my iPad On Aug 15, 2010, at 11:14 AM, William Herrin wrote: > On Sun, Aug 15, 2010 at 12:23 AM, John Curran wrote: >> https://www.arin.net/about_us/corp_docs/annual_rprt.html >> In >> between meetings, this topic is probably best suited for the arin-discuss mailing >> list as opposed to the nanog list. > > John, > > Is arin-discuss still a closed members-only list? I pay ARIN every > year for my AS# registration but the last time I asked to join > arin-discuss, I was refused because I wasn't a LIR, thus not a member. > > Please: don't ask folks to take discussions of public concern to a closed forum. > > ARIN fees and budget are a member concern, not a public concern. Non-LIR resource holders can become members for $500 per year. > On Sun, Aug 15, 2010 at 5:53 AM, John Curran wrote: >> On Aug 15, 2010, at 1:20 AM, David Conrad wrote: >>> It has been depressing to watch participants in ARIN >>> (in particular) suggest all will be well if people would just >>> sign away their rights via an LRSA, >> >> Actually, you've got it backwards. The Legacy RSA provides specific >> contractual rights which take precedence over present policy or any >> policy that might be made which would otherwise limit such rights: > > A strict (albeit ridiculous) reading of the LRSA says that if I > bit-torrent some music using my LRSA-covered IP addresses and lose in > court (4.d.ii) ARIN can terminate the contract (14.b.i) and revoke the > numbers (14.e.i). In fact, any way I run afoul of ARIN's ever changing > policies (15.d) leads to 14.b and 14.e.1. Not that ARIN would, of > course, but the contract gives them the power. > > https://www.arin.net/resources/agreements/legacy_rsa.pdf > > Absent the LRSA, the status quo leaves ARIN unable to revoke and > reassign legacy IP addresses without placing itself at major risk, > requiring a litigious rather than contractual resolution to exactly > what rights ARIN and the legacy registrants have. My defacto rights > are less certain but rather more extensive than what the LRSA offers. > You and Randy operate from the assumption that these less certain rights somehow exist at all. I believe them to be fictitious in nature and contrary to the intent of number stewardship all the way back to Postel's original notebook. Postel himself is on record stating that disused addresses should be returned. > > On Sun, Aug 15, 2010 at 7:34 AM, Randy Bush wrote: >> the fact is that the lrsa does require the legacy holder to sign away >> rights. and if you assert that they have no special/different rights, >> then why is [section 9] there? > > Because that's intended to be part of the price, Randy. In exchange > for gaining enforceable rights with respect to ARIN's provision of > services, you quit any claim to your legacy addresses as property, > just like with all the addresses allocated in the last decade and a > half. The other part of the price was supposed to be the $100 annual > fee. > I would say you acknowledge the lack of such a claim in the first place rather than quit claim. Thus you are not giving up anything and the only actual price is $100 per year with very limited possible increases over future years. > Unfortunately, the LRSA contains another price which I personally > consider too high: voluntary termination revokes the IP addresses > instead of restoring the pre-contract status quo. Without that > balancing check to the contract, I think a steady creep in what ARIN > requires of the signatory is inevitable... and the affirmative actions > ARIN can require the registrant to perform in order to maintain the > contract are nearly unlimited. > I believe the LRSA limits them primarily to the annual fee payment. It's actually written to make it pretty hard, if not impossible, for policy changes to affect signatories in such a way. Arguably, non-signatories have exactly the same set of rights as RSA signatories, while LRSA signatories enjoy significant additional rights. Any belief that non-signatories enjoy rights not present in the RSA is speculative at best. Owen > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From fw at deneb.enyo.de Sun Aug 15 11:14:41 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 15 Aug 2010 18:14:41 +0200 Subject: BCP38 exceptions for RFC1918 space Message-ID: <87vd7bg8em.fsf@mid.deneb.enyo.de> What's the current consensus on exempting private network space from source address validation? Is it recommended? Discouraged? (One argument in favor of exceptions is that it makes PMTUD work if transfer networks use private address space.) From bill at herrin.us Sun Aug 15 11:20:26 2010 From: bill at herrin.us (William Herrin) Date: Sun, 15 Aug 2010 12:20:26 -0400 Subject: Lightly used IP addresses In-Reply-To: <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> Message-ID: On Sun, Aug 15, 2010 at 11:44 AM, Owen DeLong wrote: > ARIN fees and budget are a member concern, not a public concern. Oh really? The money ARIN spends managing the public's IP addresses (and how it collects that money and the privileges conferred on the folks from whom it's collected) are not a matter of public concern? I seem to recall that attitude was how ICANN first started to get in to trouble. >> Unfortunately, the LRSA contains another price which I personally >> consider too high: voluntary termination revokes the IP addresses >> instead of restoring the pre-contract status quo. Without that >> balancing check to the contract, I think a steady creep in what ARIN >> requires of the signatory is inevitable... and the affirmative actions >> ARIN can require the registrant to perform in order to maintain the >> contract are nearly unlimited. >> > I believe the LRSA limits them primarily to the annual fee payment. Do you now. Unfortunately, the plain language of the LRSA does not respect your belief. ARIN makes only two promises about the application of existing and new ARIN policies to LRSA signatories: "ARIN will take no action to reduce the services provided for Included Number Resources _that are not currently being utilized_ by the Legacy Applicant." (10.b) and "fee shall be $100 per year until the year 2013; no increase per year greater than $25." (6.b) Except for those exclusions, the LRSA includes "the Policies which are hereby incorporated by reference" (15.d). Those policies are "binding upon Legacy Applicant immediately after they are posted on the Website" (7). In other words, if the ARIN board adopts a policy that legacy registrants must install some of their addresses on a router on the moon (or perhaps some requirement that's a little less extreme) then failing to is cause for terminating the contract (14.b). Which revokes the IP addresses (14.e.i). Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Valdis.Kletnieks at vt.edu Sun Aug 15 11:26:38 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 15 Aug 2010 12:26:38 -0400 Subject: BCP38 exceptions for RFC1918 space In-Reply-To: Your message of "Sun, 15 Aug 2010 18:14:41 +0200." <87vd7bg8em.fsf@mid.deneb.enyo.de> References: <87vd7bg8em.fsf@mid.deneb.enyo.de> Message-ID: <67328.1281889598@localhost> On Sun, 15 Aug 2010 18:14:41 +0200, Florian Weimer said: > What's the current consensus on exempting private network space from > source address validation? Is it recommended? Discouraged? What you do on your internal networks and internal transit is your business. BCP38 talks about where you connect to the rest of the world. RFC 1918 is specific that you're supposed to get all medieval on any escaping packets: It is strongly recommended that routers which connect enterprises to external networks are set up with appropriate packet and routing filters at both ends of the link in order to prevent packet and routing information leakage. An enterprise should also filter any private networks from inbound routing information in order to protect itself from ambiguous routing situations which can occur if routes to the private address space point outside the enterprise. > (One argument in favor of exceptions is that it makes PMTUD work if > transfer networks use private address space.) And that connection that's trying to use PMTU got established across the commodity internet, how, exactly? ;) That implies you let some routing info escape and got one of those "ambiguous routing situations". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From fw at deneb.enyo.de Sun Aug 15 11:46:49 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 15 Aug 2010 18:46:49 +0200 Subject: BCP38 exceptions for RFC1918 space In-Reply-To: <67328.1281889598@localhost> (Valdis Kletnieks's message of "Sun, 15 Aug 2010 12:26:38 -0400") References: <87vd7bg8em.fsf@mid.deneb.enyo.de> <67328.1281889598@localhost> Message-ID: <87iq3bg6x2.fsf@mid.deneb.enyo.de> * Valdis Kletnieks: > On Sun, 15 Aug 2010 18:14:41 +0200, Florian Weimer said: >> What's the current consensus on exempting private network space from >> source address validation? Is it recommended? Discouraged? > > What you do on your internal networks and internal transit is your business. > BCP38 talks about where you connect to the rest of the world. I'm seeing them across AS boundaries, otherwise I wouldn't have bothered. > RFC 1918 is specific that you're supposed to get all medieval on any > escaping packets: Yeah, but sometimes, the current practice moves on. 8-) >> (One argument in favor of exceptions is that it makes PMTUD work if >> transfer networks use private address space.) > > And that connection that's trying to use PMTU got established across the > commodity internet, how, exactly? ;) ICMP "fragmentation needed, but DF set" messages carry the a addresses of intermediate routers which generate them (potentially in response to MTU drops) as source addresses, not the IP addresses of the peers in a connection. > That implies you let some routing info escape and got one of those > "ambiguous routing situations". Not really, I'm afraid. From mjwise at kapu.net Sun Aug 15 11:47:35 2010 From: mjwise at kapu.net (Michael J Wise) Date: Sun, 15 Aug 2010 09:47:35 -0700 Subject: BCP38 exceptions for RFC1918 space In-Reply-To: <87vd7bg8em.fsf@mid.deneb.enyo.de> References: <87vd7bg8em.fsf@mid.deneb.enyo.de> Message-ID: <040D7E72-DF20-4C85-843A-D621B73A52B3@kapu.net> On Aug 15, 2010, at 9:14 AM, Florian Weimer wrote: > What's the current consensus on exempting private network space from > source address validation? BCP38-land MUST *never* see RFC1918-space traffic. Ever. Unless you're using a border router as a NAT device, of course.... The only way your question makes sense is if someone who should know better is intending to announce some chunk of RFC1918-space via BGP. Please tell us that is not your intent. Aloha, Michael. -- "Please have your Internet License http://kapu.net/~mjwise/ and Usenet Registration handy..." From Valdis.Kletnieks at vt.edu Sun Aug 15 11:57:18 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 15 Aug 2010 12:57:18 -0400 Subject: BCP38 exceptions for RFC1918 space In-Reply-To: Your message of "Sun, 15 Aug 2010 18:46:49 +0200." <87iq3bg6x2.fsf@mid.deneb.enyo.de> References: <87vd7bg8em.fsf@mid.deneb.enyo.de> <67328.1281889598@localhost> <87iq3bg6x2.fsf@mid.deneb.enyo.de> Message-ID: <69096.1281891438@localhost> On Sun, 15 Aug 2010 18:46:49 +0200, Florian Weimer said: > > And that connection that's trying to use PMTU got established across the > > commodity internet, how, exactly? ;) > > ICMP "fragmentation needed, but DF set" messages carry the a addresses > of intermediate routers which generate them (potentially in response > to MTU drops) as source addresses, not the IP addresses of the peers > in a connection. If any long-haul carriers are originating ICMP packets for other people's consumption from 1918 addresses rather than addresses in their address space, it's time to name-n-shame so the rest of us can vote with our feet and checkbooks. There's no excuse for that in this day and age. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From fw at deneb.enyo.de Sun Aug 15 12:02:50 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 15 Aug 2010 19:02:50 +0200 Subject: BCP38 exceptions for RFC1918 space In-Reply-To: <69096.1281891438@localhost> (Valdis Kletnieks's message of "Sun, 15 Aug 2010 12:57:18 -0400") References: <87vd7bg8em.fsf@mid.deneb.enyo.de> <67328.1281889598@localhost> <87iq3bg6x2.fsf@mid.deneb.enyo.de> <69096.1281891438@localhost> Message-ID: <87y6c7erlx.fsf@mid.deneb.enyo.de> * Valdis Kletnieks: > On Sun, 15 Aug 2010 18:46:49 +0200, Florian Weimer said: > >> > And that connection that's trying to use PMTU got established across the >> > commodity internet, how, exactly? ;) >> >> ICMP "fragmentation needed, but DF set" messages carry the a addresses >> of intermediate routers which generate them (potentially in response >> to MTU drops) as source addresses, not the IP addresses of the peers >> in a connection. > > If any long-haul carriers are originating ICMP packets for other people's > consumption from 1918 addresses rather than addresses in their address space, > it's time to name-n-shame so the rest of us can vote with our feet and > checkbooks. There's no excuse for that in this day and age. What does "originating" mean? Creating the packets? Or forwarding them? From fw at deneb.enyo.de Sun Aug 15 12:15:11 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 15 Aug 2010 19:15:11 +0200 Subject: BCP38 exceptions for RFC1918 space In-Reply-To: <040D7E72-DF20-4C85-843A-D621B73A52B3@kapu.net> (Michael J. Wise's message of "Sun, 15 Aug 2010 09:47:35 -0700") References: <87vd7bg8em.fsf@mid.deneb.enyo.de> <040D7E72-DF20-4C85-843A-D621B73A52B3@kapu.net> Message-ID: <871v9zer1c.fsf@mid.deneb.enyo.de> * Michael J. Wise: > On Aug 15, 2010, at 9:14 AM, Florian Weimer wrote: > >> What's the current consensus on exempting private network space from >> source address validation? > > BCP38-land MUST *never* see RFC1918-space traffic. Ever. > Unless you're using a border router as a NAT device, of course.... > > The only way your question makes sense is if someone who should know > better is intending to announce some chunk of RFC1918-space via BGP. > > Please tell us that is not your intent. It's not. It's not even about my or my employer's network, that's why I need to exercise extra caution before handing out advice. 8-) From nathan at atlasnetworks.us Sun Aug 15 13:02:32 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Sun, 15 Aug 2010 18:02:32 +0000 Subject: Routers in Space (was: Lightly used IP addresses) In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C28164802D4@ex-mb-1.corp.atlasnetworks.us> > In other words, if the ARIN board adopts a policy that legacy > registrants must install some of their addresses on a router on the > moon (or perhaps some requirement that's a little less extreme) then > failing to is cause for terminating the contract (14.b). Which revokes > the IP addresses (14.e.i). Why be less extreme? I would rather see moon-routers! NANO's are encouraged to provide the datasheets for the Cisco 6509's solar-power module and wideband laser signaling SFPs. Best Regards, Nathan Eisenberg From randy at psg.com Sun Aug 15 13:05:04 2010 From: randy at psg.com (Randy Bush) Date: Mon, 16 Aug 2010 03:05:04 +0900 Subject: BCP38 exceptions for RFC1918 space In-Reply-To: <87vd7bg8em.fsf@mid.deneb.enyo.de> References: <87vd7bg8em.fsf@mid.deneb.enyo.de> Message-ID: > What's the current consensus on exempting private network space from > source address validation? Is it recommended? Discouraged? > > (One argument in favor of exceptions is that it makes PMTUD work if > transfer networks use private address space.) and this is a good thing? rfc1918 packets are not supposed to reach the public internet. once you start accommodating their doing so, the downward slope gets pretty steep and does not end in a nice place. randy From rbf+nanog at panix.com Sun Aug 15 13:08:00 2010 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sun, 15 Aug 2010 13:08:00 -0500 Subject: Lightly used IP addresses In-Reply-To: <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> Message-ID: <20100815180800.GA3053@panix.com> On Sun, Aug 15, 2010 at 11:44:18AM -0400, Owen DeLong wrote: > > You and Randy operate from the assumption that these less certain > rights somehow exist at all. I believe them to be fictitious in > nature and contrary to the intent of number stewardship all the way > back to Postel's original notebook. Postel himself is on record > stating that disused addresses should be returned. A non-trivial number of people likely believe they have property rights in their legacy address space (or, more precisely, in the entry in the ARIN database that corresponds to their legacy address space) and that those property rights are much more extensive than the rights they have under the LRSA. John points out that the LRSA gives legacy address holders a degree of certainty that they don't otherwise have. That's almost certainly true; I doubt any legancy address holders are in possession of legal advice to the effect of "you absolutely have property rights in that allocation; there's absoutely no chance you'd lose should you attempt to assert those rights in court". (On the other hand, no one really knows that ARIN has the authority to make the guarantees it's making under the LRSA. The LRSA only binds ARIN ... there's nothing to say the us Government won't step in an and assert its own authority over legacy space. So, while the LRSA confers a degree of certainty, it doesn't confer absolute certainty, or anything close to it.) But John doesn't seem to want to acknowledge, at least directly, the possibility that that thsoe property rights might be reasonably believed by some to exist. I suspect some entities are in possession of legal advice to the effect of "you probably have property rights and probably can do whatever you want with your space and probably get court orders as needed to force ARIN to respond accordingly". If one has gotten such advice from one's lawyers, and one has discussed with those lawyers just how probable "probably" is, it might well be that signing the LRSA is legitimately perceived as giving up rights. > > Because that's intended to be part of the price, Randy. In exchange > > for gaining enforceable rights with respect to ARIN's provision of > > services, you quit any claim to your legacy addresses as property, > > I would say you acknowledge the lack of such a claim in the first > place rather than quit claim. Thus you are not giving up anything and > the only actual price is $100 per year with very limited possible > increases over future years. The reality is that *no one knows* whether or not there are property rights. The difference between "quit claim any rights you have" and "acknowledge you never had any rights" isn't really relevant. Either way, you go from having whatever property rights you originally had (and no one knows for sure what those rights are) to probably not having any such rights. With either language, if you never had any such rights, you aren't giving up anything. If you did previously have such rights, you probably are giving up something. Whether the language is written presupposing the existance of such rights, or presupposing the non-existance of such rights, has no real effect. OF course ARIN's position is that that clause merely clarifies a situation that already exists. But the fact that ARIN feels it needs clarifying illustrates the ambiguity. > Any belief that non-signatories enjoy rights not present in the RSA > is speculative at best. I suspect some people are in possession of legal advice to the contrary. (Well, sure, technically, it is speculative. But I'd imagine that some people have a pretty high degree of confidence in their speculation.) Let's put it this way: (This is a hypothetical point; I'm not actually making an offer here.) Say I'm willing to buy, for $10 per /24, any property rights that anyone with legacy space has in their legacy allocation, provided they have not signed an RSA or LRSA with respect to that space, and provided that they agree to never sign any such agreement, or nay similar agreement, with respect to that space. If there's no property rights, that's a free $10 per /24. On the other hand, if there are property rights, then that's a pretty low price for giving me the authority to direct a transfer of the space whenever I feel like it. How many people do you think would rationally take me up on this offer? Would you advise an ISP with a legacy allocation that is temporarily short on cash to engage in such a transaction? If so, are you confident enough in your position that you'd agree to personally indemnify them against any loss they might incur if it turns out that there are property rights and now I hold them? And that's really the crux of this argument. One side assumes there are no property rights and argues from that premise, the other side assumes there are and argues from that premise. But sides' arguments are logically sound (more or less), but they start from different premises, and starting there isn't going to do anything to convince the other side that its premise is wrong. People will just keep talking past each other if they decline to address the underlying difference in premise. -- Brett From jcurran at arin.net Sun Aug 15 13:29:35 2010 From: jcurran at arin.net (John Curran) Date: Sun, 15 Aug 2010 14:29:35 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> Message-ID: <0953B49C-145B-47DF-8768-8961F67405A7@arin.net> On Aug 15, 2010, William Herrin wrote: > Please: don't ask folks to take discussions of public concern to a closed forum. > ... > ARIN makes only two promises about the application of existing and new > ARIN policies to LRSA signatories: "ARIN will take no action to reduce > the services provided for Included Number Resources _that are not > currently being utilized_ by the Legacy Applicant." Bill - Two quick points - Your concern about arin-discuss is understandable (i.e. you should not have to join ARIN in order to discuss a potential concern of community interest that you have with the agreement). I'll mention this to the Board, and note in the meantime that the PPML mailing list often covers far-ranging discussions such as these in case that becomes necessary. Also, your emphasis above ("_that are not currently being utilized_"), pointed our we need to clarify that it should include "all resources, including those not currently being utilized", i.e. the phrase wasn't intended to exclude *utilized* resources from "ARIN will take no action" clause. I will have that fixed on the next version of the LRSA. /John John Curran President and CEO ARIN From randy at psg.com Sun Aug 15 13:32:49 2010 From: randy at psg.com (Randy Bush) Date: Mon, 16 Aug 2010 03:32:49 +0900 Subject: Lightly used IP addresses In-Reply-To: <0953B49C-145B-47DF-8768-8961F67405A7@arin.net> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> <0953B49C-145B-47DF-8768-8961F67405A7@arin.net> Message-ID: > Also, your emphasis above ("_that are not currently being utilized_"), > pointed our we need to clarify that it should include "all resources, > including those not currently being utilized", i.e. the phrase wasn't > intended to exclude *utilized* resources from "ARIN will take no action" > clause. I will have that fixed on the next version of the LRSA. but john, should you not run the change through the policy process? randy From jcurran at arin.net Sun Aug 15 13:53:15 2010 From: jcurran at arin.net (John Curran) Date: Sun, 15 Aug 2010 14:53:15 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> <0953B49C-145B-47DF-8768-8961F67405A7@arin.net> Message-ID: <141B32D7-0BC4-4F9A-9E90-E862D59D9D2C@arin.net> On Aug 15, 2010, at 2:32 PM, Randy Bush wrote: >> Also, your emphasis above ("_that are not currently being utilized_"), >> pointed our we need to clarify that it should include "all resources, >> including those not currently being utilized", i.e. the phrase wasn't >> intended to exclude *utilized* resources from "ARIN will take no action" >> clause. I will have that fixed on the next version of the LRSA. > > but john, should you not run the change through the policy process? Randy - The language "ARIN will take no action to reduce the services provided for Included Number Resources that are not currently being utilized by the Legacy Applicant" was stated in plain language to make clear the representation ARIN was making to the LRSA applicant. That representation is intended for all included resources, not just unused, so the language should be corrected to the benefit of Legacy holders. Your discourse is often thought provoking, informative, and even colorful, but I'll not let it be to the general detriment of the community. If a new LRSA signatory really wants the old language with a weaker promise from ARIN, we'll readily accommodate them then. /John John Curran President and CEO ARIN From randy at psg.com Sun Aug 15 13:55:30 2010 From: randy at psg.com (Randy Bush) Date: Mon, 16 Aug 2010 03:55:30 +0900 Subject: Lightly used IP addresses In-Reply-To: <141B32D7-0BC4-4F9A-9E90-E862D59D9D2C@arin.net> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> <0953B49C-145B-47DF-8768-8961F67405A7@arin.net> <141B32D7-0BC4-4F9A-9E90-E862D59D9D2C@arin.net> Message-ID: john, the bottom line is, changes you like and can justify to yourself with lots of glib words can be made without process. changes you don't like have to go through the policy gauntlet. randy From jcurran at arin.net Sun Aug 15 14:03:02 2010 From: jcurran at arin.net (John Curran) Date: Sun, 15 Aug 2010 15:03:02 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> Message-ID: On Aug 15, 2010, at 11:14 AM, William Herrin wrote: > > Unfortunately, the LRSA contains another price which I personally > consider too high: voluntary termination revokes the IP addresses > instead of restoring the pre-contract status quo. Without that > balancing check to the contract, I think a steady creep in what ARIN > requires of the signatory is inevitable... and the affirmative actions > ARIN can require the registrant to perform in order to maintain the > contract are nearly unlimited. Bill - Voluntary termination because ARIN is in breach results in pre-contract status quo, otherwise you are correct. Changing this would be a useful item to discuss at the Public Policy & Members meeting in one of the open mike sessions, or to submit to the suggestion process for discussion on the arin-consult mailing list The last round of improvements to the LRSA (version 2.0) added several circumstances that result in pre-contract status quo, and additional ones could be added if the community wants such and the Board concurs. /John John Curran President and CEO ARIN From jcurran at arin.net Sun Aug 15 14:53:05 2010 From: jcurran at arin.net (John Curran) Date: Sun, 15 Aug 2010 15:53:05 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> <0953B49C-145B-47DF-8768-8961F67405A7@arin.net> <141B32D7-0BC4-4F9A-9E90-E862D59D9D2C@arin.net> Message-ID: <8BE77473-9F9F-43F0-9A27-71D46B150670@arin.net> On Aug 15, 2010, at 2:55 PM, Randy Bush wrote: > > the bottom line is, changes you like and can justify to yourself with > lots of glib words can be made without process. > changes you don't like have to go through the policy gauntlet. Changes to the ARIN's operations are within my authority; I try to be reachable to the community (and how... :-), but there's also the more formal ARIN Consultation and Suggestion (ACSP) process if desired: . Changes to ARIN's fees, services, and agreements are done after consultation to the ARIN Board, and often go through the ACSP consultation process or are discussed at one of the meetings. Suggestions are also welcomed as per above, just as I asked Mr. Herrin to do earlier regarding the LRSA. Changes to the Number Resource Policy Manual (NRPM) , are made via ARIN's Policy Development Process. My apologies if this was somehow unclear, /John John Curran President and CEO ARIN From Valdis.Kletnieks at vt.edu Sun Aug 15 14:51:46 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 15 Aug 2010 15:51:46 -0400 Subject: Lightly used IP addresses In-Reply-To: Your message of "Sun, 15 Aug 2010 11:44:18 EDT." <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> Message-ID: <73403.1281901906@localhost> On Sun, 15 Aug 2010 11:44:18 EDT, Owen DeLong said: > You and Randy operate from the assumption that these less certain rights > somehow exist at all. I believe them to be fictitious in nature and > contrary to the intent of number stewardship all the way back to > Postel's original notebook. Postel himself is on record stating that > disused addresses should be returned. We've written RFCs that explain SHOULD != MUST. Keep in mind that he said that back in a long-bygone era where sending an e-mail asking "If you're not going to deploy that address range, can you give it back just because it's the Right Thing To Do, even though there's a chance that 15 years from now, you'll be able to sell it for megabucks" didn't get 53 levels of management and lawyers involved. On Sun, 15 Aug 2010 11:33:34 EDT, Owen DeLong said: > A contract which clarifies that you still don't have rights you never > had does not constitute relinquishing those non-existent rights no > matter how many times you repeat yourself. Ahh - but here's the kicker. For the contract to clarify the status of that right, it *is* admitting that the right exists and has a definition (even if not spelled out in the contract). A non-existent thing can't be the subject of a contract negotiation. So in the contract, you can agree that you don't have right XYZ, and clarify that you understand you never had right XYZ. But it doesn't make sense if XYZ is nonexistent. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From randy at psg.com Sun Aug 15 15:06:15 2010 From: randy at psg.com (Randy Bush) Date: Mon, 16 Aug 2010 05:06:15 +0900 Subject: Lightly used IP addresses In-Reply-To: <8BE77473-9F9F-43F0-9A27-71D46B150670@arin.net> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> <0953B49C-145B-47DF-8768-8961F67405A7@arin.net> <141B32D7-0BC4-4F9A-9E90-E862D59D9D2C@arin.net> <8BE77473-9F9F-43F0-9A27-71D46B150670@arin.net> Message-ID: >> the bottom line is, changes you like and can justify to yourself with >> lots of glib words can be made without process. changes you don't >> like have to go through the policy gauntlet. > ... > Changes to ARIN's fees, services, and agreements are done after > consultation to the ARIN Board, and often go through the ACSP > consultation process or are discussed at one of the meetings. > Suggestions are also welcomed as per above, just as I asked Mr. Herrin > to do earlier regarding the LRSA. as a reader of this thread with any memory can clearly see, when i asked about a change to the lrsa (with which you clearly disagree), i was told to submit a suggestion and to go through the policy process. when you want a change to the same agreement, whammy, it can magically be done with a quick internal process. qed. randy From jcurran at arin.net Sun Aug 15 15:18:09 2010 From: jcurran at arin.net (John Curran) Date: Sun, 15 Aug 2010 16:18:09 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> <0953B49C-145B-47DF-8768-8961F67405A7@arin.net> <141B32D7-0BC4-4F9A-9E90-E862D59D9D2C@arin.net> <8BE77473-9F9F-43F0-9A27-71D46B150670@arin.net> Message-ID: On Aug 15, 2010, at 4:06 PM, Randy Bush wrote: > > as a reader of this thread with any memory can clearly see, when i asked > about a change to the lrsa (with which you clearly disagree), i was told > to submit a suggestion and to go through the policy process. > > when you want a change to the same agreement, whammy, it can magically > be done with a quick internal process. Randy - I understand your confusion. If you find a typo, or grammatical error, or phrase which is contradictory, I can fix it the next version. If you have a suggestion for LRSA content change, please use the suggestion process or take it up at a meeting as you prefer. For the particular change that you want, I was noting that NRPM 4.1 (not 6.4.1 as I wrote) specifically cites RFC 2050: > 4.1.7. RFC 2050 > > ARIN takes guidance from allocation and assignment policies and procedures set forth in RFC 2050. These guidelines were developed to meet the needs of the larger Internet community in conserving scarce IPv4 address space and allowing continued use of existing Internet routing technologies. and as a result, you should look to the IETF to update the RFC2050 guidance or the Policy Development process to remove the reference. Thanks, /John John Curran President and CEO ARIN ---- Begin forwarded message: > From: John Curran > Date: August 15, 2010 6:49:12 AM EDT > To: Randy Bush > Cc: North American Network Operators Group > Subject: Re: Lightly used IP addresses > > On Aug 15, 2010, at 6:21 AM, Randy Bush wrote: >> >>>> gosh, i must have completely misread section nine >>> Seeking contractual rights contrary to IETF RFCs 2008 and 2150? >> >> oh, and if you feel that you have those rights by other means than the >> lrsa, then why is section nine in the lrsa. just remove it. > > Easy to do, you can either: > > 1) Change the appropriate policy language (NRPM 6.4.1) via the ARIN policy > development process, in which case the LRSA will be updated as noted, or > > 2) If you feel that you'd prefer a different forum, you can address this on a > more global basis (since each RIR has similar language regarding addresses) > by going through the IETF and revising the RFCs, which will likely result > in the RIRs all reviewing their documents accordingly. > > Either route requires that the community comes to a consensus on the change > and can give you the results you seek. Or you can enjoy the status quo. > > /John > > John Curran > President and CEO > ARIN > > p.s. If you want to continue to discuss, can we shortly move this to PPML > or ARIN-Discuss for the sake of those not interested in these matters > who have different expectations from their NANOG list subscription? > From dot at dotat.at Sun Aug 15 17:25:57 2010 From: dot at dotat.at (Tony Finch) Date: Sun, 15 Aug 2010 23:25:57 +0100 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> Message-ID: On Sat, 14 Aug 2010, Randy Bush wrote: > > when the registry work was re-competed and taken from sri to netsol (i > think it was called that at the time), rick adams put in a no cost > bid to do it all with automated scripts. hindsight tells me we should > have supported that much more strongly. I fear the abuse resulting from free domain registration. Tony. -- f.anthony.n.finch http://dotat.at/ MALIN HEBRIDES: SOUTH 3 OR 4. SLIGHT, OCCASIONALLY MODERATE. OCCASIONAL DRIZZLE THEN RAIN. MODERATE OR GOOD, OCCASIONALLY POOR. From sethm at rollernet.us Sun Aug 15 17:41:43 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 15 Aug 2010 15:41:43 -0700 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> Message-ID: <4C686D27.4050709@rollernet.us> On 8/13/2010 19:55, Randy Bush wrote: > > when the registry work was re-competed and taken from sri to netsol (i > think it was called that at the time), rick adams [0] put in a no cost > bid to do it all with automated scripts. hindsight tells me we should > have supported that much more strongly. and folk who think that would > not have scaled, need to know that the netsol lowball solution was mark > and scott in a basement with a sun3 and a 56k line. > Hah. Automated no-cost registration, meet automated registering script with a dictionary plus random string generator. ~Seth From brunner at nic-naa.net Sun Aug 15 17:42:50 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sun, 15 Aug 2010 18:42:50 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> Message-ID: <4C686D6A.9000500@nic-naa.net> On 8/15/10 6:25 PM, Tony Finch wrote: > On Sat, 14 Aug 2010, Randy Bush wrote: >> >> when the registry work was re-competed and taken from sri to netsol (i >> think it was called that at the time), rick adams put in a no cost when we (sri) lost the defense data network nic contract in may '91, disa awarded it to government systems inc., which eventually became netsol. >> bid to do it all with automated scripts. hindsight tells me we should >> have supported that much more strongly. > > I fear the abuse resulting from free domain registration. the price point gsi set was $100/two-years, and later in litigation the portion earmarked to go a public agency was removed, resulting in the $75/two-year price point. of the things to fear, that hadn't happened then, such as the determination that domains are marks (wipo i), and the ancillary exploits, keeping the cost at the green-stamp price-point of zero dollars and zero cents seems a pretty odd thing to fear. yes, we f*cked by failing to keep the allocation mechanism profit neutral. -e From lists at memetic.org Sun Aug 15 18:35:09 2010 From: lists at memetic.org (Adam Armstrong) Date: Mon, 16 Aug 2010 00:35:09 +0100 Subject: BCP38 exceptions for RFC1918 space In-Reply-To: <87y6c7erlx.fsf@mid.deneb.enyo.de> References: <87vd7bg8em.fsf@mid.deneb.enyo.de> <67328.1281889598@localhost> <87iq3bg6x2.fsf@mid.deneb.enyo.de> <69096.1281891438@localhost> <87y6c7erlx.fsf@mid.deneb.enyo.de> Message-ID: <4C6879AD.2000106@memetic.org> On 15/08/2010 18:02, Florian Weimer wrote: > * Valdis Kletnieks: > >> On Sun, 15 Aug 2010 18:46:49 +0200, Florian Weimer said: >> >>>> And that connection that's trying to use PMTU got established across the >>>> commodity internet, how, exactly? ;) >>> >>> ICMP "fragmentation needed, but DF set" messages carry the a addresses >>> of intermediate routers which generate them (potentially in response >>> to MTU drops) as source addresses, not the IP addresses of the peers >>> in a connection. >> >> If any long-haul carriers are originating ICMP packets for other people's >> consumption from 1918 addresses rather than addresses in their address space, >> it's time to name-n-shame so the rest of us can vote with our feet and >> checkbooks. There's no excuse for that in this day and age. > > What does "originating" mean? Creating the packets? Or forwarding > them? My bus originates in the town of bananaville, but before it finally originates at mangoburgh, it originates through 5 other towns. Wow, that would be a confusing language to speak. ;) The origin is the beginning point of something, where it is created. http://en.wiktionary.org/wiki/origin I'll let you off as you're German and German doesn't use any words with related etymology :> Though really, if you know BGP you should understand the term 'origin'. adam. From owen at delong.com Sun Aug 15 22:05:22 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 15 Aug 2010 20:05:22 -0700 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> Message-ID: On Aug 15, 2010, at 9:20 AM, William Herrin wrote: > On Sun, Aug 15, 2010 at 11:44 AM, Owen DeLong wrote: >> ARIN fees and budget are a member concern, not a public concern. > > Oh really? The money ARIN spends managing the public's IP addresses > (and how it collects that money and the privileges conferred on the > folks from whom it's collected) are not a matter of public concern? > > I seem to recall that attitude was how ICANN first started to get in to trouble. > > As I said, they are a matter of member concern. To the best of my knowledge, ICANN membership is not open. If you care about how ARIN spends its money, become a member, speak up, and vote. Membership is open to all and voting membership is open to all resource holders. >>> Unfortunately, the LRSA contains another price which I personally >>> consider too high: voluntary termination revokes the IP addresses >>> instead of restoring the pre-contract status quo. Without that >>> balancing check to the contract, I think a steady creep in what ARIN >>> requires of the signatory is inevitable... and the affirmative actions >>> ARIN can require the registrant to perform in order to maintain the >>> contract are nearly unlimited. >>> >> I believe the LRSA limits them primarily to the annual fee payment. > > Do you now. Unfortunately, the plain language of the LRSA does not > respect your belief. > > ARIN makes only two promises about the application of existing and new > ARIN policies to LRSA signatories: "ARIN will take no action to reduce > the services provided for Included Number Resources _that are not > currently being utilized_ by the Legacy Applicant." (10.b) and "fee > shall be $100 per year until the year 2013; no increase per year > greater than $25." (6.b) > > Except for those exclusions, the LRSA includes "the Policies which are > hereby incorporated by reference" (15.d). Those policies are "binding > upon Legacy Applicant immediately after they are posted on the > Website" (7). > > In other words, if the ARIN board adopts a policy that legacy > registrants must install some of their addresses on a router on the > moon (or perhaps some requirement that's a little less extreme) then > failing to is cause for terminating the contract (14.b). Which revokes > the IP addresses (14.e.i). > I think that is a rather bizarre and extreme construction of excerpts of the contract language. More rational construction would lead one to believe that the stated intent is to limit ARIN's ability to raise fees and prevent the revocation of legacy addresses absent a failure to pay fees. The policies incorporated by reference are the same policies which affect every other address holder, so ARIN would have a hard time requiring legacy holders to address devices on the moon without requiring the same thing from all other resource holders. Owen From owen at delong.com Sun Aug 15 22:25:50 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 15 Aug 2010 20:25:50 -0700 Subject: Lightly used IP addresses In-Reply-To: <20100815180800.GA3053@panix.com> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> <20100815180800.GA3053@panix.com> Message-ID: <71D31107-CC10-4E1C-9119-A72EFF116ABD@delong.com> On Aug 15, 2010, at 11:08 AM, Brett Frankenberger wrote: > On Sun, Aug 15, 2010 at 11:44:18AM -0400, Owen DeLong wrote: >> >> You and Randy operate from the assumption that these less certain >> rights somehow exist at all. I believe them to be fictitious in >> nature and contrary to the intent of number stewardship all the way >> back to Postel's original notebook. Postel himself is on record >> stating that disused addresses should be returned. > > A non-trivial number of people likely believe they have property rights > in their legacy address space (or, more precisely, in the entry in the > ARIN database that corresponds to their legacy address space) and that > those property rights are much more extensive than the rights they have > under the LRSA. > Once upon a time, a non-trivial number of people believed in a set of $DIETIES we now refer to as greco-roman mythology. That doesn't make those beliefs any more or less correct than the ones who believe in these mystic undocumented property rights. > John points out that the LRSA gives legacy address holders a degree of > certainty that they don't otherwise have. That's almost certainly > true; I doubt any legancy address holders are in possession of legal > advice to the effect of "you absolutely have property rights in that > allocation; there's absoutely no chance you'd lose should you attempt > to assert those rights in court". (On the other hand, no one really > knows that ARIN has the authority to make the guarantees it's making > under the LRSA. The LRSA only binds ARIN ... there's nothing to say > the us Government won't step in an and assert its own authority over > legacy space. So, while the LRSA confers a degree of certainty, it > doesn't confer absolute certainty, or anything close to it.) > Since the only assurances the LRSA offers are with regard to what ARIN will or won't do, I would say that ARIN is in a perfectly good position to make those assurances. > But John doesn't seem to want to acknowledge, at least directly, the > possibility that that thsoe property rights might be reasonably > believed by some to exist. I suspect some entities are in possession > of legal advice to the effect of "you probably have property rights and > probably can do whatever you want with your space and probably get > court orders as needed to force ARIN to respond accordingly". If one > has gotten such advice from one's lawyers, and one has discussed with > those lawyers just how probable "probably" is, it might well be that > signing the LRSA is legitimately perceived as giving up rights. > Whether or not such belief is reasonable (I'm not inclined that it is as I have seen not one single document that conveys any form of property rights and the concept of owning integers seems utterly bizarre to me) I will leave to the psychologists and psychiatrists to determine. I acknowledge that some people believe this. I believe they are mistaken. I'll leave it to John to speak for himself on the matter. >>> Because that's intended to be part of the price, Randy. In exchange >>> for gaining enforceable rights with respect to ARIN's provision of >>> services, you quit any claim to your legacy addresses as property, >> >> I would say you acknowledge the lack of such a claim in the first >> place rather than quit claim. Thus you are not giving up anything and >> the only actual price is $100 per year with very limited possible >> increases over future years. > > The reality is that *no one knows* whether or not there are property > rights. The difference between "quit claim any rights you have" and > "acknowledge you never had any rights" isn't really relevant. Either > way, you go from having whatever property rights you originally had > (and no one knows for sure what those rights are) to probably not > having any such rights. > Not exactly. In the "acknowledging you never had rights" scenario, you go from having no rights whatsoever to having a defined set of rights which may be less in scope than you imagined your rights to be prior to seeking documentation of said rights and discovering none. > With either language, if you never had any such rights, you aren't > giving up anything. If you did previously have such rights, you > probably are giving up something. Whether the language is written > presupposing the existance of such rights, or presupposing the > non-existance of such rights, has no real effect. > Ah, but, if you never had any such rights and you are gaining some rights (which is actually what the LRSA does) that is quite different from giving up rights. I agree that the perspective of the contractual language is nearly a no-op for the signatories of the contract. > OF course ARIN's position is that that clause merely clarifies a > situation that already exists. But the fact that ARIN feels it needs > clarifying illustrates the ambiguity. > Or, perhaps, the fact that ARIN feels it needs clarifying is indicative of ARIN acknowledging wide-spread mythology. I can acknowledge that the greeks believed Hades lived in the underworld and took the dead without believing that they were correct in that belief or accepting any ambiguity on the correctness of that belief. >> Any belief that non-signatories enjoy rights not present in the RSA >> is speculative at best. > > I suspect some people are in possession of legal advice to the > contrary. (Well, sure, technically, it is speculative. But I'd > imagine that some people have a pretty high degree of confidence in > their speculation.) > That may well be true. I don't see how it makes any difference (other than possibly leading to future legal malpractice suits). > Let's put it this way: (This is a hypothetical point; I'm not actually > making an offer here.) Say I'm willing to buy, for $10 per /24, any > property rights that anyone with legacy space has in their legacy > allocation, provided they have not signed an RSA or LRSA with respect > to that space, and provided that they agree to never sign any such > agreement, or nay similar agreement, with respect to that space. > s/nay/any/ ? (nay in that context doesn't parse for me, but, I want to make sure I am extracting the correct meaning) > If there's no property rights, that's a free $10 per /24. On the other > hand, if there are property rights, then that's a pretty low price for > giving me the authority to direct a transfer of the space whenever I > feel like it. > Yep. My belief is that: 1. You'd have few takers at that price. 2. Even if you did, when you attempted to direct the transfer, the block would have a good chance of being reclaimed. 3. Upon reclamation, you'd have a poor chance of winning your lawsuit against ARIN to try and force the transfer. > How many people do you think would rationally take me up on this offer? At $10 per /24... roughly 0. > Would you advise an ISP with a legacy allocation that is temporarily > short on cash to engage in such a transaction? If so, are you > confident enough in your position that you'd agree to personally > indemnify them against any loss they might incur if it turns out that > there are property rights and now I hold them? > I would advise them against such a transaction because such a transaction would be contrary to ARIN policies and they could well lose their space in the process. > And that's really the crux of this argument. One side assumes there > are no property rights and argues from that premise, the other side > assumes there are and argues from that premise. But sides' arguments > are logically sound (more or less), but they start from different > premises, and starting there isn't going to do anything to convince the > other side that its premise is wrong. People will just keep talking > past each other if they decline to address the underlying difference in > premise. > Agreed... Hence my bringing up the fact that it was different premises in the first place. Owen From jeffrey.lyon at blacklotus.net Sun Aug 15 22:31:43 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 16 Aug 2010 08:01:43 +0430 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> Message-ID: All (and especially Mr. Curran), Would the policy process be an appropriate venue for a proposition to change the ARIN mission, restricting it's activities exclusively to registration services while requiring a reduction in fees and budget? Best regards, Jeff On Mon, Aug 16, 2010 at 7:35 AM, Owen DeLong wrote: > > On Aug 15, 2010, at 9:20 AM, William Herrin wrote: > >> On Sun, Aug 15, 2010 at 11:44 AM, Owen DeLong wrote: >>> ARIN fees and budget are a member concern, not a public concern. >> >> Oh really? The money ARIN spends managing the public's IP addresses >> (and how it collects that money and the privileges conferred on the >> folks from whom it's collected) are not a matter of public concern? >> >> I seem to recall that attitude was how ICANN first started to get in to trouble. >> >> > As I said, they are a matter of member concern. To the best of my knowledge, > ICANN membership is not open. If you care about how ARIN spends its money, > become a member, speak up, and vote. Membership is open to all and voting > membership is open to all resource holders. > >>>> Unfortunately, the LRSA contains another price which I personally >>>> consider too high: voluntary termination revokes the IP addresses >>>> instead of restoring the pre-contract status quo. Without that >>>> balancing check to the contract, I think a steady creep in what ARIN >>>> requires of the signatory is inevitable... and the affirmative actions >>>> ARIN can require the registrant to perform in order to maintain the >>>> contract are nearly unlimited. >>>> >>> I believe the LRSA limits them primarily to the annual fee payment. >> >> Do you now. Unfortunately, the plain language of the LRSA does not >> respect your belief. >> >> ARIN makes only two promises about the application of existing and new >> ARIN policies to LRSA signatories: "ARIN will take no action to reduce >> the services provided for Included Number Resources _that are not >> currently being utilized_ by the Legacy Applicant." (10.b) and "fee >> shall be $100 per year until the year 2013; no increase per year >> greater than $25." (6.b) >> >> Except for those exclusions, the LRSA includes "the Policies which are >> hereby incorporated by reference" (15.d). Those policies are "binding >> upon Legacy Applicant immediately after they are posted on the >> Website" (7). >> >> In other words, if the ARIN board adopts a policy that legacy >> registrants must install some of their addresses on a router on the >> moon (or perhaps some requirement that's a little less extreme) then >> failing to is cause for terminating the contract (14.b). Which revokes >> the IP addresses (14.e.i). >> > I think that is a rather bizarre and extreme construction of excerpts of the > contract language. More rational construction would lead one to believe > that the stated intent is to limit ARIN's ability to raise fees and prevent > the revocation of legacy addresses absent a failure to pay fees. > > The policies incorporated by reference are the same policies which affect > every other address holder, so ARIN would have a hard time requiring > legacy holders to address devices on the moon without requiring the > same thing from all other resource holders. > > Owen > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From owen at delong.com Sun Aug 15 22:30:54 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 15 Aug 2010 20:30:54 -0700 Subject: Lightly used IP addresses In-Reply-To: <73403.1281901906@localhost> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> <73403.1281901906@localhost> Message-ID: On Aug 15, 2010, at 12:51 PM, Valdis.Kletnieks at vt.edu wrote: > On Sun, 15 Aug 2010 11:44:18 EDT, Owen DeLong said: >> You and Randy operate from the assumption that these less certain rights >> somehow exist at all. I believe them to be fictitious in nature and >> contrary to the intent of number stewardship all the way back to >> Postel's original notebook. Postel himself is on record stating that >> disused addresses should be returned. > > We've written RFCs that explain SHOULD != MUST. > > Keep in mind that he said that back in a long-bygone era where sending an > e-mail asking "If you're not going to deploy that address range, can you give > it back just because it's the Right Thing To Do, even though there's a chance > that 15 years from now, you'll be able to sell it for megabucks" didn't get 53 > levels of management and lawyers involved. > > On Sun, 15 Aug 2010 11:33:34 EDT, Owen DeLong said: >> A contract which clarifies that you still don't have rights you never >> had does not constitute relinquishing those non-existent rights no >> matter how many times you repeat yourself. > > Ahh - but here's the kicker. For the contract to clarify the status of that > right, it *is* admitting that the right exists and has a definition (even if > not spelled out in the contract). A non-existent thing can't be the subject > of a contract negotiation. So in the contract, you can agree that you don't > have right XYZ, and clarify that you understand you never had right XYZ. > But it doesn't make sense if XYZ is nonexistent. > There are lots of contracts which clarify that inaccuracies previously perceived as rights are, indeed, and always were, fictitious in nature. That is possible in a contract and is not as uncommon as one would wish it were. It does not magically lend credence to the prior fiction. Owen From bill at herrin.us Mon Aug 16 00:14:38 2010 From: bill at herrin.us (William Herrin) Date: Mon, 16 Aug 2010 01:14:38 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> Message-ID: On Sun, Aug 15, 2010 at 3:03 PM, John Curran wrote: > ?The last round of improvements to the LRSA (version 2.0) added several > ?circumstances that result in pre-contract status quo, and additional > ?ones could be added if the community wants such and the Board concurs. John, I noticed and I appreciate it. Each round of revisions to the LRSA contract has brought it closer to being a document I could sign. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From awacs at ziskind.us Mon Aug 16 00:25:48 2010 From: awacs at ziskind.us (N. Yaakov Ziskind) Date: Mon, 16 Aug 2010 01:25:48 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> Message-ID: <20100816012548.C17976@egps.ziskind.us> [attribution removed, as I lost track of who said what] > > Do you now. Unfortunately, the plain language of the LRSA does not > > respect your belief. > > > > ARIN makes only two promises about the application of existing and new > > ARIN policies to LRSA signatories: "ARIN will take no action to reduce > > the services provided for Included Number Resources _that are not > > currently being utilized_ by the Legacy Applicant." (10.b) and "fee > > shall be $100 per year until the year 2013; no increase per year > > greater than $25." (6.b) > > > > Except for those exclusions, the LRSA includes "the Policies which are > > hereby incorporated by reference" (15.d). Those policies are "binding > > upon Legacy Applicant immediately after they are posted on the > > Website" (7). > > > > In other words, if the ARIN board adopts a policy that legacy > > registrants must install some of their addresses on a router on the > > moon (or perhaps some requirement that's a little less extreme) then > > failing to is cause for terminating the contract (14.b). Which revokes > > the IP addresses (14.e.i). > > > I think that is a rather bizarre and extreme construction of excerpts of the > contract language. More rational construction would lead one to believe > that the stated intent is to limit ARIN's ability to raise fees and prevent > the revocation of legacy addresses absent a failure to pay fees. You could think this 'bizarre', and you might be right. I read it, however, and was convinced - at least to the point where I would advise a client not to sign such an agreement without additional research. Ritual disclaimer - IAAL, but not a very good one, and this isn't legal advice, and, if you take legal advice from a stranger's internet postings, you have bigger problems than ARIN can throw at you. :-) -- _________________________________________ Nachman Yaakov Ziskind, FSPA, LLM awacs at ziskind.us Attorney and Counselor-at-Law http://ziskind.us Economic Group Pension Services http://egps.com Actuaries and Employee Benefit Consultants From bill at herrin.us Mon Aug 16 00:44:47 2010 From: bill at herrin.us (William Herrin) Date: Mon, 16 Aug 2010 01:44:47 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> Message-ID: On Sun, Aug 15, 2010 at 11:05 PM, Owen DeLong wrote: > On Aug 15, 2010, at 9:20 AM, William Herrin wrote: >> On Sun, Aug 15, 2010 at 11:44 AM, Owen DeLong wrote: >>> ARIN fees and budget are a member concern, not a public concern. >> >> I seem to recall that attitude was how ICANN first started to get in to trouble. > > To the best of my knowledge, > ICANN membership is not open. Not any more. >>>> requires of the signatory is inevitable... and the affirmative actions >>>> ARIN can require the registrant to perform in order to maintain the >>>> contract are nearly unlimited. >>> >>> I believe the LRSA limits them primarily to the annual fee payment. Put your money where your mouth is Owen. As an ARIN Advisory Council member, ask ARIN Counsel Steve Ryan to issue a legal opinion that ARIN considers itself constrained to limit the requirements placed on LRSA signatories "primarily to the annual fee payment" regardless of how ARIN policy changes. Until reading such a clarification from someone actually qualified to make it, I have to expect that the contract means what it says when it says that only regular fees and use ratios are excluded from the scope of policy ARIN may apply to legacy registrants under an LRSA. >> Do you now. Unfortunately, the plain language of the LRSA does not >> respect your belief. >> >> ARIN makes only two promises about the application of existing and new >> ARIN policies to LRSA signatories: > >More rational construction would lead one to believe >that the stated intent is to limit ARIN's ability The courts are full of people who thought a contract intended to mean something other than the actual text to which their signature was attached. Their rate of success is not great. > The policies incorporated by reference are the same policies which affect > every other address holder, so ARIN would have a hard time requiring > legacy holders to address devices on the moon without requiring the > same thing from all other resource holders. ARIN doesn't seem to have any problem differentiating between ISP address holdings and end-user address holdings in the policies, and applying rather substantially different requirements to each. What exactly do you think would prevent policies from differentiating between those two classes and legacy address holdings under an LRSA? The retort you want to make is that ARIN just wouldn't do that. That's not the kind of people they are. Fine. So update the LRSA so it doesn't carefully and pervasively establish ARIN's legal right to behave that way. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From marcoh at marcoh.net Mon Aug 16 00:49:15 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 16 Aug 2010 07:49:15 +0200 Subject: BCP38 exceptions for RFC1918 space In-Reply-To: References: <87vd7bg8em.fsf@mid.deneb.enyo.de> Message-ID: <821D4DC0-2179-4018-B37A-9EE1C7DB91B2@marcoh.net> On 15 aug 2010, at 20:05, Randy Bush wrote: >> What's the current consensus on exempting private network space from >> source address validation? Is it recommended? Discouraged? >> >> (One argument in favor of exceptions is that it makes PMTUD work if >> transfer networks use private address space.) > > and this is a good thing? > > rfc1918 packets are not supposed to reach the public internet. once you > start accommodating their doing so, the downward slope gets pretty steep > and does not end in a nice place. I cannot agree more with this. If you want PMTU use non-private space, there is enough really :) And saving a /24 by renumbering your core into RFC 1918 won't save you from the coming run out. MarcoH From bill at herrin.us Mon Aug 16 01:05:14 2010 From: bill at herrin.us (William Herrin) Date: Mon, 16 Aug 2010 02:05:14 -0400 Subject: BCP38 exceptions for RFC1918 space In-Reply-To: <821D4DC0-2179-4018-B37A-9EE1C7DB91B2@marcoh.net> References: <87vd7bg8em.fsf@mid.deneb.enyo.de> <821D4DC0-2179-4018-B37A-9EE1C7DB91B2@marcoh.net> Message-ID: On Mon, Aug 16, 2010 at 1:49 AM, Marco Hogewoning wrote: > On 15 aug 2010, at 20:05, Randy Bush wrote: >> rfc1918 packets are not supposed to reach the public internet. ?once you >> start accommodating their doing so, the downward slope gets pretty steep >> and does not end in a nice place. > > I cannot agree more with this. If you want PMTU use >non-private space, there is enough really :) And saving > a /24 by renumbering your core into RFC 1918 won't > save you from the coming run out. I once suggested something along the lines of: interface Loopback0 ip address 1.2.3.4 255.255.255.255 interface GigabitEthernet0/0 ip address 192.168.0.1 255.255.255.0 icmp errors-from Loopback0 But I was yelled at for trying to break traceroute. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mike-nanog at tiedyenetworks.com Mon Aug 16 01:49:05 2010 From: mike-nanog at tiedyenetworks.com (Mike) Date: Sun, 15 Aug 2010 23:49:05 -0700 Subject: Numbering nameservers and resolvers Message-ID: <4C68DF61.6080601@tiedyenetworks.com> Hi Folks, I am needing to renumber some core infrastructure - namely, my nameservers and my resolvers - and I was wondering if the collective wisdom still says heck yes keep this stuff all on seperate subnets away from eachother? Anyone got advice either way? Should I try to give sequential numbers to my resolvers for the benefit of consultants ... like .11, .22 and .33 for my server ips? Mike- From patrick at ianai.net Mon Aug 16 02:04:56 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 16 Aug 2010 08:04:56 +0100 Subject: Numbering nameservers and resolvers In-Reply-To: <4C68DF61.6080601@tiedyenetworks.com> References: <4C68DF61.6080601@tiedyenetworks.com> Message-ID: <91BA3752-118D-4284-A6C2-6E042A033D0B@ianai.net> Composed on a virtual keyboard, please forgive typos. On Aug 16, 2010, at 7:49, Mike wrote: > Hi Folks, > > I am needing to renumber some core infrastructure - namely, my nameservers and my resolvers - and I was wondering if the collective wisdom still says heck yes keep this stuff all on seperate subnets away from eachother? Anyone got advice either way? Should I try to give sequential numbers to my resolvers for the benefit of consultants ... like .11, .22 and .33 for my server ips? 1) Use different prefixes. A single prefix going down should not kill your entire network. (Nameservers and resolvers being unreachable breaks the whole Internet as far as users are concerned.) 2) Consider trading secondary NS with another AS. This is for authorities only, recursive NSes should be on-net only. 3) Try not to use the first /24 in a large prefix. See as7007 incident for why, although that is probably less likely today. 4) Using easily memorized numbers for at least one authority & one resolved will help your NOC, but should not override other considerations. That's a start, I'm sure others will have more suggestions. -- TTFN, patrick From aredridel at nbtsc.org Mon Aug 16 02:12:06 2010 From: aredridel at nbtsc.org (Aria Stewart) Date: Mon, 16 Aug 2010 01:12:06 -0600 Subject: Numbering nameservers and resolvers In-Reply-To: <4C68DF61.6080601@tiedyenetworks.com> References: <4C68DF61.6080601@tiedyenetworks.com> Message-ID: On Aug 16, 2010, at 12:49 AM, Mike wrote: > Hi Folks, > > I am needing to renumber some core infrastructure - namely, my nameservers and my resolvers - and I was wondering if the collective wisdom still says heck yes keep this stuff all on seperate subnets away from eachother? Anyone got advice either way? Should I try to give sequential numbers to my resolvers for the benefit of consultants ... like .11, .22 and .33 for my server ips? Resolvers being easily memorable is nice, since they get keyed in by IP. Authority servers are referred to by name, so IP matters less. Definitely keep an authority server in another prefix if you can, and resolvers in different prefixes is also nice -- but that's more a question of redundancy, not numbering. Other than that, go dense. Addresses are starting to get scarce. Aria Stewart From Valdis.Kletnieks at vt.edu Mon Aug 16 02:14:53 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 16 Aug 2010 03:14:53 -0400 Subject: Numbering nameservers and resolvers In-Reply-To: Your message of "Sun, 15 Aug 2010 23:49:05 PDT." <4C68DF61.6080601@tiedyenetworks.com> References: <4C68DF61.6080601@tiedyenetworks.com> Message-ID: <87849.1281942893@localhost> On Sun, 15 Aug 2010 23:49:05 PDT, Mike said: > I am needing to renumber some core infrastructure - namely, my > nameservers and my resolvers - and I was wondering if the collective > wisdom still says heck yes keep this stuff all on seperate subnets away > from eachother? Anyone got advice either way Microsoft used to have all their DNS servers on one /24. Nine years later, you can still use Google on just 'microsoft dns server failure subnet' and find this on the second page of over a million hits: http://www.wired.com/techbiz/media/news/2001/01/41423 (OK, so our local resolvers are in one /24, but it's a bridged VLAN across our entire campus, the servers are physically in buildings several miles apart, and if you can't reach at least one of them, it probably means our campus core network is hosed enough that you're not going to do anything with a DNS response anyhow... Our authoritative servers are split across 2 different AS's in 2 different states.) Whatever gave you the idea that collective wisdom could *possibly* have moved away from "spread it out as far as you can to avoid single points of failure"? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nanog-01 at jeremykister.com Mon Aug 16 02:19:25 2010 From: nanog-01 at jeremykister.com (Jeremy Kister) Date: Mon, 16 Aug 2010 03:19:25 -0400 Subject: Numbering nameservers and resolvers In-Reply-To: <4C68DF61.6080601@tiedyenetworks.com> References: <4C68DF61.6080601@tiedyenetworks.com> Message-ID: <4C68E67D.8030802@jeremykister.com> On 8/16/2010 2:49 AM, Mike wrote: > from eachother? Anyone got advice either way? Should I try to give If you have a dedicated subnet for /32s (e.g., router loopback interfaces), i'd pick from there. if you eventually require geo-redundancy or want to load balance your queries, it's much neater injecting them into your igp rather than having a few /32's injected from an otherwise nice clean /24. I am also a fan of keeping your recursive and authoritative ip addresses separate. Not only is this much more modular, it can be more secure; see http://cr.yp.to/djbdns/separation.html -- Jeremy Kister http://jeremy.kister.net./ From randy at psg.com Mon Aug 16 03:03:04 2010 From: randy at psg.com (Randy Bush) Date: Mon, 16 Aug 2010 17:03:04 +0900 Subject: Numbering nameservers and resolvers In-Reply-To: <4C68DF61.6080601@tiedyenetworks.com> References: <4C68DF61.6080601@tiedyenetworks.com> Message-ID: for authoritatuve servers, i try to have one on a very different backbone on a distant continent. i make deals with friends. there have been just too many failures where servers were in the same facility, or behind the same routing, or on a single backbone. see rfc 2182. for customer- and infrastructure-facing caches, i try for as different routing domains and peering/x-stream exits as i can while keeping them easily reachable by their clients. randy From ariev at vayner.net Mon Aug 16 03:08:31 2010 From: ariev at vayner.net (Arie Vayner) Date: Mon, 16 Aug 2010 11:08:31 +0300 Subject: Numbering nameservers and resolvers In-Reply-To: <4C68DF61.6080601@tiedyenetworks.com> References: <4C68DF61.6080601@tiedyenetworks.com> Message-ID: For resolvers, I guess it would make sense to advertise them as /32s as dynamic prefixes coming from some SLB device... You can have multiple VIPs, each representing a different POP/network domain... Arie On Mon, Aug 16, 2010 at 9:49 AM, Mike wrote: > Hi Folks, > > I am needing to renumber some core infrastructure - namely, my > nameservers and my resolvers - and I was wondering if the collective wisdom > still says heck yes keep this stuff all on seperate subnets away from > eachother? Anyone got advice either way? Should I try to give sequential > numbers to my resolvers for the benefit of consultants ... like .11, .22 and > .33 for my server ips? > > Mike- > > > From jeroen at unfix.org Mon Aug 16 04:09:19 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 16 Aug 2010 11:09:19 +0200 Subject: Numbering nameservers and resolvers In-Reply-To: <4C68DF61.6080601@tiedyenetworks.com> References: <4C68DF61.6080601@tiedyenetworks.com> Message-ID: <4C69003F.3050203@unfix.org> On 2010-08-16 08:49, Mike wrote: > Hi Folks, > > I am needing to renumber some core infrastructure - namely, my > nameservers and my resolvers - and I was wondering if the collective > wisdom still says heck yes keep this stuff all on seperate subnets away > from eachother? Anyone got advice either way? Should I try to give > sequential numbers to my resolvers for the benefit of consultants ... > like .11, .22 and .33 for my server ips? Take a IPv4 /24, /28, whatever size you might think you need and an IPv6 /64 and make it your 'service prefix', then anycast this inside your network and do the standard 'bgp daemon on the box, monitor the local service' trick and kill the announcement when the service does not work, presto. As for the actually numbers, just keep them simple. Using port-numbers (53 = DNS, 25 = SMTP etc etc etc) where possible is easy for at least the more technical folks, of course IPv4 only goes up to 255, IPv6 does not have that issue. Greets, Jeroen From jcurran at arin.net Mon Aug 16 05:33:54 2010 From: jcurran at arin.net (John Curran) Date: Mon, 16 Aug 2010 06:33:54 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> Message-ID: On Aug 16, 2010, at 1:44 AM, William Herrin wrote: > ... > The retort you want to make is that ARIN just wouldn't do that. That's > not the kind of people they are. Fine. So update the LRSA so it > doesn't carefully and pervasively establish ARIN's legal right to > behave that way. Bill - Divide and conquer... I will confirm with the Board that that is the intent of the LRSA (which would then allow us to initiate the task of changing the language accordingly); can you submit this as a suggestion so that this request is not accidentally lost or overlooked? Thanks! /John John Curran President and CEO ARIN From david.freedman at uk.clara.net Mon Aug 16 05:42:41 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Mon, 16 Aug 2010 11:42:41 +0100 Subject: BCP38 exceptions for RFC1918 space In-Reply-To: <87vd7bg8em.fsf@mid.deneb.enyo.de> References: <87vd7bg8em.fsf@mid.deneb.enyo.de> Message-ID: Florian Weimer wrote: > What's the current consensus on exempting private network space from > source address validation? Is it recommended? Discouraged? > > (One argument in favor of exceptions is that it makes PMTUD work if > transfer networks use private address space.) > > IMHO, operators who number infrastructure out of RFC1918 and then permit internet traceroutes over it are misguided and should consider avoiding TTL decrement (i.e using mpls without internet TTL propagation) as a less stressful (for us) alternative to simply filtering. Dave. -- David Freedman Group Network Engineering Claranet Group From harry.nanog at harry.lu Mon Aug 16 06:01:01 2010 From: harry.nanog at harry.lu (Harry Strongburg) Date: Mon, 16 Aug 2010 11:01:01 +0000 Subject: Geolocation tools - IPv6 style Message-ID: <20100816110101.GA30736@harry.lu> Hello NANOG, first time writing to here. My inquiry for you is on the subject of IPv6 Geolocation tools; or better yet, the lack accuracy in them. My main problem comes from YouTube.com and other Google Geolocation required tools (Google Voice, being an example). I must set network.dns.disableIPv6 to true just to access a lot of videos on YouTube, and to access my Google voice and similar services. I am unsure what country it thinks I am from when I access via IPv6, but it sure thinks I am foreign to the US. I understand that all Geolocation can, at most, point to the local routing station of that person's ISP. The current progress in the IPv6 field of geolocation is mostly pointing at countries, not even states or cities unlike IPv4. Is there something majorly different about the ability to track IPs in v6, than there was in v4? Or are the main producers of this data just busy / do not see IPv6 as being profitable / not worth their time? Another problem I have (which isn't really relevant to the subject, but if anyone has the same problem when loading via IPv6 I would be interested in hearing about it), would be the loading of YouTube content. Pages will seemingly load partially, and always be "Waiting on s.ytimg.com". http://s.ytimg.com/ loads instantly for me via IPv6, but not via videos. Has anyone else experenced the same problem? If I use v4 to load YouTube, the video instantly loads. There could be heavy load from my broker (he.net), but all other sites load instantly. Thanks for your time. From Valdis.Kletnieks at vt.edu Mon Aug 16 06:02:35 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 16 Aug 2010 07:02:35 -0400 Subject: BCP38 exceptions for RFC1918 space In-Reply-To: Your message of "Sun, 15 Aug 2010 19:02:50 +0200." <87y6c7erlx.fsf@mid.deneb.enyo.de> References: <87vd7bg8em.fsf@mid.deneb.enyo.de> <67328.1281889598@localhost> <87iq3bg6x2.fsf@mid.deneb.enyo.de> <69096.1281891438@localhost> <87y6c7erlx.fsf@mid.deneb.enyo.de> Message-ID: <131102.1281956555@localhost> On Sun, 15 Aug 2010 19:02:50 +0200, Florian Weimer said: > * Valdis Kletnieks: > > > On Sun, 15 Aug 2010 18:46:49 +0200, Florian Weimer said: > > > >> > And that connection that's trying to use PMTU got established across the > >> > commodity internet, how, exactly? ;) > >> > >> ICMP "fragmentation needed, but DF set" messages carry the a addresses > >> of intermediate routers which generate them (potentially in response > >> to MTU drops) as source addresses, not the IP addresses of the peers > >> in a connection. > > > > If any long-haul carriers are originating ICMP packets for other people's > > consumption from 1918 addresses rather than addresses in their address space, > > it's time to name-n-shame so the rest of us can vote with our feet and > > checkbooks. There's no excuse for that in this day and age. > > What does "originating" mean? Creating the packets? Or forwarding > them? Either way, there's no excuse. First off, remember that BCP38 and 1918 don't apply on your set of interconnected private networks, no matter how big a net it is. You want to filter between two of your private nets, go ahead. You don't want to, that's OK to. The fun starts when those packets leave your network(s) and hit the public Internet. Now that we have that squared away... Either that intermediate router originated the ICMP 'frag needed' packet, in which case somebody needs to be smacked for originating a 1918-addressed packet on the public internet, or it's forwarding the packet. And if it's forwarding the packet, then somebody *else* needs to be smacked for injecting that packet into the public internet. What *possible* use case would require a 1918-sourced packet to be traversing the public internet? We're all waiting with bated breath to hear this one. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jcurran at arin.net Mon Aug 16 06:02:58 2010 From: jcurran at arin.net (John Curran) Date: Mon, 16 Aug 2010 07:02:58 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> Message-ID: <68B176F7-FA03-4D91-8405-57A39CFC57F2@arin.net> On Aug 15, 2010, at 11:31 PM, Jeffrey Lyon wrote: > > Would the policy process be an appropriate venue for a proposition to > change the ARIN mission, restricting it's activities exclusively to > registration services while requiring a reduction in fees and budget? Jeffrey - Some historical perspective: ARIN not raised fees to my knowledge, but has actually lowered them 4 or 5 times over its 12 year history. ARIN's mission is set by the Board of Trustees, and lies within the purposes of the articles of incorporation of ARIN. I'll note that the articles encompass remarkable breadth, so the setting the mission turns out to be fairly important to keep ARIN focused appropriately. We have added initiatives in the past (e.g. this years extensive education and outreach regarding IPv4/IPv6) based on input received (predominantly at the Public Policy and Members meeting) and can remove them just as easily, but setting mission does not lie per se within the Policy process; it is a Board function to review and update the mission periodically. (Two minor notes: if you want an *ongoing* restraint on mission scope, it would really need be placed by the Board into the Bylaws with an significant hurdle precluding future revision, and should have some specificity, e.g. "exclusively registration services" could easily be read as either including or excluding abuse/fraud investigation, depending on the particular reader's inclination) /John John Curran President and CEO ARIN From jeroen at unfix.org Mon Aug 16 06:41:11 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 16 Aug 2010 13:41:11 +0200 Subject: Geolocation tools - IPv6 style In-Reply-To: <20100816110101.GA30736@harry.lu> References: <20100816110101.GA30736@harry.lu> Message-ID: <4C6923D7.3000808@unfix.org> On 2010-08-16 13:01, Harry Strongburg wrote: > Hello NANOG, first time writing to here. > > My inquiry for you is on the subject of IPv6 Geolocation tools; or > better yet, the lack accuracy in them. My main problem comes from > YouTube.com and other Google Geolocation required tools (Google Voice, > being an example). I must set network.dns.disableIPv6 to true just to > access a lot of videos on YouTube, and to access my Google voice and > similar services. I am unsure what country it thinks I am from when I > access via IPv6, but it sure thinks I am foreign to the US. [Well..... you do have a .lu domain in your email address] The moment you have the ability to go to amazon/ebay/$onlineshop and order all kinds of random junk and give your address to the retailers in question and this has been done enough all the geolocation database will be nicely filled after a while. Thus don't forget to provide all your private details in as many places as possible, the more they know about you, the better they can serve you. Just wait a few years and all will be fine, when IPv4 just started to be used there was none if this geolocation stuff either. Geolocation for restricting based on 'copyright regions' or similar things is the worst idea ever btw, especially as one can simply get a "VPS" with some VPN in the location that you need it and voila, you get around these silly restrictions, just like getting a .lu domain. Of course everybody knows&understands this except for layer 8 and up. Greets, Jeroen From jgreco at ns.sol.net Mon Aug 16 06:50:00 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 16 Aug 2010 06:50:00 -0500 (CDT) Subject: BCP38 exceptions for RFC1918 space In-Reply-To: <131102.1281956555@localhost> Message-ID: <201008161150.o7GBo08b044855@aurora.sol.net> > > What does "originating" mean? Creating the packets? Or forwarding > > them? > > Either way, there's no excuse. > > First off, remember that BCP38 and 1918 don't apply on your set of > interconnected private networks, no matter how big a net it is. You want to > filter between two of your private nets, go ahead. You don't want to, that's > OK to. The fun starts when those packets leave your network(s) and hit the > public Internet. > > Now that we have that squared away... > > Either that intermediate router originated the ICMP 'frag needed' packet, in > which case somebody needs to be smacked for originating a 1918-addressed packet > on the public internet, or it's forwarding the packet. And if it's forwarding > the packet, then somebody *else* needs to be smacked for injecting that packet > into the public internet. > > What *possible* use case would require a 1918-sourced packet to be traversing > the public internet? We're all waiting with bated breath to hear this one. ;) It's great for showing in traceroutes who the heel is. Do I win a prize? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jeffrey.lyon at blacklotus.net Mon Aug 16 07:01:07 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 16 Aug 2010 16:31:07 +0430 Subject: Lightly used IP addresses In-Reply-To: <68B176F7-FA03-4D91-8405-57A39CFC57F2@arin.net> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> <68B176F7-FA03-4D91-8405-57A39CFC57F2@arin.net> Message-ID: John, That was just the elevator speech, I wouldn't go off and write an entire proposal without a better understanding on how the community at large feels about the issue and exactly where the boundary would be drawn. My intent was not primarily cost, the registration fees are indeed low. I was just musing that limiting scope would have the ripple effect of reducing budget and thus putting more money in the hands of operators. It would be like a stimulus that doesn't cost any tax payer money ;). Best regards, Jeff On Mon, Aug 16, 2010 at 3:32 PM, John Curran wrote: > On Aug 15, 2010, at 11:31 PM, Jeffrey Lyon wrote: >> >> Would the policy process be an appropriate venue for a proposition to >> change the ARIN mission, restricting it's activities exclusively to >> registration services while requiring a reduction in fees and budget? > > Jeffrey - > > ?Some historical perspective: ARIN not raised fees to my knowledge, > ?but has actually lowered them 4 or 5 times over its 12 year history. > > ?ARIN's mission is set by the Board of Trustees, and lies within > ?the purposes of the articles of incorporation of ARIN. ?I'll note > ?that the articles encompass remarkable breadth, so the setting the > ?mission turns out to be fairly important to keep ARIN focused > ?appropriately. ?We have added initiatives in the past (e.g. this > ?years extensive education and outreach regarding IPv4/IPv6) based > ?on input received (predominantly at the Public Policy and Members > ?meeting) and can remove them just as easily, but setting mission > ?does not lie per se within the Policy process; it is a Board > ?function to review and update the mission periodically. > > ?(Two minor notes: if you want an *ongoing* restraint on mission > ?scope, it would really need be placed by the Board into the Bylaws > ?with an significant hurdle precluding future revision, and should > ?have some specificity, e.g. ?"exclusively registration services" > ?could easily be read as either including or excluding abuse/fraud > ?investigation, depending on the particular reader's inclination) > > /John > > John Curran > President and CEO > ARIN > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From owen at delong.com Mon Aug 16 07:04:09 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 16 Aug 2010 05:04:09 -0700 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> Message-ID: <0943D4FE-1D35-4EE1-987D-474A246834EC@delong.com> > > The retort you want to make is that ARIN just wouldn't do that. That's > not the kind of people they are. Fine. So update the LRSA so it > doesn't carefully and pervasively establish ARIN's legal right to > behave that way. John/Steve, Bill makes a reasonable point here. Is there a way to, in the next round of LRSA mods, include something to the effect of: Under the ARIN Policy Development Process, the board will not ratify any policy which exclusively affects LRSA signatories in a manner inconsistent with its effect on other resource holders. === That's probably not ideal wording, but, I hope it conveys the general idea and I hope smarter people can find better language. It does seem to me to be a reasonable request and consistent with the intent of the LRSA. If you prefer that I submit this via ACSP I will do so. However, it seems to me it could fall within the same scope as the other clarification John offered earlier. Owen From jcurran at arin.net Mon Aug 16 07:13:15 2010 From: jcurran at arin.net (John Curran) Date: Mon, 16 Aug 2010 08:13:15 -0400 Subject: Lightly used IP addresses In-Reply-To: <0943D4FE-1D35-4EE1-987D-474A246834EC@delong.com> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C675F5D.6070408@zill.net> <57FB98A0-E223-436D-BE1A-4284137287B8@delong.com> <0943D4FE-1D35-4EE1-987D-474A246834EC@delong.com> Message-ID: <03E3D716-41A6-497B-A05E-651ED70045CB@arin.net> On Aug 16, 2010, at 8:04 AM, Owen DeLong wrote: > > John/Steve, Just me (we don't pay Steve to read Nanog, although I do forward him legalistic emails depending on content :-) > Bill makes a reasonable point here. Is there a way to, in the next round of > LRSA mods, include something to the effect of: > > Under the ARIN Policy Development Process, the board will not ratify any > policy which exclusively affects LRSA signatories in a manner inconsistent > with its effect on other resource holders. > > === > > That's probably not ideal wording, but, I hope it conveys the general idea > and I hope smarter people can find better language. It does seem to me > to be a reasonable request and consistent with the intent of the LRSA. > > If you prefer that I submit this via ACSP I will do so. However, it seems to > me it could fall within the same scope as the other clarification John offered > earlier. I'll run with it, but would ask you send in to the suggestion process so that it doesn't get lost given our level of activity nowadays. Thanks! /John John Curran President and CEO ARIN From owen at delong.com Mon Aug 16 07:52:59 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 16 Aug 2010 05:52:59 -0700 Subject: Geolocation tools - IPv6 style In-Reply-To: <4C6923D7.3000808@unfix.org> References: <20100816110101.GA30736@harry.lu> <4C6923D7.3000808@unfix.org> Message-ID: <2006E91D-664C-4614-BBEF-7CC8CED9BBCB@delong.com> On Aug 16, 2010, at 4:41 AM, Jeroen Massar wrote: > On 2010-08-16 13:01, Harry Strongburg wrote: >> Hello NANOG, first time writing to here. >> >> My inquiry for you is on the subject of IPv6 Geolocation tools; or >> better yet, the lack accuracy in them. My main problem comes from >> YouTube.com and other Google Geolocation required tools (Google Voice, >> being an example). I must set network.dns.disableIPv6 to true just to >> access a lot of videos on YouTube, and to access my Google voice and >> similar services. I am unsure what country it thinks I am from when I >> access via IPv6, but it sure thinks I am foreign to the US. > > [Well..... you do have a .lu domain in your email address] > > The moment you have the ability to go to amazon/ebay/$onlineshop and > order all kinds of random junk and give your address to the retailers in > question and this has been done enough all the geolocation database will > be nicely filled after a while. > > Thus don't forget to provide all your private details in as many places > as possible, the more they know about you, the better they can serve you. > Wow... That's pretty absurd. I order stuff from Amazon/etc. from IP addresses all over the world to be shipped to my office or my home in California. Does that mean that the Geolocation things are getting confused about all of these IP addresses I use at random and moving them to California? If that's the case, no wonder Geolocation by IP is such a quagmire of inaccuracy. > Just wait a few years and all will be fine, when IPv4 just started to be > used there was none if this geolocation stuff either. > And even in IPv4 it's still wrong as often as not. > > Geolocation for restricting based on 'copyright regions' or similar > things is the worst idea ever btw, especially as one can simply get a > "VPS" with some VPN in the location that you need it and voila, you get > around these silly restrictions, just like getting a .lu domain. > Of course everybody knows&understands this except for layer 8 and up. > For once, Jeroen, I happen to agree with you, although I think you'd be surprised at the number of layer 4-7 people who actually don't get it. Owen From cmadams at hiwaay.net Mon Aug 16 08:03:36 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 16 Aug 2010 08:03:36 -0500 Subject: Numbering nameservers and resolvers In-Reply-To: <91BA3752-118D-4284-A6C2-6E042A033D0B@ianai.net> References: <4C68DF61.6080601@tiedyenetworks.com> <91BA3752-118D-4284-A6C2-6E042A033D0B@ianai.net> Message-ID: <20100816130336.GA703173@hiwaay.net> Once upon a time, Patrick W. Gilmore said: > 1) Use different prefixes. A single prefix going down should not kill > your entire network. (Nameservers and resolvers being unreachable > breaks the whole Internet as far as users are concerned.) How do you do this in the IPv6 world, where I get a single /32? Will others accept announcements of two /33s to better handle things like this? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From owen at delong.com Mon Aug 16 08:08:02 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 16 Aug 2010 06:08:02 -0700 Subject: Numbering nameservers and resolvers In-Reply-To: <20100816130336.GA703173@hiwaay.net> References: <4C68DF61.6080601@tiedyenetworks.com> <91BA3752-118D-4284-A6C2-6E042A033D0B@ianai.net> <20100816130336.GA703173@hiwaay.net> Message-ID: <20FD4DA8-112A-4BE8-BC7E-B58A16036D7D@delong.com> On Aug 16, 2010, at 6:03 AM, Chris Adams wrote: > Once upon a time, Patrick W. Gilmore said: >> 1) Use different prefixes. A single prefix going down should not kill >> your entire network. (Nameservers and resolvers being unreachable >> breaks the whole Internet as far as users are concerned.) > > How do you do this in the IPv6 world, where I get a single /32? Will > others accept announcements of two /33s to better handle things like > this? > The better solution is to trade secondary services with some other provider. Sure, it's a bit of a pain keeping up with the new zones to be added and old zones to be removed back and forth, but, it's a great way to have your authoritative servers truly diverse and independent. Owen From patrick at ianai.net Mon Aug 16 08:11:37 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 16 Aug 2010 09:11:37 -0400 Subject: Numbering nameservers and resolvers In-Reply-To: <20100816130336.GA703173@hiwaay.net> References: <4C68DF61.6080601@tiedyenetworks.com> <91BA3752-118D-4284-A6C2-6E042A033D0B@ianai.net> <20100816130336.GA703173@hiwaay.net> Message-ID: <281DEBF2-6DCE-41F5-A843-5E1973E622C4@ianai.net> On Aug 16, 2010, at 9:03 AM, Chris Adams wrote: > Once upon a time, Patrick W. Gilmore said: >> 1) Use different prefixes. A single prefix going down should not kill >> your entire network. (Nameservers and resolvers being unreachable >> breaks the whole Internet as far as users are concerned.) > > How do you do this in the IPv6 world, where I get a single /32? Will > others accept announcements of two /33s to better handle things like > this? Oooooooooobviously I was not thinking clearly, since I was only considering v4. =) But you do what you can. Some people have only a single v4 prefixes as well. If you can't use more than one prefix, then don't. Other good suggestions were things like ensuring the default exit point for each NS was a different vector. If you have only one exit point, that is not possible. But it does not mean the suggestion is bad. -- TTFN, patrick From ariev at vayner.net Mon Aug 16 08:11:19 2010 From: ariev at vayner.net (Arie Vayner) Date: Mon, 16 Aug 2010 16:11:19 +0300 Subject: Numbering nameservers and resolvers In-Reply-To: <20100816130336.GA703173@hiwaay.net> References: <4C68DF61.6080601@tiedyenetworks.com> <91BA3752-118D-4284-A6C2-6E042A033D0B@ianai.net> <20100816130336.GA703173@hiwaay.net> Message-ID: In IPv6 you should be able to advertise up to /48 with no problem... Arie On Mon, Aug 16, 2010 at 4:03 PM, Chris Adams wrote: > Once upon a time, Patrick W. Gilmore said: > > 1) Use different prefixes. A single prefix going down should not kill > > your entire network. (Nameservers and resolvers being unreachable > > breaks the whole Internet as far as users are concerned.) > > How do you do this in the IPv6 world, where I get a single /32? Will > others accept announcements of two /33s to better handle things like > this? > > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > > From Valdis.Kletnieks at vt.edu Mon Aug 16 08:26:56 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 16 Aug 2010 09:26:56 -0400 Subject: BCP38 exceptions for RFC1918 space In-Reply-To: Your message of "Mon, 16 Aug 2010 06:50:00 CDT." <201008161150.o7GBo08b044855@aurora.sol.net> References: <201008161150.o7GBo08b044855@aurora.sol.net> Message-ID: <135798.1281965216@localhost> On Mon, 16 Aug 2010 06:50:00 CDT, Joe Greco said: > > What *possible* use case would require a 1918-sourced packet to be traversing > > the public internet? We're all waiting with bated breath to hear this one. ;) > > It's great for showing in traceroutes who the heel is. Like I said, at that point it's name-n-shame time. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From franck at genius.com Mon Aug 16 08:39:47 2010 From: franck at genius.com (Franck Martin) Date: Tue, 17 Aug 2010 01:39:47 +1200 (FJT) Subject: Geolocation tools - IPv6 style In-Reply-To: <20100816110101.GA30736@harry.lu> Message-ID: <15489945.877.1281965985268.JavaMail.franck@franck-martins-macbook-pro.local> I have the feeling that the systems is not able to understand at all IPv6 for geolocation therefore default to "foreign". I'm not aware of anyone providing IPv6 geolocation at the moment? Anyone has pointers? ----- Original Message ----- From: "Harry Strongburg" To: nanog at nanog.org Sent: Monday, 16 August, 2010 11:01:01 PM Subject: Geolocation tools - IPv6 style Hello NANOG, first time writing to here. My inquiry for you is on the subject of IPv6 Geolocation tools; or better yet, the lack accuracy in them. My main problem comes from YouTube.com and other Google Geolocation required tools (Google Voice, being an example). I must set network.dns.disableIPv6 to true just to access a lot of videos on YouTube, and to access my Google voice and similar services. I am unsure what country it thinks I am from when I access via IPv6, but it sure thinks I am foreign to the US. I understand that all Geolocation can, at most, point to the local routing station of that person's ISP. The current progress in the IPv6 field of geolocation is mostly pointing at countries, not even states or cities unlike IPv4. Is there something majorly different about the ability to track IPs in v6, than there was in v4? Or are the main producers of this data just busy / do not see IPv6 as being profitable / not worth their time? Another problem I have (which isn't really relevant to the subject, but if anyone has the same problem when loading via IPv6 I would be interested in hearing about it), would be the loading of YouTube content. Pages will seemingly load partially, and always be "Waiting on s.ytimg.com". http://s.ytimg.com/ loads instantly for me via IPv6, but not via videos. Has anyone else experenced the same problem? If I use v4 to load YouTube, the video instantly loads. There could be heavy load from my broker (he.net), but all other sites load instantly. Thanks for your time. From jeroen at unfix.org Mon Aug 16 08:52:55 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 16 Aug 2010 15:52:55 +0200 Subject: Geolocation tools - IPv6 style In-Reply-To: <2006E91D-664C-4614-BBEF-7CC8CED9BBCB@delong.com> References: <20100816110101.GA30736@harry.lu> <4C6923D7.3000808@unfix.org> <2006E91D-664C-4614-BBEF-7CC8CED9BBCB@delong.com> Message-ID: <4C6942B7.9050207@unfix.org> On 2010-08-16 14:52, Owen DeLong wrote: [..] >> Thus don't forget to provide all your private details in as many places >> as possible, the more they know about you, the better they can serve you. >> > Wow... That's pretty absurd. I order stuff from Amazon/etc. from IP addresses > all over the world to be shipped to my office or my home in California. Does > that mean that the Geolocation things are getting confused about all of these > IP addresses I use at random and moving them to California? > > If that's the case, no wonder Geolocation by IP is such a quagmire of > inaccuracy. If you where actually running a larger site then you would know that having millions upon millions of customers returning from a certain range of addresses and providing their details which then match up give you a confidence factor, then just set that at factor X you locate that address down another level etc. Thus that one time that you go and order from some site and ship it home won't influence it all that much, as a hundred/thousand other people will have provided a more 'local' address to where that IP is used. Indeed, those systems cannot be 100% accurate, so what, if you tunnel it won't matter anyway. There are always ways around, it does work for most cases and that is what it is good enough for. [..] > For once, Jeroen, I happen to agree with you, although I think you'd be > surprised at the number of layer 4-7 people who actually don't get it. Let alone the supposed layer <3 people... Greets, Jeroen From jmaimon at ttec.com Mon Aug 16 08:57:51 2010 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 16 Aug 2010 09:57:51 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> Message-ID: <4C6943DF.4070702@ttec.com> Randy Bush wrote: > and why in hell would i trust these organizations with any control of > my routing via rpki certification? they have always said thay would > never be involved in routing, but if they control the certification > chain, they have a direct stranglehold they can use to extort fees. > Kind of interesting to consider how a successful implementation of RPKI might change the rules of this game we all play in. I tried talking about that at ARIN in Toronto, not certain I was clear enough. Joe From jmaimon at ttec.com Mon Aug 16 08:58:01 2010 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 16 Aug 2010 09:58:01 -0400 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C8F4.5070205@kl.net> Message-ID: <4C6943E9.1070606@ttec.com> Randy Bush wrote: >> Yet most of the bad ideas in the past 15 years have actually come from >> the IETF (TLA's, no end site multihoming, RA religion), some of which >> have actually been "fixed" by the RIR's. > > no, they were fixed within the ietf. that's my blood you are taking > about, and i know where and by whom it was spent. > > the fracking rirs, in the name of marla and and lee, actually went to > the ietf last month with a proposal to push address policy back to the > ietf from the ops. and they just did not get thomas's proposal to move > more policy from ietf back to ops. > > randy > I would appreciate it greatly if you could elaborate a bit more, perhaps with some links. Joe From patrick at vande-walle.eu Mon Aug 16 09:09:57 2010 From: patrick at vande-walle.eu (Patrick Vande Walle) Date: Mon, 16 Aug 2010 16:09:57 +0200 Subject: Geolocation tools - IPv6 style In-Reply-To: <15489945.877.1281965985268.JavaMail.franck@franck-martins-macbook-pro.local> References: <15489945.877.1281965985268.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <23ea722ab810e9172c767d5a45e3ec3c@localhost> On Tue, 17 Aug 2010 01:39:47 +1200 (FJT), Franck Martin wrote: > I have the feeling that the systems is not able to understand at all > IPv6 for geolocation therefore default to "foreign". > > I'm not aware of anyone providing IPv6 geolocation at the moment? > Anyone has pointers? Maxmind has an IPv6 database at http://www.maxmind.com/app/geolitecountry It is very rudimentary. Given that the number of native IPv6 connections on the residential market is still very limited, it will, at best, return the location of your tunnel provider. Not very useful right now, especially of your tunnel provider is not local to you. Patrick Vande Walle From jcurran at arin.net Mon Aug 16 10:01:10 2010 From: jcurran at arin.net (John Curran) Date: Mon, 16 Aug 2010 11:01:10 -0400 Subject: Lightly used IP addresses In-Reply-To: <4C6943DF.4070702@ttec.com> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C6943DF.4070702@ttec.com> Message-ID: Joe - Excellent question, and one which I know is getting some public policy attention. There is a session at upcoming Internet Governance Forum (IGF) in Vilnius specifically covering some of these issues. I also believe that some of the IETF sidr working group folks have noted the need for local policy support so that ISPs can decide to trust routes, even if not verifiable from their configured Trust Anchor. This is probably an essential control for most ISPs to have, even if never needed. /John John Curran President and CEO ARIN On Aug 16, 2010, at 9:57 AM, "Joe Maimon" wrote: > ... > > Kind of interesting to consider how a successful implementation of RPKI > might change the rules of this game we all play in. I tried talking > about that at ARIN in Toronto, not certain I was clear enough. > > Joe From lee at asgard.org Mon Aug 16 10:47:19 2010 From: lee at asgard.org (Lee Howard) Date: Mon, 16 Aug 2010 09:47:19 -0600 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C8F4.5070205@kl.net> Message-ID: <000001cb3d5a$503e6b10$f0bb4130$@org> > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Friday, August 13, 2010 10:13 PM > To: Kevin Loch > Cc: North American Network Operators Group > Subject: Re: Lightly used IP addresses > > > the fracking rirs, in the name of marla and and lee, actually went to > > the ietf last month with a proposal to push address policy back to the > > ietf from the ops. and they just did not get thomas's proposal to > > move more policy from ietf back to ops. You mischaracterize my position. Check the minutes when posted. Check the names on the draft. > and, to continue the red herring with jc, i bet you 500 yen that arin > paid their travel expenses to go to maastricht nl to do this stupid > thing. You lose your bet. Lee > randy From max.clark at gmail.com Mon Aug 16 11:40:11 2010 From: max.clark at gmail.com (Max Clark) Date: Mon, 16 Aug 2010 09:40:11 -0700 Subject: One Wilshire Radio Room Message-ID: Hello all, I'm looking for someone with space in the One Wilshire Radio Room. Please contact me off list. Thanks Max (310) 906-0296 max.clark at gmail.com From Valdis.Kletnieks at vt.edu Mon Aug 16 11:44:43 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 16 Aug 2010 12:44:43 -0400 Subject: Lightly used IP addresses In-Reply-To: Your message of "Mon, 16 Aug 2010 09:57:51 EDT." <4C6943DF.4070702@ttec.com> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C6943DF.4070702@ttec.com> Message-ID: <8657.1281977083@localhost> On Mon, 16 Aug 2010 09:57:51 EDT, Joe Maimon said: > Kind of interesting to consider how a successful implementation of RPKI > might change the rules of this game we all play in. I tried talking > about that at ARIN in Toronto, not certain I was clear enough. I'm not at all convinced this would help all that much. A PKI would allow better verification of authentication - but how many providers currently have doubts about who the other end of their BGP session is? I'm sure most of the ones who care have already set up TCPMD5 and/or TTL hacks, and the rest wouldn't deploy an RPKI. The real problem is authorization - and the same people who don't currently apply filtering of BGP announcements won't deploy a PKI. So the people who care already have other tools to do most of the work, and the ones who don't care won't deploy. Sure it may be nice and allow automation of some parts of the mess, but I'm not seeing a big window here for it being a game-changer. If somebody has a good case for how it *will* be a game-changer, I'm all ears. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From springer at inlandnet.com Mon Aug 16 11:47:00 2010 From: springer at inlandnet.com (John Springer) Date: Mon, 16 Aug 2010 09:47:00 -0700 (PDT) Subject: Lightly used IP addresses In-Reply-To: References: <20100813173652.84198.qmail@joyce.lan> <77CE0974-8CC1-4D83-8723-EF661A9D9BF0@delong.com> <20100813175554.GB7558@vacation.karoshi.com> <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> <20100813200658.GC8181@vacation.karoshi.com> <024484A8-FE17-4B2D-B059-5AAD4F4DC61B@arin.net> <20100813213942.GD8181@vacation.karoshi.com> <20100813220338.GN2582@sizone.org> Message-ID: <20100816094302.V2768@mail.inlandnet.com> On Sat, 14 Aug 2010, Frank Bulk wrote: > This week I was told by my sales person at Red Condor that I'm the only one > of his customers that is asking for IPv6. He sounded annoyed and it seemed > like he was trying to make me feel bad for being the "only oddball" pushing > the IPv6 feature requirement. FWIW, I asked the same question. My guy was polite, but w/o info. John Springer From jmaimon at ttec.com Mon Aug 16 12:59:38 2010 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 16 Aug 2010 13:59:38 -0400 Subject: Lightly used IP addresses In-Reply-To: <8657.1281977083@localhost> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C6943DF.4070702@ttec.com> <8657.1281977083@localhost> Message-ID: <4C697C8A.9070303@ttec.com> Valdis.Kletnieks at vt.edu wrote: > On Mon, 16 Aug 2010 09:57:51 EDT, Joe Maimon said: > >> Kind of interesting to consider how a successful implementation of RPKI >> might change the rules of this game we all play in. I tried talking >> about that at ARIN in Toronto, not certain I was clear enough. > > I'm not at all convinced this would help all that much. A PKI would allow > better verification of authentication - but how many providers currently have > doubts about who the other end of their BGP session is? I'm sure most of the > ones who care have already set up TCPMD5 and/or TTL hacks, and the rest > wouldn't deploy an RPKI. > > The real problem is authorization - and the same people who don't currently > apply filtering of BGP announcements won't deploy a PKI. > > So the people who care already have other tools to do most of the work, and > the ones who don't care won't deploy. Sure it may be nice and allow automation > of some parts of the mess, but I'm not seeing a big window here for it being > a game-changer. What you are saying is that you have doubts that there will be a successful implementation of RPKI that will properly secure BGP. > > If somebody has a good case for how it *will* be a game-changer, I'm all ears. However, Randy's point seemed me to be one I had brought up before. Can the RiR's still pass the theoretical fork test if RPKI were to be successfully and globally deployed? I am glad to hear that others who are likely far more competent than I are seriously examining the issue and seem to have similar concerns. The topic of this sub-thread isnt about the technological challenge of securing BGP and the routing of prefixes, it is about the political implications of successfully doing so and what the resulting impact on operations may be. Joe From dwhite at olp.net Mon Aug 16 13:01:43 2010 From: dwhite at olp.net (Dan White) Date: Mon, 16 Aug 2010 13:01:43 -0500 Subject: Lightly used IP addresses In-Reply-To: <20100816094302.V2768@mail.inlandnet.com> References: <26D0CF3D-AF95-4BCB-81D0-73B1C31772A7@arin.net> <20100813200658.GC8181@vacation.karoshi.com> <024484A8-FE17-4B2D-B059-5AAD4F4DC61B@arin.net> <20100813213942.GD8181@vacation.karoshi.com> <20100813220338.GN2582@sizone.org> <20100816094302.V2768@mail.inlandnet.com> Message-ID: <20100816180142.GD2654@dan.olp.net> On 16/08/10?09:47?-0700, John Springer wrote: > On Sat, 14 Aug 2010, Frank Bulk wrote: > >> This week I was told by my sales person at Red Condor that I'm the only one >> of his customers that is asking for IPv6. He sounded annoyed and it seemed >> like he was trying to make me feel bad for being the "only oddball" pushing >> the IPv6 feature requirement. > > FWIW, I asked the same question. My guy was polite, but w/o info. > > John Springer Hi Frank, I was actually told that there was some demand for it, and that they were targeting 2011 for support, which was acknowledged when I brought it up again in a difference conference call. I'll note that they just got bought out, which may change their priorities, for better or worse. -- Dan White From randy at psg.com Mon Aug 16 15:05:25 2010 From: randy at psg.com (Randy Bush) Date: Tue, 17 Aug 2010 05:05:25 +0900 Subject: Lightly used IP addresses In-Reply-To: <000001cb3d5a$503e6b10$f0bb4130$@org> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C8F4.5070205@kl.net> <000001cb3d5a$503e6b10$f0bb4130$@org> Message-ID: >> and, to continue the red herring with jc, i bet you 500 yen that arin >> paid their travel expenses to go to maastricht nl to do this stupid >> thing. > You lose your bet. then owe you 500Y. paypal? randy From randy at psg.com Mon Aug 16 15:46:49 2010 From: randy at psg.com (Randy Bush) Date: Tue, 17 Aug 2010 05:46:49 +0900 Subject: Lightly used IP addresses In-Reply-To: <8657.1281977083@localhost> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C6943DF.4070702@ttec.com> <8657.1281977083@localhost> Message-ID: >> Kind of interesting to consider how a successful implementation of >> RPKI might change the rules of this game we all play in. I tried >> talking about that at ARIN in Toronto, not certain I was clear >> enough. first, let's remember that the rpki is a distributed database which has a number of possible applications. the first technical application on the horizon is route origin validation. > I'm not at all convinced this would help all that much. A PKI would > allow better verification of authentication - but how many providers > currently have doubts about who the other end of their BGP session is? > I'm sure most of the ones who care have already set up TCPMD5 and/or > TTL hacks, and the rest wouldn't deploy an RPKI. route origin validation is not about authenticating your neighbor. it is about being able to base your routing policy on whether the origin asn of an announcement is authorized to originate a particular prefix. it is stopping fat fingers such as pk/youtube, 7007, and the every day accidental mis-announcements of others' prefixes. randy From dougb at dougbarton.us Mon Aug 16 17:47:38 2010 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 16 Aug 2010 15:47:38 -0700 Subject: Numbering nameservers and resolvers In-Reply-To: <4C68DF61.6080601@tiedyenetworks.com> References: <4C68DF61.6080601@tiedyenetworks.com> Message-ID: <4C69C00A.5050408@dougbarton.us> On 8/15/2010 11:49 PM, Mike wrote: > Hi Folks, > > I am needing to renumber some core infrastructure - namely, my > nameservers and my resolvers - and I was wondering if the collective > wisdom still says heck yes keep this stuff all on seperate subnets > away from eachother? Authoritative name servers should be on different networks, preferably in entirely different facilities. You've already had good suggestions about swapping secondary service, etc. Resolving name servers should be separate from authoritative ones, but there is no reason that they can't be on the same subnet(s). It's still a good idea to have more than one resolver on each local network, but there is also no reason they can't be on the same subnet as well. For larger and/or highly performance sensitive installations anycasting the resolvers (so that you only need 1 IP in resolv.conf) is becoming more popular. > Anyone got advice either way? Should I try to give sequential numbers > to my resolvers for the benefit of consultants ... like .11, .22 and > .33 for my server ips? This sounds more like a local preference issue. Presumably the people who don't type into config files for a living will have their hosts configured with DHCP, and those who do will know how to copy and paste. :) hth, Doug PS, if you need more formal help, see the URL below. -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From ekim.ittag at gmail.com Mon Aug 16 17:54:39 2010 From: ekim.ittag at gmail.com (Mike Gatti) Date: Mon, 16 Aug 2010 18:54:39 -0400 Subject: Fiber Cut in the DC Area Message-ID: <27E1E35C-3C8E-404F-BC1B-97E4B8A18DAF@gmail.com> Is anyone aware of a fiber cut that could be affecting the Washington DC area? Just opened a ticket with Verizon and heard of a fiber cut through some side conversations. -- Mike Gatti From nick at foobar.org Mon Aug 16 18:36:45 2010 From: nick at foobar.org (Nick Hilliard) Date: Tue, 17 Aug 2010 00:36:45 +0100 Subject: Lightly used IP addresses In-Reply-To: References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C6943DF.4070702@ttec.com> <8657.1281977083@localhost> Message-ID: <4C69CB8D.4000202@foobar.org> On 16/08/2010 21:46, Randy Bush wrote: > it is stopping fat fingers such as pk/youtube, 7007, and the every day > accidental mis-announcements of others' prefixes. I am dying to hear the explanation of why the people who didn't bother with irrdb filters are going to latch on en-masse to rpki thereby preventing a repeat of the 7007/youtube incidents. Nick From marka at isc.org Mon Aug 16 20:42:56 2010 From: marka at isc.org (Mark Andrews) Date: Tue, 17 Aug 2010 11:42:56 +1000 Subject: Lightly used IP addresses In-Reply-To: Your message of "Tue, 17 Aug 2010 00:36:45 +0100." <4C69CB8D.4000202@foobar.org> References: <8a2ulite6jhqsvisma4f4apy.1281730459934@email.android.com> <22641F3D-C0CB-479E-A16B-904A3FDECD8D@arin.net> <4C65C81C.5060809@kotovnik.com> <4C6943DF.4070702@ttec.com> <8657.1281977083@localhost> <4C69CB8D.4000202@foobar.org> Message-ID: <20100817014256.716DF311873@drugs.dv.isc.org> In message <4C69CB8D.4000202 at foobar.org>, Nick Hilliard writes: > On 16/08/2010 21:46, Randy Bush wrote: > > it is stopping fat fingers such as pk/youtube, 7007, and the every day > > accidental mis-announcements of others' prefixes. > > I am dying to hear the explanation of why the people who didn't bother > with irrdb filters are going to latch on en-masse to rpki thereby > preventing a repeat of the 7007/youtube incidents. More people will be willing to trust the databases if they know that they can be verified as (mostly) correct rather than hoping that they are correct. > Nick > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jared at puck.nether.net Mon Aug 16 22:39:02 2010 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 16 Aug 2010 23:39:02 -0400 Subject: Numbering nameservers and resolvers In-Reply-To: <20100816130336.GA703173@hiwaay.net> References: <4C68DF61.6080601@tiedyenetworks.com> <91BA3752-118D-4284-A6C2-6E042A033D0B@ianai.net> <20100816130336.GA703173@hiwaay.net> Message-ID: <2F4DA27A-89DB-421E-94F5-29CFF873122E@puck.nether.net> On Aug 16, 2010, at 9:03 AM, Chris Adams wrote: > Once upon a time, Patrick W. Gilmore said: >> 1) Use different prefixes. A single prefix going down should not kill >> your entire network. (Nameservers and resolvers being unreachable >> breaks the whole Internet as far as users are concerned.) > > How do you do this in the IPv6 world, where I get a single /32? Will > others accept announcements of two /33s to better handle things like > this? Everyone I know that is clued in this arena goes out and (even as a $sfi_network) BUYS transit/colo/somethingelse from another network (or does it via trade/barter/part of peering agreements, you get the idea). There are also people you can outsource this stuff to as well to make sure it's done right. Honestly, I'm surprised both at how many and how few people do this. Those that have the network capability pay someone else to do DNS at times, and those who should pay to have a reliable service hack it on some poor network infrastructure. Some people even provide an API or web interface to manage secondary dns servers to help out those in need. Try clicking here: http://www.google.com/search?q=free+secondary+dns - Jared From mpalmer at hezmatt.org Tue Aug 17 03:53:24 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Tue, 17 Aug 2010 18:53:24 +1000 Subject: Numbering nameservers and resolvers In-Reply-To: <20FD4DA8-112A-4BE8-BC7E-B58A16036D7D@delong.com> References: <4C68DF61.6080601@tiedyenetworks.com> <91BA3752-118D-4284-A6C2-6E042A033D0B@ianai.net> <20100816130336.GA703173@hiwaay.net> <20FD4DA8-112A-4BE8-BC7E-B58A16036D7D@delong.com> Message-ID: <20100817085324.GK11895@hezmatt.org> On Mon, Aug 16, 2010 at 06:08:02AM -0700, Owen DeLong wrote: > On Aug 16, 2010, at 6:03 AM, Chris Adams wrote: > > Once upon a time, Patrick W. Gilmore said: > >> 1) Use different prefixes. A single prefix going down should not kill > >> your entire network. (Nameservers and resolvers being unreachable > >> breaks the whole Internet as far as users are concerned.) > > > > How do you do this in the IPv6 world, where I get a single /32? Will > > others accept announcements of two /33s to better handle things like > > this? > > The better solution is to trade secondary services with some other > provider. Sure, it's a bit of a pain keeping up with the new zones > to be added and old zones to be removed back and forth, but, it's > a great way to have your authoritative servers truly diverse and > independent. At $JOB[3], where I was responsible for this sort of thing, a small amount of shell scripting behind inetd on the master[1], and slightly more shell scripting behind cron on the secondaries[2], and all our problems were solved for all time. - Matt [1] Read /etc/named/zones/* mangled the (standardised) filenames to get a list of the zones, and dumped it on stdout, which went out on a high port that inetd was listening on. [2] nc to the master on the relevant high port, read the list and write out an automated named.conf fragment. Also use a bit of md5sum to detect when the list changed, so we know when to reload named on the slave. [3] Subscript, not footnote. From sven at cb3rob.net Tue Aug 17 07:11:56 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Tue, 17 Aug 2010 12:11:56 +0000 (UTC) Subject: Numbering nameservers and resolvers In-Reply-To: <20100817085324.GK11895@hezmatt.org> References: <4C68DF61.6080601@tiedyenetworks.com> <91BA3752-118D-4284-A6C2-6E042A033D0B@ianai.net> <20100816130336.GA703173@hiwaay.net> <20FD4DA8-112A-4BE8-BC7E-B58A16036D7D@delong.com> <20100817085324.GK11895@hezmatt.org> Message-ID: nowadays, i'd simply put them all on the same /24 which you simply announce on different pops tcp/zonetransfer not working reliably is no longer a problem as you simply retreive those directly from the database over a seperate ip, no more old-fashioned bind related crap. so 1 /24 prefix, with one ip for your authorative nameserver, and maybe one for a resolver if needed, and the rest you leave unused.. this you simply put right next to the routers where you pick up your transit for transport to your own facilities (bet you have some rackspace and power left there too ;) making the network itself redundant rather than the nameserver... not to mention ofcourse that you fit these nameservers with solid state hdd's and ramdisks for the changing files and no moving parts so they last forever, and that whatever nameserver software you run is either an init child with respawn.. as these boxes are actually an integrated solid state router+nameserver, they have a normal static ip for the bgp/ospf session/routing and therefore can use this ip to retreive information themselves from the database and other nameservers once more and more parties buy/build routers with sufficient ram and therefore can handle larger routing tables (it's 2010 people, move on ;) you can also make the prefix smaller, let's say a /29.. our own setup is not yet a proper example here btw, so no bashing on that, but this is what our next setup will look like. kinda like ripes k-root, just used for ordinary authorative servers/resolvers pretty much plug and play (with ospf, with bgp it requires some additional configging ;) and nuke resistant, just the way we like it. this whole "you have to put 2 nameservers on two seperate subnets at two different locations" seems a bit.. pre-1993 to me. plus, why only 2, why not... 20 or so, all in different parts of the world and let bgp handle the rest. -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven at cb3rob.net ========================================================================= C3P0, der elektrische Westerwelle ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Tue, 17 Aug 2010, Matthew Palmer wrote: > On Mon, Aug 16, 2010 at 06:08:02AM -0700, Owen DeLong wrote: >> On Aug 16, 2010, at 6:03 AM, Chris Adams wrote: >>> Once upon a time, Patrick W. Gilmore said: >>>> 1) Use different prefixes. A single prefix going down should not kill >>>> your entire network. (Nameservers and resolvers being unreachable >>>> breaks the whole Internet as far as users are concerned.) >>> >>> How do you do this in the IPv6 world, where I get a single /32? Will >>> others accept announcements of two /33s to better handle things like >>> this? >> >> The better solution is to trade secondary services with some other >> provider. Sure, it's a bit of a pain keeping up with the new zones >> to be added and old zones to be removed back and forth, but, it's >> a great way to have your authoritative servers truly diverse and >> independent. > > At $JOB[3], where I was responsible for this sort of thing, a small amount > of shell scripting behind inetd on the master[1], and slightly more shell > scripting behind cron on the secondaries[2], and all our problems were > solved for all time. > > - Matt > > [1] Read /etc/named/zones/* mangled the (standardised) filenames to get a > list of the zones, and dumped it on stdout, which went out on a high port > that inetd was listening on. > > [2] nc to the master on the relevant high port, read the list and write out > an automated named.conf fragment. Also use a bit of md5sum to detect when > the list changed, so we know when to reload named on the slave. > > [3] Subscript, not footnote. > From jared at puck.nether.net Tue Aug 17 07:52:20 2010 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 17 Aug 2010 08:52:20 -0400 Subject: Numbering nameservers and resolvers In-Reply-To: References: <4C68DF61.6080601@tiedyenetworks.com> <91BA3752-118D-4284-A6C2-6E042A033D0B@ianai.net> <20100816130336.GA703173@hiwaay.net> <20FD4DA8-112A-4BE8-BC7E-B58A16036D7D@delong.com> <20100817085324.GK11895@hezmatt.org> Message-ID: <674901BB-EB6D-463E-8E1A-F78FFB14C577@puck.nether.net> Sven, On Aug 17, 2010, at 8:11 AM, Sven Olaf Kamphuis wrote: > this whole "you have to put 2 nameservers on two seperate subnets at two different locations" seems a bit.. pre-1993 to me. > plus, why only 2, why not... 20 or so, all in different parts of the world and let bgp handle the rest. There's an important component that is missing from the above. It's one thing to have a single nameserver hosted in such a manner, but through operational integration and history there are still a lot of domain names that are not fault tolerant. I remember "in recent years" a ccTLD that ended up without functioning services as a result of poor nameserver site selection. Ideally you would have a system with two geographically diverse nameservers for a domain, under seperate (routing) administrative control. One of my former employers backhauled all their legacy nameservers to a single site, eg: e[0-2].ns.voyager.net. While they were originally on diverse subnets and geographical locations, this appears to have changed. Selecting a site outside of your control is valuable. When I was hostmaster at cic.net, we "traded" with mr.net. These days, if I were in the same role, I would want to have three instead of two. Asia, Europe and US someplace. If US only, east, west and central. If you look at ntt.net, our "off-net" resolver is 69.36.249.36 This means if there is a ntt meltdown, there's a good chance you can still resolve related names off-net. - Jared From jgreco at ns.sol.net Tue Aug 17 07:53:36 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 17 Aug 2010 07:53:36 -0500 (CDT) Subject: Numbering nameservers and resolvers In-Reply-To: Message-ID: <201008171253.o7HCraVs061148@aurora.sol.net> > nowadays, i'd simply put them all on the same /24 which you simply > announce on different pops > > tcp/zonetransfer not working reliably is no longer a problem as you simply > retreive those directly from the database over a seperate ip, no more old-fashioned > bind related crap. tcp/zonetransfer can also be configured to run off of a different IP address, for example, the native IP of the box. This works just fine. In BIND, you're looking for transfer-source ${qaddr} port ${qport}; IIRC. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From cmadams at hiwaay.net Tue Aug 17 07:56:31 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 17 Aug 2010 07:56:31 -0500 Subject: Numbering nameservers and resolvers In-Reply-To: References: <4C68DF61.6080601@tiedyenetworks.com> <91BA3752-118D-4284-A6C2-6E042A033D0B@ianai.net> <20100816130336.GA703173@hiwaay.net> <20FD4DA8-112A-4BE8-BC7E-B58A16036D7D@delong.com> <20100817085324.GK11895@hezmatt.org> Message-ID: <20100817125631.GA947531@hiwaay.net> Once upon a time, Sven Olaf Kamphuis said: > tcp/zonetransfer not working reliably is no longer a problem as you simply > retreive those directly from the database over a seperate ip, no more > old-fashioned bind related crap. TCP is not just for zone transfers (especially in the age of DNSSEC and still-broken firewalls). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From tme at americafree.tv Tue Aug 17 08:07:18 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 17 Aug 2010 09:07:18 -0400 Subject: H.R. 3101: Twenty-first Century Communications Act Message-ID: This passed the House by 348-23 http://www.govtrack.us/congress/billtext.xpd?bill=h111-3101 While much of the focus is on closed captioning, there are several other pieces of this that SPs might be interested in. Here are two that strike me : SEC. 715. INTERNET PROTOCOL-BASED RELAY SERVICES. ?Within one year after the date of enactment of the Twenty-First Century Communications and Video Accessibility Act of 2010, each interconnected VoIP service provider and each provider of non-interconnected VoIP service shall participate in and contribute to the Telecommunications Relay Services Fund established in section 64.604(c)(5)(iii) of title 47, Code of Federal Regulations, as in effect on the date of enactment of such Act, in a manner prescribed by the Commission by regulation to provide for obligations of such providers that are consistent with and comparable to the obligations of other contributors to such Fund.?. ------ SEC. 201. VIDEO PROGRAMMING AND EMERGENCY ACCESS ADVISORY COMMITTEE. (e) (2) VIDEO DESCRIPTION, EMERGENCY INFORMATION, USER INTERFACES, AND VIDEO PROGRAMMING GUIDES AND MENUS- Within 18 months after the date of enactment of this Act, the Advisory Committee shall develop and submit to the Commission a report that includes the following: (A) An identification of the performance objectives for protocols, technical capabilities, and technical procedures needed to permit content providers, content distributors, Internet service providers, software developers, and device manufacturers to reliably encode, transport, receive, and render video descriptions of video programming and emergency information delivered using Internet protocol or digital broadcast television. Regards Marshall From jared at puck.nether.net Tue Aug 17 08:21:04 2010 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 17 Aug 2010 09:21:04 -0400 Subject: Numbering nameservers and resolvers In-Reply-To: <20100817125631.GA947531@hiwaay.net> References: <4C68DF61.6080601@tiedyenetworks.com> <91BA3752-118D-4284-A6C2-6E042A033D0B@ianai.net> <20100816130336.GA703173@hiwaay.net> <20FD4DA8-112A-4BE8-BC7E-B58A16036D7D@delong.com> <20100817085324.GK11895@hezmatt.org> <20100817125631.GA947531@hiwaay.net> Message-ID: On Aug 17, 2010, at 8:56 AM, Chris Adams wrote: > Once upon a time, Sven Olaf Kamphuis said: >> tcp/zonetransfer not working reliably is no longer a problem as you simply >> retreive those directly from the database over a seperate ip, no more >> old-fashioned bind related crap. > > TCP is not just for zone transfers (especially in the age of DNSSEC and > still-broken firewalls). Yeah. there's a lot of bad networking voodoo out there. I was on the NY State Thruway in recent weeks, and noticed a few things: 1) Don't query their website for an AAAA record, nor attempt to report it to the state. They say "we don't support IPv6" - not understanding sending back a SERVFAIL is bad 2) Don't expect 1.1.1.1 to work, they use that as a HTTPS portal, so you not only get broken IP, but a broken certificate login page 3) Comcast will sometimes reply from a "different" IP than you sent the query if the dns query fails in such a manner. - Jared From jgreco at ns.sol.net Tue Aug 17 08:26:08 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 17 Aug 2010 08:26:08 -0500 (CDT) Subject: Numbering nameservers and resolvers In-Reply-To: <674901BB-EB6D-463E-8E1A-F78FFB14C577@puck.nether.net> Message-ID: <201008171326.o7HDQ8DB061657@aurora.sol.net> > One of my former employers backhauled all their legacy nameservers to a = > single site, eg: e[0-2].ns.voyager.net. > > While they were originally on diverse subnets and geographical = > locations, this appears to have changed. As one of the people who originally worked on that setup, I'll note that they're all being announced by 7321, which is certainly not the ideal for purposes of diversity, but I notice some variation in the ping times, so it's not clear to me that there's a reliable basis for expecting that they're not at least diverse geographically. The original locations were in Dayton, Kalamazoo, and New Berlin, all of which are several ms away from Chicago, and while several of the facilities have been shuffled around or closed, it's not clear that there aren't still nameservers in those states. AS diversity wasn't there for all that long to begin with; I seem to recall that a lot of it was being announced from 8011 as the integration efforts went on. It seems to me that for very small or very large organizations, there are significant benefits to finding AS diversity, but for mid-size ones, the picture is a bit less clear. In the Voyager case, the existence of separate networks was something that came along as more of a bonus and side effect of acquistions, and nameserver engineering took advantage of it, but network engineering's goal was to get all the networks integrated and connected, so eventually things got rolled into 8011. That would definitely count as somewhat suboptimal from the point of nameserver reliability, but the network grew generally more reliable since there weren't twenty slightly different ways of doing things and lots of legacy crud that neteng needed to "just know". While that did a lot to increase the overall reliability of the network, it certainly is putting your eggs all in one basket, and then you have to be ready for the hazards. We had, for example, this guy in Michigan who liked to load up routers in remote locations with unreleased versions of Cisco code that he'd get from his contacts at Cisco, which led to several cases of network downtime when they didn't work as expected (or at all). I believe that Wisconsin network engineering was generally fearful that one day it would turn ugly and something bad would happen that would take down the whole network; this is the downside to having less compartmentalization. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From streiner at cluebyfour.org Tue Aug 17 06:29:50 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 17 Aug 2010 07:29:50 -0400 (EDT) Subject: Recycling old cabling? Message-ID: Just out of curiosity, is anyone here recycling old cabling and plant infrastructure for their raw materials, or engaging a recycler to handle those materials? Where I work, there is almost always a renovation project going on. This provides opportunities to rip out Cat3/Cat5/long-abandoned thicknet/thinnet/FDDI-grade fiber/etc, which we normally do. Most of the time that old cabling ends up in the dumpster, but I'm wondering if anyone is recycling it, either by their choice, or as the result of company policy or relevant laws in your area? Cat3/Cat5 can be broken down to raw materials with some effort, but I haven't seen many recyclers with an economically viable process for doing it. Coax is a bit tougher, but not impossible (same questions about economic viability still apply). Fiber can be tough, expecially if you're dealing with something like 20+ year old gel-buffered cable where the has long-since dried out. I'd be interested to hear other peoples' experiences along these lines. jms From jtk at cymru.com Tue Aug 17 10:48:21 2010 From: jtk at cymru.com (John Kristoff) Date: Tue, 17 Aug 2010 10:48:21 -0500 Subject: Numbering nameservers and resolvers In-Reply-To: References: <4C68DF61.6080601@tiedyenetworks.com> <91BA3752-118D-4284-A6C2-6E042A033D0B@ianai.net> <20100816130336.GA703173@hiwaay.net> <20FD4DA8-112A-4BE8-BC7E-B58A16036D7D@delong.com> <20100817085324.GK11895@hezmatt.org> Message-ID: <20100817104821.73c8cb7f@t61p> On Tue, 17 Aug 2010 12:11:56 +0000 (UTC) Sven Olaf Kamphuis wrote: > nowadays, i'd simply put them all on the same /24 which you simply > announce on different pops I would raise a red flag of caution with this approach especially for services that need to be reachable outside your network If there is a a snafu with said /24 prefix, particularly outside your own routing domain, a reachability problem could persist for an extended period and you'd be in a difficult position to solve it on your own. For instance, if it flaps and someone, for better or worse, dampens that route, that could mean an extended outage for all those hosts until the damping period timer expires. On a related note, some systems and folks have taken multiple unique origin ASNs as a measure of diversity. In pratice, unless there is some odd AS path mangling going on for your specific routes, which is unlikely, one can properly instrument diversity using a single origin ASN with multiple prefixes. Its the path and the prefix that matters, much less the ASN. John From jasongurtz at npumail.com Tue Aug 17 12:09:53 2010 From: jasongurtz at npumail.com (Jason Gurtz) Date: Tue, 17 Aug 2010 13:09:53 -0400 Subject: Recycling old cabling? In-Reply-To: References: Message-ID: > Just out of curiosity, is anyone here recycling old cabling and plant > infrastructure for their raw materials, or engaging a recycler to handle > those materials? There are places that will pay for and recycle old telecom wire. About 11 years ago I did some consulting work for a company that did just that, usually buying old wire by the railroad car-load and shipping it to a plant where it was chopped into little bits. The little bits then went through a vibrating process, where metal went one way, insulation another. Then the metal bits got sold via comex. An article I found mentioned that the front-end process was the toughest for the recyclers. I imagine, as an operator, the best path would be to call around to various scrap metal dealers and ask if one of these wire recyclers is in the area. I have no idea about the feasibility of fiber recycling. ~JasonG From bruns at 2mbit.com Tue Aug 17 12:16:05 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 17 Aug 2010 11:16:05 -0600 Subject: Recycling old cabling? In-Reply-To: References: Message-ID: <4C6AC3D5.7090307@2mbit.com> On 8/17/10 5:29 AM, Justin M. Streiner wrote: > Just out of curiosity, is anyone here recycling old cabling and plant > infrastructure for their raw materials, or engaging a recycler to handle > those materials? Where I work, there is almost always a renovation > project going on. This provides opportunities to rip out > Cat3/Cat5/long-abandoned thicknet/thinnet/FDDI-grade fiber/etc, which we > normally do. Most of the time that old cabling ends up in the dumpster, > but I'm wondering if anyone is recycling it, either by their choice, or > as the result of company policy or relevant laws in your area? Stripping out wiring and recycling it around here is actually a fairly good business - with buildings and offices changing hands from one major player to another, the new owner usually wants to gut the entire inside of the building and redo it their way. Given that Boise was once a pretty nice place to be for tech companies, and the downturn of the economy, the past two years has seen a spike in the recycling side of things. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From dougb at dougbarton.us Tue Aug 17 13:11:51 2010 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 17 Aug 2010 11:11:51 -0700 Subject: Numbering nameservers and resolvers In-Reply-To: References: <4C68DF61.6080601@tiedyenetworks.com> <91BA3752-118D-4284-A6C2-6E042A033D0B@ianai.net> <20100816130336.GA703173@hiwaay.net> <20FD4DA8-112A-4BE8-BC7E-B58A16036D7D@delong.com> <20100817085324.GK11895@hezmatt.org> Message-ID: <4C6AD0E7.9010409@dougbarton.us> On 08/17/2010 05:11, Sven Olaf Kamphuis wrote: > tcp/zonetransfer not working reliably is no longer a problem TCP is a MUST for DNS. It's used as a fallback in the normal resolution process if an answer can't fit in a UDP packet for whatever reason. This is true even for common things like large A record lists, but is only becoming more frequent in the age of DNSSEC, AAAA, etc. It is unfortunately even more necessary than we had hoped it would be due to many local network operators not "getting the memo" regarding EDNS. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From nick at brevardwireless.com Tue Aug 17 14:00:11 2010 From: nick at brevardwireless.com (Nick Olsen) Date: Tue, 17 Aug 2010 15:00:11 -0400 Subject: Numbering nameservers and resolvers Message-ID: <5235c050$22e0dd3$54bd756c$@com> So lets say that you have multiple DNS resolvers in the same ip space that you advertise from multiple locations. All would be fine for the most part. But if you had a location equidistant network wise from two POP's wouldn't it load balance and possibly break some TCP sessions? How would someone get around this? This is also what OpenDNS does from what I understand. Nick Olsen Network Operations (321) 205-1100 x106 ---------------------------------------- From: "Doug Barton" Sent: Tuesday, August 17, 2010 2:12 PM To: "Sven Olaf Kamphuis" Subject: Re: Numbering nameservers and resolvers On 08/17/2010 05:11, Sven Olaf Kamphuis wrote: > tcp/zonetransfer not working reliably is no longer a problem TCP is a MUST for DNS. It's used as a fallback in the normal resolution process if an answer can't fit in a UDP packet for whatever reason. This is true even for common things like large A record lists, but is only becoming more frequent in the age of DNSSEC, AAAA, etc. It is unfortunately even more necessary than we had hoped it would be due to many local network operators not "getting the memo" regarding EDNS. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From mksmith at adhost.com Tue Aug 17 14:30:46 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 17 Aug 2010 12:30:46 -0700 Subject: Brief NANOG Mailing Lists Outage - 8/18/2010 Message-ID: <17838240D9A5544AAA5FF95F8D52031608C8FE06@ad-exh01.adhost.lan> Hello All: This Wednesday morning at 7:00 a.m. EDT, Merit staff will replace the power supply on the NANOG server that operates the mailing lists. (The original power supply failed some time ago and was swapped for a part owned by a different project. In the operation on Wednesday, a new power supply will be installed.) This will result in a list outage that should last not more than 15 minutes if all goes well. Regards, Mike NANOG Communications Committee Chair From swmike at swm.pp.se Tue Aug 17 14:34:58 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 17 Aug 2010 21:34:58 +0200 (CEST) Subject: Numbering nameservers and resolvers In-Reply-To: <5235c050$22e0dd3$54bd756c$@com> References: <5235c050$22e0dd3$54bd756c$@com> Message-ID: On Tue, 17 Aug 2010, Nick Olsen wrote: > So lets say that you have multiple DNS resolvers in the same ip space that > you advertise from multiple locations. All would be fine for the most part. > But if you had a location equidistant network wise from two POP's wouldn't > it load balance and possibly break some TCP sessions? How would someone get > around this? This is also what OpenDNS does from what I understand. Usually network do not loadshare per-packet on BGP, so a TCP session will "always" go to the same dns server, at least for the short duration this TCP session lives. -- Mikael Abrahamsson email: swmike at swm.pp.se From hannes at mailcolloid.de Tue Aug 17 18:12:19 2010 From: hannes at mailcolloid.de (Hannes Frederic Sowa) Date: Wed, 18 Aug 2010 01:12:19 +0200 Subject: end-user ipv6 deployment and concerns about privacy Message-ID: Hello! As the first IPv6 deployments for end-users are in the planning stage in Germany, I realized I have not found any BCP for handling addressing in those scenarios. IPv6 will make it a lot easier for static address deployments but I wonder weather this is in the best sense for the customers. As I normally come from the technical side I prefer static addressing. But in the world of facebook and co. I wonder if it would be a better to let the user have the choice. A major provider of dsl here in Germany recently blogged about this [1]. Their proposal is to serve two subnets, one being a static one while the other one will be dynamically allocated. I have no clue how the user would switch between these subnets (without using some kind of command line tools). This is not about using privacy extensions as the subnet is sufficient for identification. Did you reach any conclusion on this matter? Thanks, Hannes [1] http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-8&layout=1&eotf=1&u=http://blog.1und1.de/2010/05/07/ipv6-totale-ueberwachung/&sl=de&tl=en From kompella at cs.purdue.edu Tue Aug 17 21:29:42 2010 From: kompella at cs.purdue.edu (Ramana Kompella) Date: Tue, 17 Aug 2010 22:29:42 -0400 Subject: CFP: COMSNETS 2011 Message-ID: <20100818022942.GA2730@tirupati> *** APOLOGIES IF YOUR RECEIVED MULTIPLE COPIES OF THE CFP *** COMSNETS 2011 The THIRD International Conference on COMunication Systems and NETworks January 4-8, 2011, Bangalore, India http://www.comsnets.org (In Co-operation with ACM SIGMOBILE) (Technically Co-Sponsored by IEEE COMSOC) The Third International Conference on COMmunication Systems and NETworkS (COMSNETS) will be held in Bangalore, India, from 4 January 2011 to 8 January 2011. COMSNETS is a premier international conference dedicated to addressing advances in Networking and Communications Systems, and Telecommunications services. The goal of the conference is to create a world-class gathering of researchers from academia and industry, practitioners, business leaders, intellectual property experts, and venture capitalists, providing a forum for discussing cutting edge research, and directions for new innovative business and technology. The conference will include a highly selective technical program consisting of parallel tracks of submitted papers, a small set of invited papers on important and timely topics from well-known leaders in the field, and poster sessions of work in progress. Focused workshops and panel discussions will be held on emerging topics to allow for a lively exchange of ideas. International business and government leaders will be invited to share their perspectives, thus complementing the technical program. Papers describing original research work and practical experiences/experimental results are solicited on topics including, but not limited to: Topics of Interest ------------------ Internet Architecture and Protocols Network-based Applications Video Distribution (IPTV, Mobile Video, Video on Demand) Network Operations and Management Broadband and Cellular Networks (3G/4G, WiMAX/LTE) Mesh, Sensor and PAN Networks Communication Software (Cognitive Radios, DSA, SDR) Wireless Operating Systems and Mobile Platforms Peer-to-peer Networking Cognitive Radio and White Space Networking Optical Networks Network Security & Cyber Security Technologies Cloud and Utility computing Storage Area Networks Next Generation Web Architectures Vehicular Networking Energy-Efficient Networking Network Science and Emergent Behavior in Socio-Technical Networks Social Networking Analysis, Middleware and Applications Networking Technologies for Smart Energy Grids Disruption/Delay Tolerant Networking Conference Highlights --------------------- Conference Inaugural Speaker: Prof. Pravin Varaiya, U. C. Berkeley, USA Banquet speaker: Dr. Rajeev Rastogi, Yahoo Research, India Keynote Speakers: Prof. Don Towsley, U. Mass Amherst, USA Dr. Pravin Bhagwat, AirTight Networks, India Dr. Jean Bolot, Sprint, USA Workshops WISARD (4, 5 Jan) NetHealth (4 Jan) IAMCOM (5 Jan) Mobile India 2011 (7 Jan) Technical Paper and Poster Sessions Ph.D Forum Panel Discussions Demos & Exhibits Important Deadlines ------------------- Paper submission: September 13, 2010 at 11:59 pm EDT (Sept 14, 9:29 am IST) Notification of Acceptance: November 8, 2010 Camera-Ready Submission: December 8, 2010 Detailed conference information and paper submission guidelines will soon be available on the conference web site. Please see http://www.comsnets.org for detailed information from time to time. The conference email address is: comsnets2011 at gmail.com General Co-Chairs ----------------- David B. Johnson, Rice University, USA Anurag Kumar, IISc Bangalore, India Technical Program Co-Chairs --------------------------- Jon Crowcroft, U. of Cambridge, UK D. Manjunath, IIT Bombay, India Archan Misra, Telcordia Tech., USA Steering Committee Co-Chairs ---------------------------- Uday Desai, IIT Hyderabad, India Giridhar Mandyam, Qualcomm, USA Sanjoy Paul, Infosys, India Rajeev Shorey, NIIT University, India G. Venkatesh, SASKEN, India Panel Co-Chairs --------------- Aditya Akella, U. of Wisconsin, USA Venkat Padmanabhan, MSR, India Ph.D Forum Chair ---------------- Bhaskaran Raman, IIT Bombay, India Publications Chair ------------------ Varsha Apte, IIT Bombay, India Demos and Exhibits Co-Chairs ---------------------------- Aaditeshwar Seth, IIT Delhi, India Ajay Bakre, Netapps, India Sponsorship Chair ----------------- Sudipta Maitra, Delhi, india Workshop Chairs --------------- Sharad Jaiswal, Alcatel-Lucent, India Ravindran Kaliappa, CUNY, USA Neelesh Mehta, IISc Bangalore, India Mobile India 2011 Co-Chairs --------------------------- Gulzar Azad, Google, India Gene Landy, Ruperto-Israel & Weiner, USA Rajaraghavan Setlur, SASKEN, India Sridhar Varadharajan, SASKEN, India Publicity Co-Chair ------------------ Augustin Chaintreau, TTL, France Kameswari Chebrolu, IIT Bombay, India Song Chong, KAIST, Korea Ramana Kompella, Purdue Univ, USA Nishanth Sastry, U. of Cambridge, UK Web Co-Chairs ------------- Santhana Krishnan, IIT Bombay, India Vinay Veerappa, SASKEN, India International Advisory Committee -------------------------------- K. K. Ramakrishnan, AT&T, USA Victor Bahl, Microsoft Research, USA Sunghyun Choi, Seoul National U., Korea Sajal Das, U. Texas at Arlington, USA B. N. Jain, IIT Delhi, India Anurag Kumar, IISc, Bangalore, India L. M. Patnaik, IISc, Bangalore, India Krithi Ramamritham, IIT Bombay, India Parmesh Ramanathan, U. Wisconsin, USA Krishan Sabnani, Alcatel-Lucent, USA Kang Shin, U. Michigan, USA Nitin Vaidya, U. Illinois, USA University Partners: -------------------- IIT Bombay, IIT Delhi, IISc Bangalore, IIT Hyderabad, NIIT University, IIIT Bangalore Patrons: -------- Mobile Monday Bangalore, Sasken, IBM Research, Alcatel Lucent From frank at fttx.org Wed Aug 18 00:08:49 2010 From: frank at fttx.org (Frank A. Coluccio) Date: Tue, 17 Aug 2010 22:08:49 -0700 Subject: Recycling old cabling? Message-ID: <20100817220849.68E39692@resin07.mta.everyone.net> All of the larger telcos and power utilities have been 're-smelting' copper for decades. Verizon (nee NY Telephone) had a copper smelting plant on Staten Island at one time that recycled all of the used cross-connect wire and cables removed from underground and poles. Telco main distribution frame personnel were, and very likely still are, instructed to use "copper-scrap" bags for depositing small bits and pieces of copper wiring collected at cleanup time at the end of work shifts. Many years ago, copper, for this reason, was one of the three "C"'s that no one would mess with. Copper and Cash were two.I'll leave the third one to the reader's imagination. This subject is interesting because it's one of the cost-justifiers in business models that seek to re-engineer large office buildings and other copper-intensive venues where the objective is to replace all copper wiring with hybrid fiber-wireless alternatives. While reclamation through salvage is only a by-product of this movement, it is nonetheless one that is cash intensive, so it cannot be overlooked. Not only is the copper data cabling removed (Cat3/5e/6, in this case), but also potentially tons of power cables and racks supporting sometimes hundreds of riser telecom/LAN closets, where there are usually anywhere from two to four closets per floor, depending on the size of the floor plate, in a forty- or sixty-story building, say. Every copper penny helps these days. --- streiner at cluebyfour.org wrote: From: "Justin M. Streiner" To: nanog at nanog.org Subject: Recycling old cabling? Date: Tue, 17 Aug 2010 07:29:50 -0400 (EDT) Just out of curiosity, is anyone here recycling old cabling and plant infrastructure for their raw materials, or engaging a recycler to handle those materials? Where I work, there is almost always a renovation project going on. This provides opportunities to rip out Cat3/Cat5/long-abandoned thicknet/thinnet/FDDI-grade fiber/etc, which we normally do. Most of the time that old cabling ends up in the dumpster, but I'm wondering if anyone is recycling it, either by their choice, or as the result of company policy or relevant laws in your area? Cat3/Cat5 can be broken down to raw materials with some effort, but I haven't seen many recyclers with an economically viable process for doing it. Coax is a bit tougher, but not impossible (same questions about economic viability still apply). Fiber can be tough, expecially if you're dealing with something like 20+ year old gel-buffered cable where the has long-since dried out. I'd be interested to hear other peoples' experiences along these lines. jms From swmike at swm.pp.se Wed Aug 18 00:12:29 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 18 Aug 2010 07:12:29 +0200 (CEST) Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: References: Message-ID: On Wed, 18 Aug 2010, Hannes Frederic Sowa wrote: > Did you reach any conclusion on this matter? Let the user choose. Here in Sweden we've for 10 years had ISPs offering static IPv4 address (either handed out via DHCP or just plain static with no dynamics what so ever) and some users prefer that, some don't. Some sell static IP as an extra option, some don't. For people who want to use DNS and run services, they'll most likely want a static address/subnet that doesn't change in the first place (even though it should be handed out via DHCPv6-PD for ease). If someone wants to be anonymous, there is always TOR or other anonymising services. Personally I prefer static for both IPv4 and IPv6 and have chosen providers accordingly historically. I also recommend this to others. -- Mikael Abrahamsson email: swmike at swm.pp.se From graham at apolix.co.za Wed Aug 18 00:41:17 2010 From: graham at apolix.co.za (Graham Beneke) Date: Wed, 18 Aug 2010 07:41:17 +0200 Subject: Numbering nameservers and resolvers In-Reply-To: <4C68DF61.6080601@tiedyenetworks.com> References: <4C68DF61.6080601@tiedyenetworks.com> Message-ID: <4C6B727D.4020608@apolix.co.za> On 16/08/2010 08:49, Mike wrote: > I am needing to renumber some core infrastructure - namely, my > nameservers and my resolvers - and I was wondering if the collective > wisdom still says heck yes keep this stuff all on seperate subnets away > from eachother? Anyone got advice either way? Should I try to give > sequential numbers to my resolvers for the benefit of consultants ... > like .11, .22 and .33 for my server ips? We have 4 authoritative nameservers with a management backend to make sure that their records are in sync. The servers are located on 3 separate continents, originated on 4 different ASNs, numbered from 4 different /8's and not sharing any common data centre or power infrastructure. The software platform is still a single point of failure and some people have recommended a mix of software vendors for additional redundancy. With resolvers the approach is a bit different: You want an easy to remember address and also an address that will not be subject to renumbering in the future. Even though they shouldn't we see many users statically configuring their DNS resolvers. A dedicated prefix for each resolver would be my first choice. You can then move that prefix to different hardware if necessary even if the routing to the hardware changes. A dedicated prefix also allows you to anycast the service if required. Since this is only internal routing it doesn't need to be a full /24. I have also found it helpful to have the upstream queries originating from IPs in separate prefixes and this is quite easy to move around transparently to users or even in an emergency. On IPv6 I have reserved 4 x /48s for DNS resolvers. The prefixes were chosen to be short and easy to remember and they are routed to existing resolvers. The :1 of each prefix is added to the loopback on the resolver. -- Graham Beneke From marcoh at marcoh.net Wed Aug 18 00:53:07 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 18 Aug 2010 07:53:07 +0200 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: References: Message-ID: On 18 aug 2010, at 01:12, Hannes Frederic Sowa wrote: > prefer static addressing. But in the world of facebook and co. I > wonder if it would be a better to let the user have the choice. A What does facebook have to do with it ? Ever heard of cookies ? MarcoH From jeffrey.lyon at blacklotus.net Wed Aug 18 01:05:30 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 18 Aug 2010 10:35:30 +0430 Subject: Recycling old cabling? In-Reply-To: <20100817220849.68E39692@resin07.mta.everyone.net> References: <20100817220849.68E39692@resin07.mta.everyone.net> Message-ID: I know of a guy that was terminated for "stealing" CAT5 that he was instructed to throw in the dumpster. Jeff On Wed, Aug 18, 2010 at 9:38 AM, Frank A. Coluccio wrote: > ? All of the larger telcos and power utilities have been 're-smelting' > ? copper for decades. Verizon (nee NY Telephone) had a copper smelting > ? plant on Staten Island at one time that recycled all of the used > ? cross-connect wire and cables removed from underground and poles. Telco > ? main distribution frame personnel were, and very likely still are, > ? instructed to use "copper-scrap" bags for depositing small bits and > ? pieces of copper wiring collected at cleanup time at the end of work > ? shifts. Many years ago, copper, for this reason, was one of the three > ? "C"'s that no one would mess with. Copper and Cash were two.I'll leave > ? the third one to the reader's imagination. > ? This subject is interesting because it's one of the cost-justifiers in > ? business models that seek to re-engineer large office buildings and > ? other copper-intensive venues where the objective is to replace all > ? copper wiring with hybrid fiber-wireless alternatives. While > ? reclamation through salvage is only a by-product of this movement, it > ? is nonetheless one that is cash intensive, so it cannot be overlooked. > ? Not only is the copper data cabling removed (Cat3/5e/6, in this case), > ? but also potentially tons of power cables and racks supporting > ? sometimes hundreds of riser telecom/LAN closets, where there are > ? usually anywhere from two to four closets per floor, depending on the > ? size of the floor plate, in a forty- or sixty-story building, say. > ? Every copper penny helps these days. > ? --- streiner at cluebyfour.org wrote: > ? From: "Justin M. Streiner" > ? To: nanog at nanog.org > ? Subject: Recycling old cabling? > ? Date: Tue, 17 Aug 2010 07:29:50 -0400 (EDT) > ? Just out of curiosity, is anyone here recycling old cabling and plant > ? infrastructure for their raw materials, or engaging a recycler to > ? handle > ? those materials? ?Where I work, there is almost always a renovation > ? project going on. ?This provides opportunities to rip out > ? Cat3/Cat5/long-abandoned thicknet/thinnet/FDDI-grade fiber/etc, which > ? we > ? normally do. ?Most of the time that old cabling ends up in the > ? dumpster, > ? but I'm wondering if anyone is recycling it, either by their choice, or > ? as > ? the result of company policy or relevant laws in your area? > ? Cat3/Cat5 can be broken down to raw materials with some effort, but I > ? haven't seen many recyclers with an economically viable process for > ? doing > ? it. ?Coax is a bit tougher, but not impossible (same questions about > ? economic viability still apply). ?Fiber can be tough, expecially if > ? you're > ? dealing with something like 20+ year old gel-buffered cable where the > ? has > ? long-since dried out. > ? I'd be interested to hear other peoples' experiences along these lines. > ? jms > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From khatfield at socllc.net Wed Aug 18 01:38:12 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Wed, 18 Aug 2010 06:38:12 +0000 Subject: Recycling old cabling? In-Reply-To: References: <20100817220849.68E39692@resin07.mta.everyone.net> Message-ID: <1885992790-1282113493-cardhu_decombobulator_blackberry.rim.net-1687831139-@bda903.bisx.prod.on.blackberry> It's pretty standard for any company to terminate upon taking something without permission. I worked with a company that threw away / recycled nearly an entire 100k sq. foot datacenter. All of the gear still in working order. It's just one those things... Your employer tells you to throw it away... It's best to throw it away and not try to take it home :) We (employees) could request specific pieces but the majority was thrown out. Kind of crazy to see entire Cisco lab environments trashed but it's not uncommon and trash or not, still stealing. As far as the original question: More companies recycle and properly dispose of equipment than they did ten years ago. Yet, if they aren't being looked at to be "green" or something along those lines then many choose the cheapest route (the dumpster). Per the note by Jeff, it's not recommended to try to take it into your own hands. Your best bet would be to approach your employer with a recommendation that you feel may be more cost-effective or environmentally friendly. -----Original Message----- From: Jeffrey Lyon Date: Wed, 18 Aug 2010 10:35:30 To: Subject: Re: Recycling old cabling? I know of a guy that was terminated for "stealing" CAT5 that he was instructed to throw in the dumpster. Jeff On Wed, Aug 18, 2010 at 9:38 AM, Frank A. Coluccio wrote: > ? All of the larger telcos and power utilities have been 're-smelting' > ? copper for decades. Verizon (nee NY Telephone) had a copper smelting > ? plant on Staten Island at one time that recycled all of the used > ? cross-connect wire and cables removed from underground and poles. Telco > ? main distribution frame personnel were, and very likely still are, > ? instructed to use "copper-scrap" bags for depositing small bits and > ? pieces of copper wiring collected at cleanup time at the end of work > ? shifts. Many years ago, copper, for this reason, was one of the three > ? "C"'s that no one would mess with. Copper and Cash were two.I'll leave > ? the third one to the reader's imagination. > ? This subject is interesting because it's one of the cost-justifiers in > ? business models that seek to re-engineer large office buildings and > ? other copper-intensive venues where the objective is to replace all > ? copper wiring with hybrid fiber-wireless alternatives. While > ? reclamation through salvage is only a by-product of this movement, it > ? is nonetheless one that is cash intensive, so it cannot be overlooked. > ? Not only is the copper data cabling removed (Cat3/5e/6, in this case), > ? but also potentially tons of power cables and racks supporting > ? sometimes hundreds of riser telecom/LAN closets, where there are > ? usually anywhere from two to four closets per floor, depending on the > ? size of the floor plate, in a forty- or sixty-story building, say. > ? Every copper penny helps these days. > ? --- streiner at cluebyfour.org wrote: > ? From: "Justin M. Streiner" > ? To: nanog at nanog.org > ? Subject: Recycling old cabling? > ? Date: Tue, 17 Aug 2010 07:29:50 -0400 (EDT) > ? Just out of curiosity, is anyone here recycling old cabling and plant > ? infrastructure for their raw materials, or engaging a recycler to > ? handle > ? those materials? ?Where I work, there is almost always a renovation > ? project going on. ?This provides opportunities to rip out > ? Cat3/Cat5/long-abandoned thicknet/thinnet/FDDI-grade fiber/etc, which > ? we > ? normally do. ?Most of the time that old cabling ends up in the > ? dumpster, > ? but I'm wondering if anyone is recycling it, either by their choice, or > ? as > ? the result of company policy or relevant laws in your area? > ? Cat3/Cat5 can be broken down to raw materials with some effort, but I > ? haven't seen many recyclers with an economically viable process for > ? doing > ? it. ?Coax is a bit tougher, but not impossible (same questions about > ? economic viability still apply). ?Fiber can be tough, expecially if > ? you're > ? dealing with something like 20+ year old gel-buffered cable where the > ? has > ? long-since dried out. > ? I'd be interested to hear other peoples' experiences along these lines. > ? jms > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From swmike at swm.pp.se Wed Aug 18 01:45:15 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 18 Aug 2010 08:45:15 +0200 (CEST) Subject: Recycling old cabling? In-Reply-To: <1885992790-1282113493-cardhu_decombobulator_blackberry.rim.net-1687831139-@bda903.bisx.prod.on.blackberry> References: <20100817220849.68E39692@resin07.mta.everyone.net> <1885992790-1282113493-cardhu_decombobulator_blackberry.rim.net-1687831139-@bda903.bisx.prod.on.blackberry> Message-ID: On Wed, 18 Aug 2010, khatfield at socllc.net wrote: > More companies recycle and properly dispose of equipment than they did > ten years ago. Yet, if they aren't being looked at to be "green" or > something along those lines then many choose the cheapest route (the > dumpster). The amazing thing is sometimes they will pay to have it trashed instead of the option of a recycler/reseller coming around and picking it up at no cost. As you said, it's just one of those things. -- Mikael Abrahamsson email: swmike at swm.pp.se From hannes at mailcolloid.de Wed Aug 18 02:35:42 2010 From: hannes at mailcolloid.de (Hannes Frederic Sowa) Date: Wed, 18 Aug 2010 09:35:42 +0200 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: References: Message-ID: On Wed, Aug 18, 2010 at 7:53 AM, Marco Hogewoning wrote: > > On 18 aug 2010, at 01:12, Hannes Frederic Sowa wrote: > >> prefer static addressing. But in the world of facebook and co. I >> wonder if it would be a better to let the user have the choice. A > > What does facebook have to do with it ? Ever heard of cookies ? Facebook as an example of a company whose founder stated that privacy is old-fashioned. Cookies sit on another network-layer I am currently not talking about. They can be removed more easily, most simply by reinstalling your computer. The user *can* do something about cookies. From hannes at mailcolloid.de Wed Aug 18 02:39:50 2010 From: hannes at mailcolloid.de (Hannes Frederic Sowa) Date: Wed, 18 Aug 2010 09:39:50 +0200 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: References: Message-ID: On Wed, Aug 18, 2010 at 7:12 AM, Mikael Abrahamsson wrote: > For people who want to use DNS and run services, they'll most likely want a > static address/subnet that doesn't change in the first place (even though it > should be handed out via DHCPv6-PD for ease). If someone wants to be > anonymous, there is always TOR or other anonymising services. Tor is fairly slow using it for every days internet surfing. Why don't have sensible defaults for most users as default. For them I don't see a need for static prefixes. > Personally I prefer static for both IPv4 and IPv6 and have chosen providers > accordingly historically. I also recommend this to others. On the technical side it is clear. Static is the way to go. From jfbeam at gmail.com Wed Aug 18 03:24:41 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 18 Aug 2010 04:24:41 -0400 Subject: Recycling old cabling? In-Reply-To: <1885992790-1282113493-cardhu_decombobulator_blackberry.rim.net-1687831139-@bda903.bisx.prod.on.blackberry> References: <20100817220849.68E39692@resin07.mta.everyone.net> <1885992790-1282113493-cardhu_decombobulator_blackberry.rim.net-1687831139-@bda903.bisx.prod.on.blackberry> Message-ID: On Wed, 18 Aug 2010 02:38:12 -0400, wrote: > I worked with a company that threw away / recycled nearly an entire 100k > sq. foot datacenter. All of the gear still in working order. It's just > one those things... There are constraints beyond the logic of "common sense". And it flows from the accounting department :-) A former employer had a bunch of old PCs replaced. The old ones, for "tax reasons", had to be destroyed. Which meant they had to go in the dumpster. What happens to them after that is not my concern; I won't even notice if they aren't in there when the truck comes to empty that dumpster. Do what NCSU's ACS ("the hall of records") used to do... post to the news groups when ever they had anything "interesting" to throw away. In today's world, throwing a computer in a dumpster (headed to a landfill) is illegal just about everywhere. esp. CA. --Ricky From marcoh at marcoh.net Wed Aug 18 03:37:58 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 18 Aug 2010 10:37:58 +0200 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: References: Message-ID: <9AC46CA6-B23E-4CCE-8DA8-BA8A29C49840@marcoh.net> On 18 aug 2010, at 09:35, Hannes Frederic Sowa wrote: > On Wed, Aug 18, 2010 at 7:53 AM, Marco Hogewoning wrote: >> >> On 18 aug 2010, at 01:12, Hannes Frederic Sowa wrote: >> >>> prefer static addressing. But in the world of facebook and co. I >>> wonder if it would be a better to let the user have the choice. A >> >> What does facebook have to do with it ? Ever heard of cookies ? > > Facebook as an example of a company whose founder stated that privacy > is old-fashioned. Cookies sit on another network-layer I am currently > not talking about. They can be removed more easily, most simply by > reinstalling your computer. The user *can* do something about cookies. Yeah but given the amount of NAT and dynamic addresses around in v4 land. I think it's highly unlikely you are better of tracking v4 addresses instead of pushing cookies, especially as most 2.0 sites require a login anyway. Groet, MarcoH From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Aug 18 05:34:47 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 18 Aug 2010 20:04:47 +0930 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: References: Message-ID: <20100818200447.162288b6@opy.nosense.org> On Wed, 18 Aug 2010 01:12:19 +0200 Hannes Frederic Sowa wrote: > Hello! > > As the first IPv6 deployments for end-users are in the planning stage > in Germany, I realized I have not found any BCP for handling > addressing in those scenarios. IPv6 will make it a lot easier for > static address deployments but I wonder weather this is in the best > sense for the customers. As I normally come from the technical side I > prefer static addressing. But in the world of facebook and co. I > wonder if it would be a better to let the user have the choice. A > major provider of dsl here in Germany recently blogged about this [1]. > Their proposal is to serve two subnets, one being a static one while > the other one will be dynamically allocated. I have no clue how the > user would switch between these subnets (without using some kind of > command line tools). > > This is not about using privacy extensions as the subnet is sufficient > for identification. > > Did you reach any conclusion on this matter? > Haven't really thought about it before. One thing to consider is that unless the preferred and valid lifetimes of an IPv6 prefix are set to infinity, IPv6 prefixes are always dynamic - they'll eventually expire unless they're refreshed. The preferred and valid lifetimes for prefixes that are delegated to customers could be something that they might be able to change via a web portal, bounded to within what you as an ISP are happy with e.g. 1 to 30 days, rather than the absolute range of lifetime values supported. CPE could also potentially do the same thing with the range of subnets it has been delegated, by phasing in and out subnets over time on it's downstream interfaces. (The more subnets the better, so a /48 would be ideal for this.) As you've mentioned, privacy addresses help. A related idea is described in "Transient addressing for related processes: Improved firewalling by using IPv6 and multiple addresses per host." [0], Peter M. Gleitz and Steven M. Bellovin, which takes advantage of the 2^64 addresses in a /64, and has different applications on the same host use different source IPv6 addresses. Pretending to be multiple hosts, or even just one with privacy addresses, moving around multiple subnets, on delegated prefixes that change fairly regularly would probably mitigate quite a lot of the privacy concerns people may have related to IPv6 addressing. Regards, Mark. [0] http://www.cs.columbia.edu/~smb/papers/tarp.pdf From rs at seastrom.com Wed Aug 18 08:37:09 2010 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 18 Aug 2010 09:37:09 -0400 Subject: Numbering nameservers and resolvers In-Reply-To: (Mikael Abrahamsson's message of "Tue, 17 Aug 2010 21:34:58 +0200 (CEST)") References: <5235c050$22e0dd3$54bd756c$@com> Message-ID: <86k4norqii.fsf@seastrom.com> Mikael Abrahamsson writes: > On Tue, 17 Aug 2010, Nick Olsen wrote: > >> So lets say that you have multiple DNS resolvers in the same ip space that >> you advertise from multiple locations. All would be fine for the most part. >> But if you had a location equidistant network wise from two POP's wouldn't >> it load balance and possibly break some TCP sessions? How would someone get >> around this? This is also what OpenDNS does from what I understand. > > Usually network do not loadshare per-packet on BGP, so a TCP session > will "always" go to the same dns server, at least for the short > duration this TCP session lives. Occasionally I have seen networks (usually small dual-homed ones) that attempt to equally utilize their network pipes by doing per-packet bgp load balancing to both upstreams. Then they wonder why their performance is so irregular. :-) -r From hannes at mailcolloid.de Wed Aug 18 09:18:00 2010 From: hannes at mailcolloid.de (Hannes Frederic Sowa) Date: Wed, 18 Aug 2010 16:18:00 +0200 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: <20100818200447.162288b6@opy.nosense.org> References: <20100818200447.162288b6@opy.nosense.org> Message-ID: On Wed, Aug 18, 2010 at 12:34 PM, Mark Smith wrote: > Haven't really thought about it before. > > One thing to consider is that unless the preferred and valid lifetimes > of an IPv6 prefix are set to infinity, IPv6 prefixes are always dynamic > - they'll eventually expire unless they're refreshed. The preferred and > valid lifetimes for prefixes that are delegated to customers could be > something that they might be able to change via a web portal, bounded > to within what you as an ISP are happy with e.g. 1 to 30 days, rather > than the absolute range of lifetime values supported. CPE could also > potentially do the same thing with the range of subnets it has been > delegated, by phasing in and out subnets over time on it's downstream > interfaces. (The more subnets the better, so a /48 would be ideal for > this.) Yep, I am in favour of such setups. This will stress internal name services(eg. netbios) but would be a solvable problem, I think. > As you've mentioned, privacy addresses help. A related idea is > described in "Transient addressing for related processes: Improved > firewalling by using IPv6 and multiple addresses per host." [0], Peter > M. Gleitz and Steven M. Bellovin, which takes advantage of the 2^64 > addresses in a /64, and has different applications on the same host use > different source IPv6 addresses. > > Pretending to be multiple hosts, or even just one with privacy > addresses, moving around multiple subnets, on delegated prefixes that > change fairly regularly would probably mitigate quite a lot of the > privacy concerns people may have related to IPv6 addressing. If your ipv6-geolocation-service tells you that all /48 prefixes behind this network are just static home-user networks, why not just ignore the lower 64 bits or even the lower 80 bits? Privacy extensions would be no help here. In IPv4-land I have the possibility to reconnect and get a new unrelated ip-address every time. hannes From joesox at gmail.com Wed Aug 18 13:54:40 2010 From: joesox at gmail.com (JoeSox) Date: Wed, 18 Aug 2010 11:54:40 -0700 Subject: iPhone updates and required bandwidth Message-ID: Am I the only one that gets ticked off at the Apple iPhone update procedure and the amount of bandwidth it needs? Is there any secret I am missing to cut down on the required bandwidth needed for it (caching the update somewhere etc)? I don't own an iPhone (DroidX user here) and am unfamiliar with the update, all I know is it uses tons of BW. -- Thanks, Joe From Greg.Whynott at oicr.on.ca Wed Aug 18 14:03:26 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Wed, 18 Aug 2010 15:03:26 -0400 Subject: iPhone updates and required bandwidth In-Reply-To: References: Message-ID: I set up an OS X server which hosts updates for the rest of the company, so the OS X client machines poll/pull updates from the internal machine as opposed to 100 of them pulling the same updates over the internet. saves bucket loads of bandwidth and you can "pre ok" individual packages, so the client just updates without prompting. I'm not sure but I suspect they might have something which allows their other devices to poll this same source. it would seem reasonable anyway.. probably not a very useful answer but there it is. 8) -g On Aug 18, 2010, at 2:54 PM, JoeSox wrote: > Am I the only one that gets ticked off at the Apple iPhone update > procedure and the amount of bandwidth it needs? > Is there any secret I am missing to cut down on the required bandwidth > needed for it (caching the update somewhere etc)? I don't own an > iPhone (DroidX user here) and am unfamiliar with the update, all I > know is it uses tons of BW. > > > -- > Thanks, Joe > From dave at mvn.net Wed Aug 18 14:04:16 2010 From: dave at mvn.net (David E. Smith) Date: Wed, 18 Aug 2010 14:04:16 -0500 Subject: iPhone updates and required bandwidth In-Reply-To: References: Message-ID: On Wed, Aug 18, 2010 at 13:54, JoeSox wrote: > Am I the only one that gets ticked off at the Apple iPhone update > procedure and the amount of bandwidth it needs? > Is there any secret I am missing to cut down on the required bandwidth > needed for it (caching the update somewhere etc)? I don't own an > iPhone (DroidX user here) and am unfamiliar with the update, all I > know is it uses tons of BW. iOS (or iPhone OS, whatever) updates aren't simple deltas (i.e. here's the stuff that changed) - each update is a complete copy of the device's whole operating system. They always are a few hundred megabytes. In theory, you could download the updates manually, extract the firmware, and have your users pull it from your Web server, and then enter the secret recipe into iTunes to let the customer's computer install an iOS update from a "local" file instead of using the built-in update service. This of course defeats the whole purpose of Apple gear, that being that it's simple and Everything Just Works. iOS developers have to do this all the time, but most residential folks aren't gonna. They pay for bandwidth, and it's your job to deliver it. David Smith MVN.net From joesox at gmail.com Wed Aug 18 14:07:32 2010 From: joesox at gmail.com (JoeSox) Date: Wed, 18 Aug 2010 12:07:32 -0700 Subject: iPhone updates and required bandwidth In-Reply-To: References: Message-ID: Interesting. Do you have to configure the iPhone devices or just use its standard settings? -- Thanks, Joe On Wed, Aug 18, 2010 at 12:03 PM, Greg Whynott wrote: > I set up an OS X server which hosts updates for the rest of the company, ?so the OS X client machines poll/pull updates from the internal machine as opposed to 100 of them pulling the same updates over the internet. ?saves bucket loads of bandwidth and ?you can "pre ok" individual packages, ?so the client just updates without prompting. ? I'm not sure but I suspect they might have something which allows their other devices to poll this same source. ?it would seem reasonable anyway.. > > probably not a very useful answer but there it is. ?8) > > > -g > > > On Aug 18, 2010, at 2:54 PM, JoeSox wrote: > >> Am I the only one that gets ticked off at the Apple iPhone update >> procedure and the amount of bandwidth it needs? >> Is there any secret I am missing to cut down on the required bandwidth >> needed for it (caching the update somewhere etc)? ?I don't own an >> iPhone (DroidX user here) and am unfamiliar with the update, all I >> know is it uses tons of BW. >> >> >> -- >> Thanks, Joe >> > > From Greg.Whynott at oicr.on.ca Wed Aug 18 14:20:52 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Wed, 18 Aug 2010 15:20:52 -0400 Subject: iPhone updates and required bandwidth In-Reply-To: References: Message-ID: sorry Joe if i wasn't clear, what i was trying to say is I know there is a solution to address the bandwidth issue caused by updates for OS X machines, I am unsure if they have a similar solution for their hand held devices. I am assuming they do or soon will. I'm on the road right now, when I return to the office I'll take a look at the OS X update server and see if there is any provisions for the iPhones and friends. perhaps a squid caching server in-between the device network and internet? back in the day this is how i mitigated other many to one client update issues. -g On Aug 18, 2010, at 3:07 PM, JoeSox wrote: > Interesting. > Do you have to configure the iPhone devices or just use its standard settings? > > -- > Thanks, Joe > > > On Wed, Aug 18, 2010 at 12:03 PM, Greg Whynott wrote: >> I set up an OS X server which hosts updates for the rest of the company, so the OS X client machines poll/pull updates from the internal machine as opposed to 100 of them pulling the same updates over the internet. saves bucket loads of bandwidth and you can "pre ok" individual packages, so the client just updates without prompting. I'm not sure but I suspect they might have something which allows their other devices to poll this same source. it would seem reasonable anyway.. >> >> probably not a very useful answer but there it is. 8) >> >> >> -g >> >> >> On Aug 18, 2010, at 2:54 PM, JoeSox wrote: >> >>> Am I the only one that gets ticked off at the Apple iPhone update >>> procedure and the amount of bandwidth it needs? >>> Is there any secret I am missing to cut down on the required bandwidth >>> needed for it (caching the update somewhere etc)? I don't own an >>> iPhone (DroidX user here) and am unfamiliar with the update, all I >>> know is it uses tons of BW. >>> >>> >>> -- >>> Thanks, Joe >>> >> >> > From joachim at tingvold.com Wed Aug 18 14:29:07 2010 From: joachim at tingvold.com (Joachim Tingvold) Date: Wed, 18 Aug 2010 21:29:07 +0200 Subject: iPhone updates and required bandwidth In-Reply-To: References: Message-ID: <3FD72533-E70E-445B-A184-6FB9D6A730C6@tingvold.com> On Wed, Aug 18, 2010, at 21:20:52PM GMT+02:00, Greg Whynott wrote: > perhaps a squid caching server in-between the device network and > internet? That would be my suggestion, as well. iTunes pulls the updates from appldnld.apple.com.edgesuite.net or appldnld.apple.com, so you'd only need to cache those two. -- Joachim From jared at puck.nether.net Wed Aug 18 14:29:18 2010 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 18 Aug 2010 15:29:18 -0400 Subject: iPhone updates and required bandwidth In-Reply-To: References: Message-ID: <5424B562-E703-4ADA-B4FC-891DF61A44EB@puck.nether.net> On Aug 18, 2010, at 3:20 PM, Greg Whynott wrote: > sorry Joe if i wasn't clear, what i was trying to say is I know there is a solution to address the bandwidth issue caused by updates for OS X machines, I am unsure if they have a similar solution for their hand held devices. I am assuming they do or soon will. I'm on the road right now, when I return to the office I'll take a look at the OS X update server and see if there is any provisions for the iPhones and friends. > > perhaps a squid caching server in-between the device network and internet? back in the day this is how i mitigated other many to one client update issues. This is what I am doing for my home-lan. I have a few machines of the Mac variety and having a properly tuned transparent cache seems to solve the major issue. This isn't #apple forum, but back in the 1.0.0 they did post binary 'patch' updates for the first few revisions but eventually moved to using the full 'restore' image. I suspect this was in direct response to the "jailbreak/unlocker" community, as well as just plain-ol bugs as it relates to the binary patch process. There seemed to be a large number of people who had trouble with that. I'm sure if you approached the CDN that hosts the #apple updates they would be willing to put a copy of swcdn.apple.com on your network, as well as appldnld.apple.com The squid user forums have lots of tips about how to do this for apple and microsoft sw updates. - Jared From lists at mtin.net Wed Aug 18 14:29:46 2010 From: lists at mtin.net (Justin Wilson) Date: Wed, 18 Aug 2010 15:29:46 -0400 Subject: iPhone updates and required bandwidth In-Reply-To: Message-ID: Apple is ultra protective of their mobile stuff. It?s just going to get worse in the attempts to circumvent the devices being ?Jailbroken?. Quite a bit of behind the scenes checksums and re-checks going on. They want to make sure the device cleanly downloads, cleanly installs, and is not tampered with. Itunes is responsible for doing all this in the background. Justin -- Justin Wilson http://www.mtin.net/blog ? xISP News http://www.twitter.com/j2sw ? Follow me on Twitter Wisp Consulting ? Tower Climbing ? Network Support From: Greg Whynott Date: Wed, 18 Aug 2010 15:20:52 -0400 To: JoeSox Cc: "nanog at nanog.org" Subject: Re: iPhone updates and required bandwidth sorry Joe if i wasn't clear, what i was trying to say is I know there is a solution to address the bandwidth issue caused by updates for OS X machines, I am unsure if they have a similar solution for their hand held devices. I am assuming they do or soon will. I'm on the road right now, when I return to the office I'll take a look at the OS X update server and see if there is any provisions for the iPhones and friends. perhaps a squid caching server in-between the device network and internet? back in the day this is how i mitigated other many to one client update issues. -g On Aug 18, 2010, at 3:07 PM, JoeSox wrote: > Interesting. > Do you have to configure the iPhone devices or just use its standard settings? > > -- > Thanks, Joe > > > On Wed, Aug 18, 2010 at 12:03 PM, Greg Whynott wrote: >> I set up an OS X server which hosts updates for the rest of the company, so the OS X client machines poll/pull updates from the internal machine as opposed to 100 of them pulling the same updates over the internet. saves bucket loads of bandwidth and you can "pre ok" individual packages, so the client just updates without prompting. I'm not sure but I suspect they might have something which allows their other devices to poll this same source. it would seem reasonable anyway.. >> >> probably not a very useful answer but there it is. 8) >> >> >> -g >> >> >> On Aug 18, 2010, at 2:54 PM, JoeSox wrote: >> >>> Am I the only one that gets ticked off at the Apple iPhone update >>> procedure and the amount of bandwidth it needs? >>> Is there any secret I am missing to cut down on the required bandwidth >>> needed for it (caching the update somewhere etc)? I don't own an >>> iPhone (DroidX user here) and am unfamiliar with the update, all I >>> know is it uses tons of BW. >>> >>> >>> -- >>> Thanks, Joe >>> >> >> > From brandon.galbraith at gmail.com Wed Aug 18 14:35:25 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 18 Aug 2010 14:35:25 -0500 Subject: iPhone updates and required bandwidth In-Reply-To: <5424B562-E703-4ADA-B4FC-891DF61A44EB@puck.nether.net> References: <5424B562-E703-4ADA-B4FC-891DF61A44EB@puck.nether.net> Message-ID: On Wed, Aug 18, 2010 at 2:29 PM, Jared Mauch wrote: > I'm sure if you approached the CDN that hosts the #apple updates they would > be willing to put a copy of swcdn.apple.com on your network, as well as > appldnld.apple.com > > The squid user forums have lots of tips about how to do this for apple and > microsoft sw updates. > > - Jared > If anyone does move forward with this, I'd be interested in what sort of bandwidth savings are realized. -brandon From joesox at gmail.com Wed Aug 18 15:47:36 2010 From: joesox at gmail.com (JoeSox) Date: Wed, 18 Aug 2010 13:47:36 -0700 Subject: iPhone updates and required bandwidth In-Reply-To: <3FD72533-E70E-445B-A184-6FB9D6A730C6@tingvold.com> References: <3FD72533-E70E-445B-A184-6FB9D6A730C6@tingvold.com> Message-ID: Thank you. this is good info. -- Joe On Wed, Aug 18, 2010 at 12:29 PM, Joachim Tingvold wrote: > On Wed, Aug 18, 2010, at 21:20:52PM GMT+02:00, Greg Whynott wrote: >> >> perhaps a squid caching server in-between the device network and internet? > > That would be my suggestion, as well. iTunes pulls the updates from > appldnld.apple.com.edgesuite.net or appldnld.apple.com, so you'd only need > to cache those two. > > -- > Joachim > > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Aug 18 16:16:48 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 19 Aug 2010 06:46:48 +0930 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: References: <20100818200447.162288b6@opy.nosense.org> Message-ID: <20100819064648.6c90e970@opy.nosense.org> On Wed, 18 Aug 2010 16:18:00 +0200 Hannes Frederic Sowa wrote: > On Wed, Aug 18, 2010 at 12:34 PM, Mark Smith wrote: > > Haven't really thought about it before. > > > > One thing to consider is that unless the preferred and valid lifetimes > > of an IPv6 prefix are set to infinity, IPv6 prefixes are always dynamic > > - they'll eventually expire unless they're refreshed. The preferred and > > valid lifetimes for prefixes that are delegated to customers could be > > something that they might be able to change via a web portal, bounded > > to within what you as an ISP are happy with e.g. 1 to 30 days, rather > > than the absolute range of lifetime values supported. CPE could also > > potentially do the same thing with the range of subnets it has been > > delegated, by phasing in and out subnets over time on it's downstream > > interfaces. (The more subnets the better, so a /48 would be ideal for > > this.) > > Yep, I am in favour of such setups. This will stress internal name > services(eg. netbios) but would be a solvable problem, I think. > > > As you've mentioned, privacy addresses help. A related idea is > > described in "Transient addressing for related processes: Improved > > firewalling by using IPv6 and multiple addresses per host." [0], Peter > > M. Gleitz and Steven M. Bellovin, which takes advantage of the 2^64 > > addresses in a /64, and has different applications on the same host use > > different source IPv6 addresses. > > > > Pretending to be multiple hosts, or even just one with privacy > > addresses, moving around multiple subnets, on delegated prefixes that > > change fairly regularly would probably mitigate quite a lot of the > > privacy concerns people may have related to IPv6 addressing. > > If your ipv6-geolocation-service tells you that all /48 prefixes > behind this network are just static home-user networks, why not just > ignore the lower 64 bits or even the lower 80 bits? Privacy extensions > would be no help here. They help because you're concerned about privacy. You didn't qualify that you're only concerned about privacy from geolocation services, so I described a mechanism that would provide you as much privacy as possible, while also being automatic, and also continuing to provide IPv6 Internet connectivity. No where was cryto mentioned either (on both our parts), yet that is also a privacy mechanism. As a customer, it's relatively hard to hide from geolocation services because they use your IP address in combination with information that you don't have control over i.e. RIR / whois data. If a customer wants to hide from that, then they'll need to start tunnelling their traffic to another entry/exit point on the Internet. Much like security, privacy is relative. If you want to have bi-directional communications with another entity, you have to disclose your identity. How long you retain that identity is what makes one form of privacy more private than another. Customers who have high expectations of privacy won't trust their ISP at the time to preserve it - because, as the cliche goes, if you want something done properly, you need to do it yourself. So, as an ISP, you need to think about how much privacy you can provide, can afford to provide, and at what point it becomes irrelevant because your customer doesn't trust you to provide it at all. >In IPv4-land I have the possibility to > reconnect and get a new unrelated ip-address every time. > They're issued by the same ISP, to they're related. Regards, Mark. From jbates at brightok.net Wed Aug 18 16:41:56 2010 From: jbates at brightok.net (Jack Bates) Date: Wed, 18 Aug 2010 16:41:56 -0500 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: References: Message-ID: <4C6C53A4.7060005@brightok.net> Hannes Frederic Sowa wrote: > the other one will be dynamically allocated. I have no clue how the > user would switch between these subnets (without using some kind of > command line tools). Web portals work fine, and honestly, it's not like you need to switch subnets, either. PPPoE/A implementations work great, as they are already designed to utilize radius backends to quickly alter static/dynamic on a session. For bridging setups, you have a variety of implementations and it becomes messier. Cisco, while maintaining RBE did away with the concept of proxy-nd, and didn't provide a mechanism for dynamically allocating the prefixes to the unnumbered interface. If you use dslam level controls, you'll most likely being using DHCPv6 TA addressing with PD on top of it, which works well. Most of which can support quick static/dynamic capabilities as it does with v4. Jack From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Aug 18 16:55:11 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 19 Aug 2010 07:25:11 +0930 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: <20100818200447.162288b6@opy.nosense.org> References: <20100818200447.162288b6@opy.nosense.org> Message-ID: <20100819072511.3430f2ef@opy.nosense.org> On Wed, 18 Aug 2010 20:04:47 +0930 Mark Smith wrote: > On Wed, 18 Aug 2010 01:12:19 +0200 > Hannes Frederic Sowa wrote: > > > Hello! > > > > As the first IPv6 deployments for end-users are in the planning stage > > in Germany, I realized I have not found any BCP for handling > > addressing in those scenarios. IPv6 will make it a lot easier for > > static address deployments but I wonder weather this is in the best > > sense for the customers. As I normally come from the technical side I > > prefer static addressing. But in the world of facebook and co. I > > wonder if it would be a better to let the user have the choice. A > > major provider of dsl here in Germany recently blogged about this [1]. > > Their proposal is to serve two subnets, one being a static one while > > the other one will be dynamically allocated. I have no clue how the > > user would switch between these subnets (without using some kind of > > command line tools). > > > > This is not about using privacy extensions as the subnet is sufficient > > for identification. > > > > Did you reach any conclusion on this matter? > > > > Haven't really thought about it before. > > One thing to consider is that unless the preferred and valid lifetimes > of an IPv6 prefix are set to infinity, IPv6 prefixes are always dynamic > - they'll eventually expire unless they're refreshed. The preferred and > valid lifetimes for prefixes that are delegated to customers could be > something that they might be able to change via a web portal, bounded > to within what you as an ISP are happy with e.g. 1 to 30 days, rather > than the absolute range of lifetime values supported. In case it isn't clear, the customer would have multiple delegated IPv6 prefixes during the overlap period. New prefixes are phased in and old ones are phased out. Over what time period the phase in / phase out occurs is what the customer could have the ability to change. Changing addresses will disrupt ongoing communications. While IPv6 can't prevent that disruption, it does have mechanisms available to handle it far more gracefully than the customer having to bounce their PPP session to acquire new addressing. With the right parameters, I think an ISP could make phasing in/phasing out prefixes transparent for most cases. > CPE could also > potentially do the same thing with the range of subnets it has been > delegated, by phasing in and out subnets over time on it's downstream > interfaces. (The more subnets the better, so a /48 would be ideal for > this.) > > As you've mentioned, privacy addresses help. A related idea is > described in "Transient addressing for related processes: Improved > firewalling by using IPv6 and multiple addresses per host." [0], Peter > M. Gleitz and Steven M. Bellovin, which takes advantage of the 2^64 > addresses in a /64, and has different applications on the same host use > different source IPv6 addresses. > > Pretending to be multiple hosts, or even just one with privacy > addresses, moving around multiple subnets, on delegated prefixes that > change fairly regularly would probably mitigate quite a lot of the > privacy concerns people may have related to IPv6 addressing. > > Regards, > Mark. > > > [0] http://www.cs.columbia.edu/~smb/papers/tarp.pdf > From hannes at mailcolloid.de Wed Aug 18 18:20:30 2010 From: hannes at mailcolloid.de (Hannes Frederic Sowa) Date: Thu, 19 Aug 2010 01:20:30 +0200 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: <20100819064648.6c90e970@opy.nosense.org> References: <20100818200447.162288b6@opy.nosense.org> <20100819064648.6c90e970@opy.nosense.org> Message-ID: On Wed, Aug 18, 2010 at 11:16 PM, Mark Smith wrote: > They help because you're concerned about privacy. You didn't qualify > that you're only concerned about privacy from geolocation services, so > I described a mechanism that would provide you as much privacy as > possible, while also being automatic, and also continuing to provide > IPv6 Internet connectivity. No where was cryto mentioned either (on > both our parts), yet that is also a privacy mechanism. I tried to highlight the relationship between ipv4-address and /48-prefixes in regard to privacy. If a provider is known for handling out statically allocated prefixes, it should be possible to track its clients by prefix. Sorry for picking a geolocation-service as an example of where such information can originate from. It was misleading. > As a customer, it's relatively hard to hide from geolocation services > because they use your IP address in combination with information that > you don't have control over i.e. RIR / whois data. If a customer wants > to hide from that, then they'll need to start tunnelling their traffic > to another entry/exit point on the Internet. Fully hiding from geolocation services is only possible with anonymity services, yes. > Much like security, privacy is relative. If you want to have > bi-directional communications with another entity, you > have to disclose your identity. How long you retain that identity is > what makes one form of privacy more private than another. > Customers who have high expectations of privacy won't trust their > ISP at the time to preserve it - because, as the cliche goes, if you > want something done properly, you need to do it yourself. So, as an > ISP, you need to think about how much privacy you can provide, can > afford to provide, and at what point it becomes irrelevant because your > customer doesn't trust you to provide it at all. But most people just don't care. My proposal is to have some kind of sane defaults for them e.g. changing their prefix every week or in the case of a reconnect. This would mitigate some of the many privacy concerns in the internet a little bit. Of course all the already known problems would still exist. And still people have to care about the technology to reach a higher level of anonymity. >>In IPv4-land I have the possibility to >> reconnect and get a new unrelated ip-address every time. >> > > They're issued by the same ISP, to they're related. Ups. Unrelated in the sense of random ip from their pool, of course. hannes From hannes at mailcolloid.de Wed Aug 18 18:35:50 2010 From: hannes at mailcolloid.de (Hannes Frederic Sowa) Date: Thu, 19 Aug 2010 01:35:50 +0200 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: <4C6C53A4.7060005@brightok.net> References: <4C6C53A4.7060005@brightok.net> Message-ID: On Wed, Aug 18, 2010 at 11:41 PM, Jack Bates wrote: > Web portals work fine, and honestly, it's not like you need to switch > subnets, either. PPPoE/A implementations work great, as they are already > designed to utilize radius backends to quickly alter static/dynamic on a > session. For bridging setups, you have a variety of implementations and it > becomes messier. Cisco, while maintaining RBE did away with the concept of > proxy-nd, and didn't provide a mechanism for dynamically allocating the > prefixes to the unnumbered interface. If you use dslam level controls, > you'll most likely being using DHCPv6 TA addressing with PD on top of it, > which works well. Most of which can support quick static/dynamic > capabilities as it does with v4. Thanks. I will have a deeper look in the standards. This sounds like a viable solution to me. Albeit, I wonder if there is a drive for the big ISPs to implement such features. From scubacuda at gmail.com Wed Aug 18 19:16:56 2010 From: scubacuda at gmail.com (Rogelio) Date: Wed, 18 Aug 2010 17:16:56 -0700 Subject: tool to wrangle config file changes Message-ID: Long story short, a really crappy vendor is being shoved down our NOC's throat. They have a horrid CLI (if you can call it that). People don't understand it (it's non-intuitive) and are screwing up things all the time. In the hopes of coping with the madness, some of us are looking to put together some sort of open source configuration management tool, such as RANCID. Any luck with this on non-standard equipment, particularly ones that DO NOT allow you to output something nice and "scriptable" (e.g. Cisco's "show running-config") (If not RANCID, any other suggestions?) From ggm at apnic.net Wed Aug 18 19:38:01 2010 From: ggm at apnic.net (George Michaelson) Date: Thu, 19 Aug 2010 10:38:01 +1000 Subject: (cisco, or any) acl *reducers* out there? Message-ID: <5F0D0E5F-2BB3-43EB-B56A-F622763D78C3@apnic.net> I have been looking at acl management s/w in the freecode space and I can find lots of tools which manage/distribute and test ACLs in routers. I'm wondering if anyone has written a parser which can construct rule-trees and get rid of the cruft, unusable, order-misorder and other issues in a large ACL pool? Its possible this is NP in the wider sense, but even a partial improvement would be useful something which can take a couple of hundred basic and extended ACLs and tell you these don't work these conflict the remaining have a sequence and can reduce to this basic set (we've got the usual "acquisition of rule by accretion" problem across 4 edge/core routers with a mix of public facing, internal, WiFi, guest rules, and I hate to think this is either start from scratch, or intractable. The evidence is that its FRAGILE) -G From rdobbins at arbor.net Wed Aug 18 19:47:37 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 19 Aug 2010 00:47:37 +0000 Subject: (cisco, or any) acl *reducers* out there? In-Reply-To: <5F0D0E5F-2BB3-43EB-B56A-F622763D78C3@apnic.net> References: <5F0D0E5F-2BB3-43EB-B56A-F622763D78C3@apnic.net> Message-ID: <3913D43B-E205-43DA-85DE-3ED6854FC874@arbor.net> On Aug 19, 2010, at 7:38 AM, George Michaelson wrote: > (we've got the usual "acquisition of rule by accretion" problem across 4 edge/core routers with a mix of public facing, internal, WiFi, guest rules, and I hate to think this is either start from scratch, or intractable. The evidence is that its FRAGILE) Attempts by various commercial solutions aside, there isn't really a workable, usable, scalable and reliable automated way to do this, AFAIK; apart from the complexity of the task itself, platform-specific ACL handling complicates matters further. To begin getting a handle on your ACLs, implement some form of revision control (RCS, CVS, subversion, whatever), and then work to modularize the ACLs by function: Then take a look at whether the ACLs in question all actually belong on the edge, or whether it makes sense to break them out and instantiate the relevant policies at various points within the topology. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From morrowc.lists at gmail.com Wed Aug 18 20:51:59 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 18 Aug 2010 21:51:59 -0400 Subject: (cisco, or any) acl *reducers* out there? In-Reply-To: <3913D43B-E205-43DA-85DE-3ED6854FC874@arbor.net> References: <5F0D0E5F-2BB3-43EB-B56A-F622763D78C3@apnic.net> <3913D43B-E205-43DA-85DE-3ED6854FC874@arbor.net> Message-ID: On Wed, Aug 18, 2010 at 8:47 PM, Dobbins, Roland wrote: > > On Aug 19, 2010, at 7:38 AM, George Michaelson wrote: > >> (we've got the usual "acquisition of rule by accretion" problem across 4 edge/core routers with a mix of public facing, internal, WiFi, guest rules, and I hate to think this is either start from scratch, or intractable. The evidence is that its FRAGILE) > > Attempts by various commercial solutions aside, there isn't really a workable, usable, scalable and reliable automated way to do this, AFAIK; apart from the complexity of the task itself, platform-specific ACL handling complicates matters further. > > To begin getting a handle on your ACLs, implement some form of revision control (RCS, CVS, subversion, whatever), and then work to modularize the ACLs by function: > > > > Then take a look at whether the ACLs in question all actually belong on the edge, or whether it makes sense to break them out and instantiate the relevant policies at various points within the topology. a plug for some google-peeps: potentially once you make the definitions/policy-files you can use the proto-language to sort through your mess in a saner fashion. a nice aside is you can also create (from the same policy file) cisco/juniper/iptables configurations. (tony/pete really did a nice job on this) -chris > ----------------------------------------------------------------------- > Roland Dobbins // > > ? ?Injustice is relatively easy to bear; what stings is justice. > > ? ? ? ? ? ? ? ? ? ? ? ?-- H.L. Mencken > > > > > From randy at psg.com Wed Aug 18 22:00:48 2010 From: randy at psg.com (Randy Bush) Date: Thu, 19 Aug 2010 12:00:48 +0900 Subject: (cisco, or any) acl *reducers* out there? In-Reply-To: <5F0D0E5F-2BB3-43EB-B56A-F622763D78C3@apnic.net> References: <5F0D0E5F-2BB3-43EB-B56A-F622763D78C3@apnic.net> Message-ID: > something which can take a couple of hundred basic and extended ACLs and tell you > these don't work > these conflict > the remaining have a sequence and can reduce to this basic set maybe you could go the other direction. as opposed to trying to digest and correct cruft, generate the acls from something reasonable so that they are canonic by construction. randy From vandry at TZoNE.ORG Wed Aug 18 22:13:58 2010 From: vandry at TZoNE.ORG (Phil Vandry) Date: Thu, 19 Aug 2010 12:13:58 +0900 Subject: Numbering nameservers and resolvers In-Reply-To: <674901BB-EB6D-463E-8E1A-F78FFB14C577@puck.nether.net> References: <4C68DF61.6080601@tiedyenetworks.com> <91BA3752-118D-4284-A6C2-6E042A033D0B@ianai.net> <20100816130336.GA703173@hiwaay.net> <20FD4DA8-112A-4BE8-BC7E-B58A16036D7D@delong.com> <20100817085324.GK11895@hezmatt.org> <674901BB-EB6D-463E-8E1A-F78FFB14C577@puck.nether.net> Message-ID: <20100819031358.GA18080@OZoNE.TZoNE.ORG> On Tue, Aug 17, 2010 at 08:52:20AM -0400, Jared Mauch wrote: > Selecting a site outside of your control is valuable. When I was > hostmaster at cic.net, we "traded" with mr.net. These days, if I were > in the same role, I would want to have three instead of two. Asia, > Europe and US someplace. If US only, east, west and central. While this is good advice, I think it is also important to consider your customer base. I could easily host an authoritative nameserver for my domains in Japan, but I elected not to do so, because most of the end users who would be querying it are in Canada, and, with one nameserver in Canada and one in Japan, they would get a long RTT on DNS queries roughly half the time. -Phil From ggm at apnic.net Wed Aug 18 22:23:51 2010 From: ggm at apnic.net (George Michaelson) Date: Thu, 19 Aug 2010 13:23:51 +1000 Subject: (cisco, or any) acl *reducers* out there? In-Reply-To: References: <5F0D0E5F-2BB3-43EB-B56A-F622763D78C3@apnic.net> Message-ID: <5083397C-550D-40F9-89D2-9C076274AE55@apnic.net> On 19/08/2010, at 1:00 PM, Randy Bush wrote: >> something which can take a couple of hundred basic and extended ACLs and tell you >> these don't work >> these conflict >> the remaining have a sequence and can reduce to this basic set > > maybe you could go the other direction. as opposed to trying to digest > and correct cruft, generate the acls from something reasonable so that > they are canonic by construction. > > randy A reasonable call. Its probably where we'll be by default, because there isn't anything there and I think first principles upward is better than paring back. Thanks for the responses (and Roland!) I think its clear a tool like I asked doesn't exist, and very probably won't, anytime soon. cheers -G From lyndon at orthanc.ca Wed Aug 18 22:25:09 2010 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Wed, 18 Aug 2010 20:25:09 -0700 (PDT) Subject: Numbering nameservers and resolvers In-Reply-To: <20100819031358.GA18080@OZoNE.TZoNE.ORG> References: <4C68DF61.6080601@tiedyenetworks.com> <91BA3752-118D-4284-A6C2-6E042A033D0B@ianai.net> <20100816130336.GA703173@hiwaay.net> <20FD4DA8-112A-4BE8-BC7E-B58A16036D7D@delong.com> <20100817085324.GK11895@hezmatt.org> <674901BB-EB6D-463E-8E1A-F78FFB14C577@puck.nether.net> <20100819031358.GA18080@OZoNE.TZoNE.ORG> Message-ID: > because most of the end users who would be querying it are in > Canada, and, with one nameserver in Canada and one in Japan, > they would get a long RTT on DNS queries roughly half the time. But only, say, once per week if you're running a reasonable TTL on your zone. From randy at psg.com Wed Aug 18 22:38:12 2010 From: randy at psg.com (Randy Bush) Date: Thu, 19 Aug 2010 12:38:12 +0900 Subject: (cisco, or any) acl *reducers* out there? In-Reply-To: <5083397C-550D-40F9-89D2-9C076274AE55@apnic.net> References: <5F0D0E5F-2BB3-43EB-B56A-F622763D78C3@apnic.net> <5083397C-550D-40F9-89D2-9C076274AE55@apnic.net> Message-ID: one more comment. be careful aggregating filters. the peer may actually announce all those damed frags, especially in massively de-aggregated places such as india, indonesia, ... randy From ggm at apnic.net Wed Aug 18 22:43:32 2010 From: ggm at apnic.net (George Michaelson) Date: Thu, 19 Aug 2010 13:43:32 +1000 Subject: (cisco, or any) acl *reducers* out there? In-Reply-To: References: <5F0D0E5F-2BB3-43EB-B56A-F622763D78C3@apnic.net> <5083397C-550D-40F9-89D2-9C076274AE55@apnic.net> Message-ID: <07FB61D6-E404-495D-95D8-64D838FDF1F5@apnic.net> On 19/08/2010, at 1:38 PM, Randy Bush wrote: > one more comment. be careful aggregating filters. the peer may > actually announce all those damed frags, especially in massively > de-aggregated places such as india, indonesia, ... > > randy I should have been clearer that I really only want to aggregate ACLs like a port-22 ssh filter which has an endless list of specific /32, or the 'we don't like inbound UDP' -where it logically made sense. So if you happen to have an overarching UDP 'established' class rule, then its order compared to other rules might or might not make them useless. Route filtering is best done by professionals. Always read the instructions on the packet. (Your oven may be in centigrade, not fahrenheit, and the cup size varies by economy.) -George From alexmern at xi.uz Thu Aug 19 01:30:11 2010 From: alexmern at xi.uz (Alexander Merniy) Date: Thu, 19 Aug 2010 11:30:11 +0500 Subject: tool to wrangle config file changes In-Reply-To: References: Message-ID: <8D34E2C3-4FF9-46EF-9B8B-49C0BF5219F0@xi.uz> I'm using this for configuration backup: http://nocproject.org/ On 19/08/2010, at 5:16 AM, Rogelio wrote: > Long story short, a really crappy vendor is being shoved down our > NOC's throat. They have a horrid CLI (if you can call it that). > People don't understand it (it's non-intuitive) and are screwing up > things all the time. > > In the hopes of coping with the madness, some of us are looking to put > together some sort of open source configuration management tool, such > as RANCID. Any luck with this on non-standard equipment, particularly > ones that DO NOT allow you to output something nice and "scriptable" > (e.g. Cisco's "show running-config") > > (If not RANCID, any other suggestions?) > From eugen at imacandi.net Thu Aug 19 03:03:02 2010 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Thu, 19 Aug 2010 11:03:02 +0300 Subject: tool to wrangle config file changes In-Reply-To: References: Message-ID: On Thu, Aug 19, 2010 at 03:16, Rogelio wrote: > Long story short, a really crappy vendor is being shoved down our > NOC's throat. ?They have a horrid CLI (if you can call it that). > People don't understand it (it's non-intuitive) and are screwing up > things all the time. Would be so kind to name the vendor so that other people would have an advance warning ? From mmzinyi at yahoo.com Thu Aug 19 04:23:37 2010 From: mmzinyi at yahoo.com (jacob miller) Date: Thu, 19 Aug 2010 02:23:37 -0700 (PDT) Subject: Monitoring Tools Message-ID: <974999.79433.qm@web39501.mail.mud.yahoo.com> Am looking for an opensource network monitoring tool with ability to create different views for different users. Regards,Jacob From rmacharia at gmail.com Thu Aug 19 05:15:41 2010 From: rmacharia at gmail.com (Raymond Macharia) Date: Thu, 19 Aug 2010 13:15:41 +0300 Subject: tool to wrangle config file changes In-Reply-To: References: Message-ID: Kiwi Cat Tools. There is a free version (supports upto 20 devices). - http://www.kiwisyslog.com/ Raymond Macharia On Thu, Aug 19, 2010 at 11:03 AM, Eugeniu Patrascu wrote: > On Thu, Aug 19, 2010 at 03:16, Rogelio wrote: > > Long story short, a really crappy vendor is being shoved down our > > NOC's throat. They have a horrid CLI (if you can call it that). > > People don't understand it (it's non-intuitive) and are screwing up > > things all the time. > > Would be so kind to name the vendor so that other people would have an > advance warning ? > > From regnauld at nsrc.org Thu Aug 19 05:23:17 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 19 Aug 2010 12:23:17 +0200 Subject: Monitoring Tools In-Reply-To: <974999.79433.qm@web39501.mail.mud.yahoo.com> References: <974999.79433.qm@web39501.mail.mud.yahoo.com> Message-ID: <20100819102312.GC82715@macbook.catpipe.net> jacob miller (mmzinyi) writes: > Am looking for an opensource network monitoring tool with ability to create different views for different users. > Hi Jacob, What kind of network monitoring ? Bandwidth utilization, service availability, RTT, statistics data collection, ... ? There are tons of open source software tools out there: Nagios (www.nagios.org) Zabbix (www.zabbix.com) OpenNMS (www.opennms.org) ZenOSS (www.zenoss.com) SmokePing (http://oss.oetiker.ch/smokeping/) Cacti (www.cacti.netl) NetFlow Dashboard (http://trac.netflowdashboard.com/netflowdashboard/) NFSen (http://nfsen.sourceforge.net/) etc... Depends on what you want to achieve! Cheers, Phil From kuenzler at init7.net Thu Aug 19 06:23:04 2010 From: kuenzler at init7.net (Fredy Kuenzler) Date: Thu, 19 Aug 2010 13:23:04 +0200 Subject: NYCX (New York City Exchange) contact wanted Message-ID: <4C6D1418.3020603@init7.net> Anyone in charge of the exchange plattform in New York formerly known as NYCX (New York City Exchange), managed by NAC.net? Please contact me offlist. (Yes we are still plugged and there is some traffic flowing ...) Many thanks, Fredy From mmzinyi at yahoo.com Thu Aug 19 06:36:21 2010 From: mmzinyi at yahoo.com (jacob miller) Date: Thu, 19 Aug 2010 04:36:21 -0700 (PDT) Subject: Monitoring Tools In-Reply-To: <20100819102312.GC82715@macbook.catpipe.net> Message-ID: <156125.60110.qm@web39505.mail.mud.yahoo.com> Phil, Am looking for availability reports,bandwidth usage,alerting service and ability to create different logins to users so they can access diff objects Thnks, Jacob --- On Thu, 8/19/10, Phil Regnauld wrote: > From: Phil Regnauld > Subject: Re: Monitoring Tools > To: "jacob miller" > Cc: nanog at nanog.org > Date: Thursday, August 19, 2010, 3:23 AM > jacob miller (mmzinyi) writes: > > Am looking for an opensource network monitoring tool > with ability to create different views for different users. > > > > ? ? Hi Jacob, > > ? ? What kind of network monitoring ?? > Bandwidth utilization, service > ? ? availability, RTT, statistics data > collection, ... ? > > ? ? There are tons of open source software tools > out there: > > ? ? Nagios (www.nagios.org) > ? ? Zabbix (www.zabbix.com) > ? ? OpenNMS (www.opennms.org) > ? ? ZenOSS (www.zenoss.com) > ? ? SmokePing (http://oss.oetiker.ch/smokeping/) > ? ? Cacti (www.cacti.netl) > ? ? NetFlow Dashboard (http://trac.netflowdashboard.com/netflowdashboard/) > ? ? NFSen (http://nfsen.sourceforge.net/) > > > ? ? etc... > > ? ? Depends on what you want to achieve! > > ? ? Cheers, > ? ? Phil > > From joakim at aronius.com Thu Aug 19 07:30:07 2010 From: joakim at aronius.com (Joakim Aronius) Date: Thu, 19 Aug 2010 14:30:07 +0200 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: References: <20100818200447.162288b6@opy.nosense.org> <20100819064648.6c90e970@opy.nosense.org> Message-ID: <20100819123007.GA27242@maya.aronius.com> * Hannes Frederic Sowa (hannes at mailcolloid.de) wrote: > > But most people just don't care. My proposal is to have some kind of > sane defaults for them e.g. changing their prefix every week or in the > case of a reconnect. This would mitigate some of the many privacy > concerns in the internet a little bit. Of course all the already known > problems would still exist. And still people have to care about the > technology to reach a higher level of anonymity. Ok. Lets assume that the ISP hands out new prefixes to the clients CPE each week. The CPE then advertises these prefixes on the clients home network. For clients accessing the internet this works fine (except perhaps a glitch during the switchover). But what about the internal communication in the customer premises? How do they connect to their NAS, media players, printers, TVs etc? Of course there is UPnP, DLNA and different other kinds of magic but I imagine that most home users actually configure IP addresses at some point. Constantly changing prefixes will ad another layer of complexity, things will break, and customers will be upset. (and quite frankly I don't think that you would gain that much privacy anyway) just my $.02 /Joakim From owen at delong.com Thu Aug 19 07:49:30 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 19 Aug 2010 05:49:30 -0700 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: <20100819123007.GA27242@maya.aronius.com> References: <20100818200447.162288b6@opy.nosense.org> <20100819064648.6c90e970@opy.nosense.org> <20100819123007.GA27242@maya.aronius.com> Message-ID: <5BCFE5FC-D9CA-46E2-B75E-8E733C5D02C6@delong.com> On Aug 19, 2010, at 5:30 AM, Joakim Aronius wrote: > * Hannes Frederic Sowa (hannes at mailcolloid.de) wrote: >> >> But most people just don't care. My proposal is to have some kind of >> sane defaults for them e.g. changing their prefix every week or in the >> case of a reconnect. This would mitigate some of the many privacy >> concerns in the internet a little bit. Of course all the already known >> problems would still exist. And still people have to care about the >> technology to reach a higher level of anonymity. > > Ok. Lets assume that the ISP hands out new prefixes to the clients CPE each week. The CPE then advertises these prefixes on the clients home network. For clients accessing the internet this works fine (except perhaps a glitch during the switchover). > > But what about the internal communication in the customer premises? How do they connect to their NAS, media players, printers, TVs etc? Of course there is UPnP, DLNA and different other kinds of magic but I imagine that most home users actually configure IP addresses at some point. > You actually imagine wrong in most cases. Many do, but, not most. Most use mDNS for such things these days, actually. > Constantly changing prefixes will ad another layer of complexity, things will break, and customers will be upset. (and quite frankly I don't think that you would gain that much privacy anyway) > I would agree. I think that customers that WANT privacy at the expense of having their prefix change often being able to request such service might be a good value-add service you could offer, but, I think the vast majority of customers would prefer prefix stability. I think that the privacy implications of a stable prefix are vastly over-stated in this thread. Owen From jbates at brightok.net Thu Aug 19 08:46:39 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 19 Aug 2010 08:46:39 -0500 Subject: Monitoring Tools In-Reply-To: <156125.60110.qm@web39505.mail.mud.yahoo.com> References: <156125.60110.qm@web39505.mail.mud.yahoo.com> Message-ID: <4C6D35BF.8070406@brightok.net> jacob miller wrote: > Phil, > > Am looking for availability reports,bandwidth usage,alerting service and ability to create different logins to users so they can access diff objects For all in one, OpenNMS does decent and may meet your needs. We often utilize a mixture of tools and modify for working with what we want. My only issue with OpenNMS was that it's java and I don't care to add java to the list of languages I program in. My only complaint was it could get really weird when you have 3,000 unnumbered interfaces. :) Jack From jbates at brightok.net Thu Aug 19 08:49:34 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 19 Aug 2010 08:49:34 -0500 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: <20100819123007.GA27242@maya.aronius.com> References: <20100818200447.162288b6@opy.nosense.org> <20100819064648.6c90e970@opy.nosense.org> <20100819123007.GA27242@maya.aronius.com> Message-ID: <4C6D366E.8030301@brightok.net> Joakim Aronius wrote: > But what about the internal communication in the customer premises? How do they connect to their NAS, media players, printers, TVs etc? Of course there is UPnP, DLNA and different other kinds of magic but I imagine that most home users actually configure IP addresses at some point. > The wise setup will use routed and non-routed addressing internally. This is how IPv6 was designed to handle it. Devices will be found through multicast, dynamic dns, or other means. Jack From r.engehausen at gmail.com Thu Aug 19 09:14:27 2010 From: r.engehausen at gmail.com (Roy) Date: Thu, 19 Aug 2010 07:14:27 -0700 Subject: Monitoring Tools In-Reply-To: <156125.60110.qm@web39505.mail.mud.yahoo.com> References: <156125.60110.qm@web39505.mail.mud.yahoo.com> Message-ID: <4C6D3C43.1050107@gmail.com> On 8/19/2010 4:36 AM, jacob miller wrote: > Phil, > > Am looking for availability reports,bandwidth usage,alerting service and ability to create different logins to users so they can access diff objects > > Thnks, > > Jacob > > --- On Thu, 8/19/10, Phil Regnauld wrote: > >> From: Phil Regnauld >> Subject: Re: Monitoring Tools >> To: "jacob miller" >> Cc: nanog at nanog.org >> Date: Thursday, August 19, 2010, 3:23 AM >> jacob miller (mmzinyi) writes: >>> Am looking for an opensource network monitoring tool >> with ability to create different views for different users. >> Hi Jacob, >> >> What kind of network monitoring ? >> Bandwidth utilization, service >> availability, RTT, statistics data >> collection, ... ? >> >> There are tons of open source software tools >> out there: >> >> Nagios (www.nagios.org) >> Zabbix (www.zabbix.com) >> OpenNMS (www.opennms.org) >> ZenOSS (www.zenoss.com) >> SmokePing (http://oss.oetiker.ch/smokeping/) >> Cacti (www.cacti.netl) >> NetFlow Dashboard (http://trac.netflowdashboard.com/netflowdashboard/) >> NFSen (http://nfsen.sourceforge.net/) >> >> >> etc... >> >> Depends on what you want to achieve! >> >> Cheers, >> Phil >> Opsview. http://www.opsview.com From scott at sberkman.net Thu Aug 19 09:37:11 2010 From: scott at sberkman.net (Scott Berkman) Date: Thu, 19 Aug 2010 10:37:11 -0400 Subject: Monitoring Tools In-Reply-To: <4C6D35BF.8070406@brightok.net> References: <156125.60110.qm@web39505.mail.mud.yahoo.com> <4C6D35BF.8070406@brightok.net> Message-ID: <021801cb3fac$02c48730$084d9590$@net> I'd recommend ZenOSS. -Scott -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Thursday, August 19, 2010 9:47 AM To: jacob miller Cc: nanog at nanog.org Subject: Re: Monitoring Tools jacob miller wrote: > Phil, > > Am looking for availability reports,bandwidth usage,alerting service and ability to create different logins to users so they can access diff objects For all in one, OpenNMS does decent and may meet your needs. We often utilize a mixture of tools and modify for working with what we want. My only issue with OpenNMS was that it's java and I don't care to add java to the list of languages I program in. My only complaint was it could get really weird when you have 3,000 unnumbered interfaces. :) Jack From scott at sberkman.net Thu Aug 19 09:40:15 2010 From: scott at sberkman.net (Scott Berkman) Date: Thu, 19 Aug 2010 10:40:15 -0400 Subject: tool to wrangle config file changes In-Reply-To: References: Message-ID: <021b01cb3fac$703cf900$50b6eb00$@net> We are now using NAI for this. Free (really, not just a trial for some small number of devices), and you can very easily "write" plug-ins for new types of systems. http://inventory.alterpoint.com/ http://docs.inventory.alterpoint.com/doku.php?id=doc:content_guide -Scott -----Original Message----- From: Raymond Macharia [mailto:rmacharia at gmail.com] Sent: Thursday, August 19, 2010 6:16 AM To: Eugeniu Patrascu Cc: nanog at nanog.org Subject: Re: tool to wrangle config file changes Kiwi Cat Tools. There is a free version (supports upto 20 devices). - http://www.kiwisyslog.com/ Raymond Macharia On Thu, Aug 19, 2010 at 11:03 AM, Eugeniu Patrascu wrote: > On Thu, Aug 19, 2010 at 03:16, Rogelio wrote: > > Long story short, a really crappy vendor is being shoved down our > > NOC's throat. They have a horrid CLI (if you can call it that). > > People don't understand it (it's non-intuitive) and are screwing up > > things all the time. > > Would be so kind to name the vendor so that other people would have an > advance warning ? > > From pawal at blipp.com Thu Aug 19 10:12:05 2010 From: pawal at blipp.com (Patrik Wallstrom) Date: Thu, 19 Aug 2010 17:12:05 +0200 Subject: Recycling old cabling? In-Reply-To: References: <20100817220849.68E39692@resin07.mta.everyone.net> <1885992790-1282113493-cardhu_decombobulator_blackberry.rim.net-1687831139-@bda903.bisx.prod.on.blackberry> Message-ID: On Aug 18, 2010, at 8:45 AM, Mikael Abrahamsson wrote: > On Wed, 18 Aug 2010, khatfield at socllc.net wrote: > >> More companies recycle and properly dispose of equipment than they did ten years ago. Yet, if they aren't being looked at to be "green" or something along those lines then many choose the cheapest route (the dumpster). > > The amazing thing is sometimes they will pay to have it trashed instead of the option of a recycler/reseller coming around and picking it up at no cost. > > As you said, it's just one of those things. The cables might still have some ultra-secret bits in them. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3539 bytes Desc: not available URL: From cat at reptiles.org Thu Aug 19 10:55:53 2010 From: cat at reptiles.org (Cat Okita) Date: Thu, 19 Aug 2010 11:55:53 -0400 (EDT) Subject: (cisco, or any) acl *reducers* out there? In-Reply-To: <5F0D0E5F-2BB3-43EB-B56A-F622763D78C3@apnic.net> References: <5F0D0E5F-2BB3-43EB-B56A-F622763D78C3@apnic.net> Message-ID: On Thu, 19 Aug 2010, George Michaelson wrote: > I have been looking at acl management s/w in the freecode space and I can find lots of tools which manage/distribute and test ACLs in routers. > > I'm wondering if anyone has written a parser which can construct rule-trees and get rid of the cruft, unusable, order-misorder and other issues in a large ACL pool? Something similar to this? http://www.hpl.hp.com/techreports/2008/HPL-2008-111.pdf cheers! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." From gbonser at seven.com Thu Aug 19 11:04:13 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 19 Aug 2010 09:04:13 -0700 Subject: Monitoring Tools In-Reply-To: <156125.60110.qm@web39505.mail.mud.yahoo.com> References: <20100819102312.GC82715@macbook.catpipe.net> <156125.60110.qm@web39505.mail.mud.yahoo.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52AA10@RWC-EX1.corp.seven.com> > -----Original Message----- > From: jacob miller > Sent: Thursday, August 19, 2010 4:36 AM > To: nanog at nanog.org > Subject: Re: Monitoring Tools > > Phil, > > Am looking for availability reports,bandwidth usage,alerting service > and ability to create different logins to users so they can access diff > objects > > Thnks, Jacob, I have not yet found a monitoring environment to my liking and I have seen most of them over the years. That is a project that could keep someone busy for a decade or so (and is one of the things I might work on when I retire). It seems that the more configurable they are, the less intuitive they are and more difficult to get configured properly. Many of the open source tools have only one or two active developers who also have lives outside the project and dealing with a flood of feature requests from the field can be more than they can reasonably accommodate. The commercial monitoring environments can be extremely expensive and very difficult to configure. More important than configuring them is maintaining that configuration over time as things change. I have seen many monitoring environments installed and configured only to become somewhat useless and disused over time as the configuration isn't kept up to date. Good luck in your search but in my experience it generally comes down to putting together a hodge-podge of various tools that give a specific operation the information it needs as those needs vary from one operation to the next. One problem, too, with these tools is that they often collect duplicate information. It would be nice to have some common collector/store so that other tools can pull the information out of that store. Why have three different tools querying snmp stats from the same devices? Having one collector and sharing the data would be a better approach. There is an attempt to consolidate various open source tools in a common framework called GroundWorks. They aren't completely there yet but I believe they are pointed in the right direction. George From joelja at bogus.com Thu Aug 19 11:48:43 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 19 Aug 2010 09:48:43 -0700 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: <20100819123007.GA27242@maya.aronius.com> References: <20100818200447.162288b6@opy.nosense.org> <20100819064648.6c90e970@opy.nosense.org> <20100819123007.GA27242@maya.aronius.com> Message-ID: <4C6D606B.1020403@bogus.com> On 8/19/10 5:30 AM, Joakim Aronius wrote: > * Hannes Frederic Sowa (hannes at mailcolloid.de) wrote: >> >> But most people just don't care. My proposal is to have some kind of >> sane defaults for them e.g. changing their prefix every week or in the >> case of a reconnect. This would mitigate some of the many privacy >> concerns in the internet a little bit. Of course all the already known >> problems would still exist. And still people have to care about the >> technology to reach a higher level of anonymity. > > Ok. Lets assume that the ISP hands out new prefixes to the clients CPE each week. The CPE then advertises these prefixes on the clients home network. For clients accessing the internet this works fine (except perhaps a glitch during the switchover). > > But what about the internal communication in the customer premises? How do they connect to their NAS, media players, printers, TVs etc? Of course there is UPnP, DLNA and different other kinds of magic but I imagine that most home users actually configure IP addresses at some point. manual configuration of ip address name mappings seems like a rather low priority for the average home user... I don't expect that will be a big activity in the future either, more devices means less manual intervention not more. > Constantly changing prefixes will ad another layer of complexity, things will break, and customers will be upset. (and quite frankly I don't think that you would gain that much privacy anyway) > > just my $.02 > > /Joakim > > From cvicente at network-services.uoregon.edu Thu Aug 19 11:57:08 2010 From: cvicente at network-services.uoregon.edu (Carlos Vicente) Date: Thu, 19 Aug 2010 09:57:08 -0700 Subject: Monitoring Tools In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52AA10@RWC-EX1.corp.seven.com> References: <20100819102312.GC82715@macbook.catpipe.net> <156125.60110.qm@web39505.mail.mud.yahoo.com> <5A6D953473350C4B9995546AFE9939EE0A52AA10@RWC-EX1.corp.seven.com> Message-ID: <4C6D6264.5040009@ns.uoregon.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > One problem, too, with these tools is that they often collect duplicate > information. It would be nice to have some common collector/store so > that other tools can pull the information out of that store. Why have > three different tools querying snmp stats from the same devices? Having > one collector and sharing the data would be a better approach. There is > an attempt to consolidate various open source tools in a common > framework called GroundWorks. They aren't completely there yet but I > believe they are pointed in the right direction. One approach to this problem is to use an independent device inventory database which can be used to feed configurations to all the necessary tools. This is what we've done at U. of Oregon with Netdot. See: http://www.nanog.org/meetings/nanog49/presentations/Tuesday/Vicente-netdot-presentation-nanog49.pdf cv -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFMbWJjDADXcoYj2ZwRAjfgAJ4pr+Be3EhW0fi5WNZDfrI6x0VwwgCfYa0g YFn8OhjZI44f0KKimAeKQD0= =ln/C -----END PGP SIGNATURE----- From morrowc.lists at gmail.com Thu Aug 19 12:00:37 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 19 Aug 2010 13:00:37 -0400 Subject: (cisco, or any) acl *reducers* out there? In-Reply-To: References: <5F0D0E5F-2BB3-43EB-B56A-F622763D78C3@apnic.net> Message-ID: On Thu, Aug 19, 2010 at 11:55 AM, Cat Okita wrote: > On Thu, 19 Aug 2010, George Michaelson wrote: >> >> I have been looking at acl management s/w in the freecode space and I can >> find lots of tools which manage/distribute and test ACLs in routers. >> >> I'm wondering if anyone has written a parser which can construct >> rule-trees and get rid of the cruft, unusable, order-misorder and other >> issues in a large ACL pool? > > Something similar to this? > > http://www.hpl.hp.com/techreports/2008/HPL-2008-111.pdf > this paper, while full of math and graphs and sh*t, doesn't make my acl management simpler, clearer or more complete... I keep trying to push my acls through the paper, no joy yet. there's code or something somewhere that implements the algorithms and graphs and sh*t that the paper shows in a pretty fashion? -Chris (btw, you owe me some neosporin to take care of all the paper cuts) From pl+list at pmacct.net Thu Aug 19 12:54:02 2010 From: pl+list at pmacct.net (Paolo Lucente) Date: Thu, 19 Aug 2010 17:54:02 +0000 Subject: Monitoring Tools In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52AA10@RWC-EX1.corp.seven.com> References: <20100819102312.GC82715@macbook.catpipe.net> <156125.60110.qm@web39505.mail.mud.yahoo.com> <5A6D953473350C4B9995546AFE9939EE0A52AA10@RWC-EX1.corp.seven.com> Message-ID: <20100819175402.GA20316@moussaka.pmacct.net> Too much widsom in just a single email Paolo On Thu, Aug 19, 2010 at 09:04:13AM -0700, George Bonser wrote: > > > > -----Original Message----- > > From: jacob miller > > Sent: Thursday, August 19, 2010 4:36 AM > > To: nanog at nanog.org > > Subject: Re: Monitoring Tools > > > > Phil, > > > > Am looking for availability reports,bandwidth usage,alerting service > > and ability to create different logins to users so they can access > diff > > objects > > > > Thnks, > > Jacob, > > I have not yet found a monitoring environment to my liking and I have > seen most of them over the years. That is a project that could keep > someone busy for a decade or so (and is one of the things I might work > on when I retire). It seems that the more configurable they are, the > less intuitive they are and more difficult to get configured properly. > Many of the open source tools have only one or two active developers who > also have lives outside the project and dealing with a flood of feature > requests from the field can be more than they can reasonably > accommodate. The commercial monitoring environments can be extremely > expensive and very difficult to configure. More important than > configuring them is maintaining that configuration over time as things > change. I have seen many monitoring environments installed and > configured only to become somewhat useless and disused over time as the > configuration isn't kept up to date. > > Good luck in your search but in my experience it generally comes down to > putting together a hodge-podge of various tools that give a specific > operation the information it needs as those needs vary from one > operation to the next. > > One problem, too, with these tools is that they often collect duplicate > information. It would be nice to have some common collector/store so > that other tools can pull the information out of that store. Why have > three different tools querying snmp stats from the same devices? Having > one collector and sharing the data would be a better approach. There is > an attempt to consolidate various open source tools in a common > framework called GroundWorks. They aren't completely there yet but I > believe they are pointed in the right direction. > > > George > > > > From joakim at aronius.com Thu Aug 19 12:58:32 2010 From: joakim at aronius.com (Joakim Aronius) Date: Thu, 19 Aug 2010 19:58:32 +0200 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: <4C6D606B.1020403@bogus.com> References: <20100818200447.162288b6@opy.nosense.org> <20100819064648.6c90e970@opy.nosense.org> <20100819123007.GA27242@maya.aronius.com> <4C6D606B.1020403@bogus.com> Message-ID: <20100819175832.GA2079@maya.aronius.com> * Joel Jaeggli (joelja at bogus.com) wrote: > > manual configuration of ip address name mappings seems like a rather low > priority for the average home user... > > I don't expect that will be a big activity in the future either, more > devices means less manual intervention not more. > Ok, ok, so that argument sucked. I guess I'm still stuck in the IPv4 mindset and have not yet grasped the full blessing of IPv6, zeroconf etc. etc. Anyway, constantly changing prefixes for home users still seem like begging for trouble. (Could be a service though, as mentioned, but on the other hand I expect a fair number of anonymity services to arise so charging for it might be tough.) Cheers, /Joakim From sparctacus at gmail.com Thu Aug 19 13:00:13 2010 From: sparctacus at gmail.com (Bryan Irvine) Date: Thu, 19 Aug 2010 11:00:13 -0700 Subject: Monitoring Tools In-Reply-To: <021801cb3fac$02c48730$084d9590$@net> References: <156125.60110.qm@web39505.mail.mud.yahoo.com> <4C6D35BF.8070406@brightok.net> <021801cb3fac$02c48730$084d9590$@net> Message-ID: On Thu, Aug 19, 2010 at 7:37 AM, Scott Berkman wrote: > I'd recommend ZenOSS. > > ? ? ? ?-Scott +1 -B From ernesto at cs.fiu.edu Thu Aug 19 13:04:46 2010 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Thu, 19 Aug 2010 14:04:46 -0400 Subject: Carpathia Hosting (AS29748) Contact Message-ID: <8BF98DEB-9044-413E-A266-EBDEC7AF6D79@cs.fiu.edu> Hi all, Anyone from AS29748 with peering auth, can you contact me off list? Thanks, Ernesto M. Rubi Sr. Network Engineer AMPATH/CIARA Florida International Univ, Miami Reply-to: ernesto at cs.fiu.edu From justin.horstman at gorillanation.com Thu Aug 19 13:06:20 2010 From: justin.horstman at gorillanation.com (Justin Horstman) Date: Thu, 19 Aug 2010 11:06:20 -0700 Subject: Monitoring Tools In-Reply-To: <156125.60110.qm@web39505.mail.mud.yahoo.com> References: <20100819102312.GC82715@macbook.catpipe.net> <156125.60110.qm@web39505.mail.mud.yahoo.com> Message-ID: <8C164D3BAF7C7F41B9B286385037B13102C3EDF53C@lax-exch-fe-01.gorillanation.local> > -----Original Message----- > From: jacob miller [mailto:mmzinyi at yahoo.com] > Sent: Thursday, August 19, 2010 4:36 AM > To: nanog at nanog.org > Subject: Re: Monitoring Tools > > Phil, > > Am looking for availability reports,bandwidth usage,alerting service > and ability to create different logins to users so they can access diff > objects > > Thnks, > > Jacob > Cacti with the Monitor, Nectar plugins will accomplish what you are asking and is relatively simple to setup, but I'd throw in Phpweathermap, Quicktree, and Thold for giggles, additional monitoring and the ooshiney factor. Its fairly intuitive, but in large installations you will want to look at the autom8 plugin to merely scan your subnets and add devices it finds per the rules you define. ~J From cat at reptiles.org Thu Aug 19 13:18:33 2010 From: cat at reptiles.org (Cat Okita) Date: Thu, 19 Aug 2010 14:18:33 -0400 (EDT) Subject: (cisco, or any) acl *reducers* out there? In-Reply-To: References: <5F0D0E5F-2BB3-43EB-B56A-F622763D78C3@apnic.net> Message-ID: On Thu, 19 Aug 2010, Christopher Morrow wrote: > this paper, while full of math and graphs and sh*t, doesn't make my > acl management simpler, clearer or more complete... I keep trying to > push my acls through the paper, no joy yet. > > there's code or something somewhere that implements the algorithms and > graphs and sh*t that the paper shows in a pretty fashion? Heh. Of course there's code associated with it -- how else would we have managed to come up with numbers from practical application :P OTOH, without some idea of whether it's what he had in mind, it's pointless to push the battle to go anywhere with it. There are certainly some commercial products that do what he seemed to be asking about, as well -- but I'm failing to find references to them just now (nothing like illness and deadlines). > (btw, you owe me some neosporin to take care of all the paper cuts) I've got some lovely iodine... :P cheers! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." From nathan at atlasnetworks.us Thu Aug 19 13:52:41 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Thu, 19 Aug 2010 18:52:41 +0000 Subject: Monitoring Tools In-Reply-To: <974999.79433.qm@web39501.mail.mud.yahoo.com> References: <974999.79433.qm@web39501.mail.mud.yahoo.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C281648593F@ex-mb-1.corp.atlasnetworks.us> > Am looking for an opensource network monitoring tool with ability to create > different views for different users. > > Regards,Jacob > Just to add another opinion to the pot, I've used zabbix in several large environments, and I like it a lot. The developer team is decently sized, and very responsive to requests and feedback (they operate a commercial 'support' model for the platform, so working on the system is literally their day job - as George pointed out, this is often a problem). Zabbix also supports distributed monitoring, which is very handy for scaling or for monitoring multiple locations without dealing with VPNS and the like (or if you have places you need to monitor behind NATs!). Its major weakness at the moment is the weak support for SNMP traps (works great in polling mode, though), so you will want a separate simple system for catching traps. In my opinion, that's just fine, because statistics/trending/basic resource alerting/etc are best kept separate from things like "OMG one of my powersupplies is dead!!11one". Also supports IPMI, which is nice if you have IPMI deployed. :-) Best Regards, Nathan Eisenberg From morrowc.lists at gmail.com Thu Aug 19 14:02:12 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 19 Aug 2010 15:02:12 -0400 Subject: (cisco, or any) acl *reducers* out there? In-Reply-To: References: <5F0D0E5F-2BB3-43EB-B56A-F622763D78C3@apnic.net> Message-ID: On Thu, Aug 19, 2010 at 2:18 PM, Cat Okita wrote: > On Thu, 19 Aug 2010, Christopher Morrow wrote: >> >> this paper, while full of math and graphs and sh*t, doesn't make my >> acl management simpler, clearer or more complete... I keep trying to >> push my acls through the paper, no joy yet. >> >> there's code or something somewhere that implements the algorithms and >> graphs and sh*t that the paper shows in a pretty fashion? > > Heh. ?Of course there's code associated with it -- how else would we have > managed to come up with numbers from practical application :P oh! I thought perhaps on them fancy HP 37 calculators? Seriously though, in a brief read I saw it talking about checkpoint firewall policy stuff... does the code include compiling to meta-state the policy? does it handle policy from things other than checkpoint? (like juniper router firewall syntax and pix and cisco acls?) > OTOH, without some idea of whether it's what he had in mind, it's > pointless to push the battle to go anywhere with it. > > There are certainly some commercial products that do what he seemed to be > asking about, as well -- but I'm failing to find references to them just > now (nothing like illness and deadlines). > >> (btw, you owe me some neosporin to take care of all the paper cuts) > > I've got some lovely iodine... :P excellent! I love purple skin! -chris > cheers! > ========================================================================== > "A cat spends her life conflicted between a deep, passionate and profound > desire for fish and an equally deep, passionate and profound desire to > avoid getting wet. ?This is the defining metaphor of my life right now." > From scott at sberkman.net Thu Aug 19 14:03:11 2010 From: scott at sberkman.net (Scott Berkman) Date: Thu, 19 Aug 2010 15:03:11 -0400 Subject: Monitoring Tools In-Reply-To: <8C26A4FDAE599041A13EB499117D3C281648593F@ex-mb-1.corp.atlasnetworks.us> References: <974999.79433.qm@web39501.mail.mud.yahoo.com> <8C26A4FDAE599041A13EB499117D3C281648593F@ex-mb-1.corp.atlasnetworks.us> Message-ID: <02a501cb3fd1$2cb70de0$862529a0$@net> The last time I looked, my main issue with Zabbix was that it required (or greatly preferred) their proprietary agent on every host. This may have changed. -Scott -----Original Message----- From: Nathan Eisenberg [mailto:nathan at atlasnetworks.us] Sent: Thursday, August 19, 2010 2:53 PM To: nanog at nanog.org Subject: RE: Monitoring Tools > Am looking for an opensource network monitoring tool with ability to create > different views for different users. > > Regards,Jacob > Just to add another opinion to the pot, I've used zabbix in several large environments, and I like it a lot. The developer team is decently sized, and very responsive to requests and feedback (they operate a commercial 'support' model for the platform, so working on the system is literally their day job - as George pointed out, this is often a problem). Zabbix also supports distributed monitoring, which is very handy for scaling or for monitoring multiple locations without dealing with VPNS and the like (or if you have places you need to monitor behind NATs!). Its major weakness at the moment is the weak support for SNMP traps (works great in polling mode, though), so you will want a separate simple system for catching traps. In my opinion, that's just fine, because statistics/trending/basic resource alerting/etc are best kept separate from things like "OMG one of my powersupplies is dead!!11one". Also supports IPMI, which is nice if you have IPMI deployed. :-) Best Regards, Nathan Eisenberg From michael.holstein at csuohio.edu Thu Aug 19 14:31:17 2010 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Thu, 19 Aug 2010 15:31:17 -0400 Subject: (cisco, or any) acl *reducers* out there? In-Reply-To: <5F0D0E5F-2BB3-43EB-B56A-F622763D78C3@apnic.net> References: <5F0D0E5F-2BB3-43EB-B56A-F622763D78C3@apnic.net> Message-ID: <4C6D8685.7030204@csuohio.edu> > I'm wondering if anyone has written a parser which can construct rule-trees and get rid of the cruft, unusable, order-misorder and other issues in a large ACL pool? > fwbuilder (www.fwbuilder.org) can import Cisco ACLs and impart a checkpoint-esque rule tree for you to look at, change, and test .. then recompile back into ACL syntax. Also works on IPtables, PF, and a few other things. Cheers, Michael Holstein Cleveland State University From nathan at atlasnetworks.us Thu Aug 19 14:52:22 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Thu, 19 Aug 2010 19:52:22 +0000 Subject: Monitoring Tools In-Reply-To: <02a501cb3fd1$2cb70de0$862529a0$@net> References: <974999.79433.qm@web39501.mail.mud.yahoo.com> <8C26A4FDAE599041A13EB499117D3C281648593F@ex-mb-1.corp.atlasnetworks.us> <02a501cb3fd1$2cb70de0$862529a0$@net> Message-ID: <8C26A4FDAE599041A13EB499117D3C2816485A61@ex-mb-1.corp.atlasnetworks.us> It hasn't really changed. Almost every monitoring package I've found where you want to monitor something like 'disk space free on /' requires a daemon of some sort on the host - whether that's SNMPD or their agent. FWIW, I have had their agent running on many, many servers over the years - it has never caused me a moment of heartache (for safety's sake, iptables restricts who can talk to the agent, which has its own control mechanism built in to define who it will talk to, and it runs as a restricted user, just in case). If you don't want to use their agent, you can monitor hosts via SNMP (if you run snmpd on your servers) or via server-side checks (is 80 listening? Does the site at http://www.google.com contain "I'm feeling lucky"? Can I ping 4.2.2.2? Etc...). However, the OP was about monitoring network environments (which I took to mean routers/switches/firewalls/blah, not hosts). These devices typically speak SNMP, so $MonitoringSolution will just talk SNMP to it, and you don't have to worry about any agents. :-) -Nathan > -----Original Message----- > From: Scott Berkman [mailto:scott at sberkman.net] > Sent: Thursday, August 19, 2010 12:03 PM > To: Nathan Eisenberg; nanog at nanog.org > Subject: RE: Monitoring Tools > > The last time I looked, my main issue with Zabbix was that it required (or > greatly preferred) their proprietary agent on every host. This may have > changed. > > -Scott > > -----Original Message----- > From: Nathan Eisenberg [mailto:nathan at atlasnetworks.us] > Sent: Thursday, August 19, 2010 2:53 PM > To: nanog at nanog.org > Subject: RE: Monitoring Tools > > > Am looking for an opensource network monitoring tool with ability to > create > > different views for different users. > > > > Regards,Jacob > > > > Just to add another opinion to the pot, I've used zabbix in several large > environments, and I like it a lot. The developer team is decently sized, and very > responsive to requests and feedback (they operate a commercial 'support' > model for the platform, so working on the system is literally their day job - as > George pointed out, this is often a problem). > > Zabbix also supports distributed monitoring, which is very handy for scaling or > for monitoring multiple locations without dealing with VPNS and the like (or if > you have places you need to monitor behind NATs!). Its major weakness at the > moment is the weak support for SNMP traps (works great in polling mode, > though), so you will want a separate simple system for catching traps. In my > opinion, that's just fine, because statistics/trending/basic resource alerting/etc > are best kept separate from things like "OMG one of my powersupplies is > dead!!11one". > > Also supports IPMI, which is nice if you have IPMI deployed. :-) > > Best Regards, > Nathan Eisenberg > > > > > From ekim.ittag at gmail.com Thu Aug 19 14:59:09 2010 From: ekim.ittag at gmail.com (Mike Gatti) Date: Thu, 19 Aug 2010 15:59:09 -0400 Subject: Monitoring Tools In-Reply-To: <02a501cb3fd1$2cb70de0$862529a0$@net> References: <974999.79433.qm@web39501.mail.mud.yahoo.com> <8C26A4FDAE599041A13EB499117D3C281648593F@ex-mb-1.corp.atlasnetworks.us> <02a501cb3fd1$2cb70de0$862529a0$@net> Message-ID: <09719781-7194-42CE-A23B-92A8E5E7A0CA@gmail.com> Looking at ZenOSS to compliment our OpenView NNM system. So far has been pretty simple to get up and running and the support community is pretty responsive to questions. We have cacti in our environment and it works great for pulling bandwidth, CPU, interface errors, mem utilization. the reportit plugin in particular is great for reporting bandwidth utilization for business hours. -- Mike On Aug 19, 2010, at 3:03 PM, Scott Berkman wrote: > The last time I looked, my main issue with Zabbix was that it required (or > greatly preferred) their proprietary agent on every host. This may have > changed. > > -Scott > > -----Original Message----- > From: Nathan Eisenberg [mailto:nathan at atlasnetworks.us] > Sent: Thursday, August 19, 2010 2:53 PM > To: nanog at nanog.org > Subject: RE: Monitoring Tools > >> Am looking for an opensource network monitoring tool with ability to > create >> different views for different users. >> >> Regards,Jacob >> > > Just to add another opinion to the pot, I've used zabbix in several large > environments, and I like it a lot. The developer team is decently sized, > and very responsive to requests and feedback (they operate a commercial > 'support' model for the platform, so working on the system is literally > their day job - as George pointed out, this is often a problem). > > Zabbix also supports distributed monitoring, which is very handy for scaling > or for monitoring multiple locations without dealing with VPNS and the like > (or if you have places you need to monitor behind NATs!). Its major > weakness at the moment is the weak support for SNMP traps (works great in > polling mode, though), so you will want a separate simple system for > catching traps. In my opinion, that's just fine, because > statistics/trending/basic resource alerting/etc are best kept separate from > things like "OMG one of my powersupplies is dead!!11one". > > Also supports IPMI, which is nice if you have IPMI deployed. :-) > > Best Regards, > Nathan Eisenberg > > > > =+=+=+=+=+=+=+=+=+=+=+=+= Michael Gatti cell.703.347.4412 ekim.ittag at gmail.com =+=+=+=+=+=+=+=+=+=+=+=+= From regnauld at nsrc.org Thu Aug 19 15:23:44 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 19 Aug 2010 22:23:44 +0200 Subject: Monitoring Tools In-Reply-To: <8C26A4FDAE599041A13EB499117D3C2816485A61@ex-mb-1.corp.atlasnetworks.us> References: <974999.79433.qm@web39501.mail.mud.yahoo.com> <8C26A4FDAE599041A13EB499117D3C281648593F@ex-mb-1.corp.atlasnetworks.us> <02a501cb3fd1$2cb70de0$862529a0$@net> <8C26A4FDAE599041A13EB499117D3C2816485A61@ex-mb-1.corp.atlasnetworks.us> Message-ID: <20100819202343.GC86400@macbook.catpipe.net> Nathan Eisenberg (nathan) writes: > It hasn't really changed. Almost every monitoring package I've found > where you want to monitor something like 'disk space free on /' requires > a daemon of some sort on the host - whether that's SNMPD or their agent. Anything else than SNMP is a hassle (IMHO). I understand the idea of having a dedicated agent for some hosts - Windows for instance, when querying the WMI - and often it's the only way for a vendor to have a predictable, verified element in the greater scheme (the network). But in most cases, monitoring can be achieved by extending the SNMP mib, and using and custom scripts that will report on mail queue size, in-house application status, etc... > FWIW, I have had their agent running on many, many servers over the > years - it has never caused me a moment of heartache (for safety's sake, > iptables restricts who can talk to the agent, which has its own control > mechanism built in to define who it will talk to, and it runs as a > restricted user, just in case). While developing our own monitoring product, we've had to deal with various constraints from the customer side, for instance pharmaceutical companies where there was no way installing an agent on PLC machines would pass internal audit, without having the entire system re-validated (we're talking FDA-validated medication production here). But often, SNMPD ships with or is available as an optional base component (Windows, most UNIXes) and it's easier to convince the IT suits. Go figure. Oh, and it avoided us having to install an agent on 1000+ servers :) Cheers, Phil From cmaurand at xyonet.com Thu Aug 19 15:36:13 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Thu, 19 Aug 2010 16:36:13 -0400 Subject: Monitoring Tools In-Reply-To: <20100819202343.GC86400@macbook.catpipe.net> References: <974999.79433.qm@web39501.mail.mud.yahoo.com> <8C26A4FDAE599041A13EB499117D3C281648593F@ex-mb-1.corp.atlasnetworks.us> <02a501cb3fd1$2cb70de0$862529a0$@net> <8C26A4FDAE599041A13EB499117D3C2816485A61@ex-mb-1.corp.atlasnetworks.us> <20100819202343.GC86400@macbook.catpipe.net> Message-ID: <4C6D95BD.80807@xyonet.com> On 8/19/2010 4:23 PM, Phil Regnauld wrote: > > > While developing our own monitoring product, we've had to deal with > various constraints from the customer side, for instance pharmaceutical > companies where there was no way installing an agent on PLC machines would > pass internal audit, without having the entire system re-validated (we're > talking FDA-validated medication production here). > > > But often, SNMPD ships with or is available as an optional base > component (Windows, most UNIXes) and it's easier to convince the IT > suits. Go figure. > > Oh, and it avoided us having to install an agent on 1000+ servers :) > But the configuration learning curve for SNMP is very steep indeed. --Curtis From regnauld at nsrc.org Thu Aug 19 16:13:40 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 19 Aug 2010 23:13:40 +0200 Subject: Monitoring Tools In-Reply-To: <4C6D95BD.80807@xyonet.com> References: <974999.79433.qm@web39501.mail.mud.yahoo.com> <8C26A4FDAE599041A13EB499117D3C281648593F@ex-mb-1.corp.atlasnetworks.us> <02a501cb3fd1$2cb70de0$862529a0$@net> <8C26A4FDAE599041A13EB499117D3C2816485A61@ex-mb-1.corp.atlasnetworks.us> <20100819202343.GC86400@macbook.catpipe.net> <4C6D95BD.80807@xyonet.com> Message-ID: <20100819211336.GA86701@macbook.catpipe.net> Curtis Maurand (cmaurand) writes: > > Oh, and it avoided us having to install an agent on 1000+ servers :) > > > But the configuration learning curve for SNMP is very steep indeed. Doing network monitoring and not understanding SNMP is like, umm, well I fail to come up with an analogy, but you get my drift. :) It's a bullet you'll have to bite at one point. From scott at sberkman.net Thu Aug 19 16:46:51 2010 From: scott at sberkman.net (Scott Berkman) Date: Thu, 19 Aug 2010 17:46:51 -0400 Subject: Monitoring Tools In-Reply-To: <20100819211336.GA86701@macbook.catpipe.net> References: <974999.79433.qm@web39501.mail.mud.yahoo.com> <8C26A4FDAE599041A13EB499117D3C281648593F@ex-mb-1.corp.atlasnetworks.us> <02a501cb3fd1$2cb70de0$862529a0$@net> <8C26A4FDAE599041A13EB499117D3C2816485A61@ex-mb-1.corp.atlasnetworks.us> <20100819202343.GC86400@macbook.catpipe.net> <4C6D95BD.80807@xyonet.com> <20100819211336.GA86701@macbook.catpipe.net> Message-ID: <02c001cb3fe8$08a2f150$19e8d3f0$@net> Agreed. And it REALLY isn't that complicated. Go spend some time with CORBA or TL-1 and then re-evaluate the learning curve. SNMP is really very straight forward as a protocol. If a specific vendor's MIB is difficult to understand or use, that is an entirely different matter. -Scott -----Original Message----- From: Phil Regnauld [mailto:regnauld at nsrc.org] Sent: Thursday, August 19, 2010 5:14 PM To: Curtis Maurand Cc: nanog at nanog.org Subject: Re: Monitoring Tools Curtis Maurand (cmaurand) writes: > > Oh, and it avoided us having to install an agent on 1000+ servers :) > > > But the configuration learning curve for SNMP is very steep indeed. Doing network monitoring and not understanding SNMP is like, umm, well I fail to come up with an analogy, but you get my drift. :) It's a bullet you'll have to bite at one point. From nanog at michaelosburn.com Thu Aug 19 16:50:12 2010 From: nanog at michaelosburn.com (Michael Osburn) Date: Thu, 19 Aug 2010 15:50:12 -0600 Subject: Monitoring Tools In-Reply-To: <02c001cb3fe8$08a2f150$19e8d3f0$@net> References: <974999.79433.qm@web39501.mail.mud.yahoo.com> <8C26A4FDAE599041A13EB499117D3C281648593F@ex-mb-1.corp.atlasnetworks.us> <02a501cb3fd1$2cb70de0$862529a0$@net> <8C26A4FDAE599041A13EB499117D3C2816485A61@ex-mb-1.corp.atlasnetworks.us> <20100819202343.GC86400@macbook.catpipe.net> <4C6D95BD.80807@xyonet.com> <20100819211336.GA86701@macbook.catpipe.net> <02c001cb3fe8$08a2f150$19e8d3f0$@net> Message-ID: Vendor MIBs are the worst part of any new monitoring project. It is made even worse when they change them ever so slightly during an upgrade making your free disk space show as -2tb... On Aug 19, 2010 3:47 PM, "Scott Berkman" wrote: > Agreed. And it REALLY isn't that complicated. Go spend some time with > CORBA or TL-1 and then re-evaluate the learning curve. > > SNMP is really very straight forward as a protocol. If a specific vendor's > MIB is difficult to understand or use, that is an entirely different matter. > > -Scott > > -----Original Message----- > From: Phil Regnauld [mailto:regnauld at nsrc.org] > Sent: Thursday, August 19, 2010 5:14 PM > To: Curtis Maurand > Cc: nanog at nanog.org > Subject: Re: Monitoring Tools > > Curtis Maurand (cmaurand) writes: >> > Oh, and it avoided us having to install an agent on 1000+ servers :) >> > >> But the configuration learning curve for SNMP is very steep indeed. > > Doing network monitoring and not understanding SNMP is like, > umm, well I fail to come up with an analogy, but you get my drift. > > :) > > It's a bullet you'll have to bite at one point. > > > From leen at consolejunkie.net Thu Aug 19 16:54:41 2010 From: leen at consolejunkie.net (Leen Besselink) Date: Thu, 19 Aug 2010 23:54:41 +0200 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: <20100819175832.GA2079@maya.aronius.com> References: <20100818200447.162288b6@opy.nosense.org> <20100819064648.6c90e970@opy.nosense.org> <20100819123007.GA27242@maya.aronius.com> <4C6D606B.1020403@bogus.com> <20100819175832.GA2079@maya.aronius.com> Message-ID: <4C6DA821.4070200@consolejunkie.net> On 08/19/2010 07:58 PM, Joakim Aronius wrote: > * Joel Jaeggli (joelja at bogus.com) wrote: > >> manual configuration of ip address name mappings seems like a rather low >> priority for the average home user... >> >> I don't expect that will be a big activity in the future either, more >> devices means less manual intervention not more. >> >> > Ok, ok, so that argument sucked. I guess I'm still stuck in the IPv4 mindset and have not yet grasped the full blessing of IPv6, zeroconf etc. etc. > > Anyway, constantly changing prefixes for home users still seem like begging for trouble. (Could be a service though, as mentioned, but on the other hand I expect a fair number of anonymity services to arise so charging for it might be tough.) > > Cheers, > /Joakim > > > > If you still want fairly static addressing for your local network, there is always ULA. And those addresses do not leak to the outside world. I'm surprised no one mentioned it, maybe I missed it. I can understand if people don't recommend them because you mentioned end-user, but it might be useful to a poweruser. You could have your DSL- or cable-router/-modem onetime generate a ULA and have RA/DHCPv6 distribute that to the devices in the network like the addresses it gets from the provider. From carlosm at antel.net.uy Thu Aug 19 17:01:31 2010 From: carlosm at antel.net.uy (Carlos M. Martinez) Date: Thu, 19 Aug 2010 19:01:31 -0300 Subject: Monitoring Tools In-Reply-To: <4C6D95BD.80807@xyonet.com> References: <974999.79433.qm@web39501.mail.mud.yahoo.com> <8C26A4FDAE599041A13EB499117D3C281648593F@ex-mb-1.corp.atlasnetworks.us> <02a501cb3fd1$2cb70de0$862529a0$@net> <8C26A4FDAE599041A13EB499117D3C2816485A61@ex-mb-1.corp.atlasnetworks.us> <20100819202343.GC86400@macbook.catpipe.net> <4C6D95BD.80807@xyonet.com> Message-ID: <4C6DA9BB.9080503@antel.net.uy> On 8/19/2010 5:36 PM, Curtis Maurand wrote: >> > But the configuration learning curve for SNMP is very steep indeed. > > --Curtis > > For some esoteric topics (dynamic tables, AgentX) this might be true, however, you can get 80% of the benefit of SNMP with 20% of the whole thing. It's a query/response protocol with a tree-based data model. That's it. warm regards Carlos From warren at kumari.net Thu Aug 19 20:09:07 2010 From: warren at kumari.net (Warren Kumari) Date: Thu, 19 Aug 2010 21:09:07 -0400 Subject: Monitoring Tools In-Reply-To: <20100819102312.GC82715@macbook.catpipe.net> References: <974999.79433.qm@web39501.mail.mud.yahoo.com> <20100819102312.GC82715@macbook.catpipe.net> Message-ID: <6708EB00-6CF6-4B2A-9F28-7DABDBE13443@kumari.net> On Aug 19, 2010, at 6:23 AM, Phil Regnauld wrote: > jacob miller (mmzinyi) writes: >> Am looking for an opensource network monitoring tool with ability to create different views for different users. >> > > Hi Jacob, > > What kind of network monitoring ? Bandwidth utilization, service > availability, RTT, statistics data collection, ... ? > > There are tons of open source software tools out there: > > Nagios (www.nagios.org) > Zabbix (www.zabbix.com) > OpenNMS (www.opennms.org) > ZenOSS (www.zenoss.com) > SmokePing (http://oss.oetiker.ch/smokeping/) > Cacti (www.cacti.netl) > NetFlow Dashboard (http://trac.netflowdashboard.com/netflowdashboard/) > NFSen (http://nfsen.sourceforge.net/) > > > etc... > > Depends on what you want to achieve! Yes, yes it does... This is a (dated, but still good) introduction that you might want to read: http://www.nanog.org/meetings/nanog26/presentations/stephen.pdf Joe Abley and Stephen Stuart from NANOG26! W > > Cheers, > Phil > > From nanog-02 at jeremykister.com Thu Aug 19 23:20:58 2010 From: nanog-02 at jeremykister.com (Jeremy Kister) Date: Fri, 20 Aug 2010 00:20:58 -0400 Subject: Monitoring Tools In-Reply-To: <974999.79433.qm@web39501.mail.mud.yahoo.com> References: <974999.79433.qm@web39501.mail.mud.yahoo.com> Message-ID: <4C6E02AA.4030800@jeremykister.com> On 8/19/2010 5:23 AM, jacob miller wrote: > Am looking for an opensource network monitoring tool with ability to create different views for different users. http://argus.tcp4me.com in your ~argus/data/users file (or equivalent) specify for example, for an admin (root) type user: admin asdfasdfasdf1 Top root or, for someone who only gets a partial view: acme qwerqwerqwer1 Top:custs:acme acme see http://argus.tcp4me.com/users.html -- Jeremy Kister http://jeremy.kister.net./ From julien at gormotte.info Fri Aug 20 02:40:26 2010 From: julien at gormotte.info (Julien Gormotte) Date: Fri, 20 Aug 2010 09:40:26 +0200 Subject: Monitoring Tools In-Reply-To: <974999.79433.qm@web39501.mail.mud.yahoo.com> References: <974999.79433.qm@web39501.mail.mud.yahoo.com> Message-ID: <4C6E316A.9040909@gormotte.info> Le 19/08/2010 11:23, jacob miller a ?crit : > Am looking for an opensource network monitoring tool with ability to create different views for different users. > > Regards,Jacob > Hello, Maybe nagvis could be what you need ? Julien From bethjohnson5060 at gmail.com Fri Aug 20 08:39:29 2010 From: bethjohnson5060 at gmail.com (Beth Johnson) Date: Fri, 20 Aug 2010 06:39:29 -0700 Subject: tool to wrangle config file changes In-Reply-To: References: Message-ID: http://www.cfengine.org/ On Wed, Aug 18, 2010 at 5:16 PM, Rogelio wrote: > Long story short, a really crappy vendor is being shoved down our > NOC's throat. They have a horrid CLI (if you can call it that). > People don't understand it (it's non-intuitive) and are screwing up > things all the time. > > In the hopes of coping with the madness, some of us are looking to put > together some sort of open source configuration management tool, such > as RANCID. Any luck with this on non-standard equipment, particularly > ones that DO NOT allow you to output something nice and "scriptable" > (e.g. Cisco's "show running-config") > > (If not RANCID, any other suggestions?) > > From lists at memetic.org Fri Aug 20 09:51:06 2010 From: lists at memetic.org (Adam Armstrong) Date: Fri, 20 Aug 2010 15:51:06 +0100 Subject: Monitoring Tools In-Reply-To: <974999.79433.qm@web39501.mail.mud.yahoo.com> References: <974999.79433.qm@web39501.mail.mud.yahoo.com> Message-ID: <4C6E965A.1030602@memetic.org> On 19/08/2010 10:23, jacob miller wrote: > Am looking for an opensource network monitoring tool with ability to create different views for different users. You could try our mildly unconventional NMS project : http://www.observium.org We try to focus on collection and presentation of information. We have the ability to have different views for different users (commonly used to give customers access to certain devices/ports). We're by no means feature complete for your requirements, but if you've good ideas for features we might be able to implement them for you. adam. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Aug 20 09:58:06 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 21 Aug 2010 00:28:06 +0930 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: <20100819123007.GA27242@maya.aronius.com> References: <20100818200447.162288b6@opy.nosense.org> <20100819064648.6c90e970@opy.nosense.org> <20100819123007.GA27242@maya.aronius.com> Message-ID: <20100821002806.2f99d9bd@opy.nosense.org> On Thu, 19 Aug 2010 14:30:07 +0200 Joakim Aronius wrote: > * Hannes Frederic Sowa (hannes at mailcolloid.de) wrote: > > > > But most people just don't care. My proposal is to have some kind of > > sane defaults for them e.g. changing their prefix every week or in the > > case of a reconnect. This would mitigate some of the many privacy > > concerns in the internet a little bit. Of course all the already known > > problems would still exist. And still people have to care about the > > technology to reach a higher level of anonymity. > > Ok. Lets assume that the ISP hands out new prefixes to the clients CPE each week. The CPE then advertises these prefixes on the clients home network. For clients accessing the internet this works fine (except perhaps a glitch during the switchover). > > But what about the internal communication in the customer premises? How do they connect to their NAS, media players, printers, TVs etc? Of course there is UPnP, DLNA and different other kinds of magic but I imagine that most home users actually configure IP addresses at some point. > > Constantly changing prefixes will ad another layer of complexity, things will break, and customers will be upset. (and quite frankly I don't think that you would gain that much privacy anyway) > ULA - RFC4193. (People really need to stop thinking in IPv4 mode when discussing IPv6 ....) > just my $.02 > > /Joakim > From christopher.morrow at gmail.com Fri Aug 20 12:20:58 2010 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Fri, 20 Aug 2010 13:20:58 -0400 Subject: Should routers send redirects by default? Message-ID: Polling a little bit here, there's an active discussion going on 6man at ietf about whether or not v6 routers should: o be required to implement ip redirect functions (icmpv6 redirect) o be sending these by default Essentially 12+ years ago in RFC2461 (http://www.ietf.org/rfc/rfc2461.txt) and later in RFC4861 (http://tools.ietf.org/html/rfc4861) there are a set of message types defined and use cases discussed which seem to lead to the idea that: routers should be reqiured to implement redirect logic/functionality routers should by default be enabled to send these redirect messages. In ipv4 there's a relatively widely used practice of disabling ip redirects. secure router and secure host templates disable this functionality, and have for quite some time. There are a host of reasons for this I don't really want to debate them though :) It would be instructive to get a sense of how many folks do NOT disable this sort of thing, or how many folks RELY on these functions working in their network build today. For the 6man discussion though, I presume that in ipv4 we take a set of configs/actions because of somewhat sane reasons, I suspect we would want to have the same config/end-state in v6? One proposal is to do this with: o routers are required to be able to send redirect messages o routers should NOT do this by default With the proviso that some consenting adults may choose to enable by default on certain platforms (cabl/dsl CPE, enterprise-LAN)... if that muddies the waters it'd be nice to just hear about the proposal there and leave the hinkiness of the rest out of the picture :) I hope that folks who currently run v6 network(s) might respond, there are quite a few v6 operators here... I'm looking at you owen/jjb/au-dsl-folk... :) thanks for your time, of couse if you want to chat more directly about this the 6man list is open and at: -Chris From jbates at brightok.net Fri Aug 20 12:25:40 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 20 Aug 2010 12:25:40 -0500 Subject: Should routers send redirects by default? In-Reply-To: References: Message-ID: <4C6EBA94.8040205@brightok.net> Why should the ietf dictate a default on this? Requiring implementation I could understand, but setting the default? Should the ietf also specify requirement of allowing configuration change of a default? Honestly, redirects are not near the problem as icmp unreachables. Jack Christopher Morrow wrote: > Polling a little bit here, there's an active discussion going on > 6man at ietf about whether or not v6 routers should: > o be required to implement ip redirect functions (icmpv6 redirect) > o be sending these by default > > Essentially 12+ years ago in RFC2461 > (http://www.ietf.org/rfc/rfc2461.txt) and later in RFC4861 > (http://tools.ietf.org/html/rfc4861) there are a set of message types > defined and use cases discussed which seem to lead to the idea that: > routers should be reqiured to implement redirect logic/functionality > routers should by default be enabled to send these redirect messages. > > In ipv4 there's a relatively widely used practice of disabling ip > redirects. secure router and secure host templates disable this > functionality, and have for quite some time. There are a host of > reasons for this I don't really want to debate them though :) It would > be instructive to get a sense of how many folks do NOT disable this > sort of thing, or how many folks RELY on these functions working in > their network build today. > > For the 6man discussion though, I presume that in ipv4 we take a set > of configs/actions because of somewhat sane reasons, I suspect we > would want to have the same config/end-state in v6? One proposal is to > do this with: > o routers are required to be able to send redirect messages > o routers should NOT do this by default > > With the proviso that some consenting adults may choose to enable by > default on certain platforms (cabl/dsl CPE, enterprise-LAN)... if that > muddies the waters it'd be nice to just hear about the proposal there > and leave the hinkiness of the rest out of the picture :) I hope that > folks who currently run v6 network(s) might respond, there are quite a > few v6 operators here... I'm looking at you owen/jjb/au-dsl-folk... :) > > thanks for your time, of couse if you want to chat more directly about > this the 6man list is open and at: > > > -Chris From swmike at swm.pp.se Fri Aug 20 12:40:46 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 20 Aug 2010 19:40:46 +0200 (CEST) Subject: Should routers send redirects by default? In-Reply-To: <4C6EBA94.8040205@brightok.net> References: <4C6EBA94.8040205@brightok.net> Message-ID: On Fri, 20 Aug 2010, Jack Bates wrote: > Why should the ietf dictate a default on this? Because that's what the IETF does, sets a SHOULD on "best common practice" after discussion in the community. > Requiring implementation I could understand, but setting the default? > Should the ietf also specify requirement of allowing configuration > change of a default? I'd say by definition it's meaningless of talking about a default that can't be changed. As I stated in the 6man discussion, I prefer routers to by default not send redirects. We do that in our configuration template. -- Mikael Abrahamsson email: swmike at swm.pp.se From jbates at brightok.net Fri Aug 20 12:44:52 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 20 Aug 2010 12:44:52 -0500 Subject: Should routers send redirects by default? In-Reply-To: References: <4C6EBA94.8040205@brightok.net> Message-ID: <4C6EBF14.6040709@brightok.net> Mikael Abrahamsson wrote: > As I stated in the 6man discussion, I prefer routers to by default not > send redirects. We do that in our configuration template. > I often turn them off, but I'm not sure why. If they aren't needed, generally they won't be issued anyways (p2p links, router only segments, etc). About the only case where they might be issued and I don't want them is in policy routing situations. In host based broadcast domains, I usually want them to limit the amount of traffic redirection I need to do. Jack From rdobbins at arbor.net Fri Aug 20 12:56:51 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 20 Aug 2010 17:56:51 +0000 Subject: Should routers send redirects by default? In-Reply-To: References: Message-ID: On Aug 21, 2010, at 12:20 AM, Christopher Morrow wrote: > o routers are required to be able to send redirect messages > o routers should NOT do this by default I concur with this position from an opsec standpoint; at the same time, I don't know that *mandating* a default configuration setting for a legal (if largely iatrogenic) mode of operation is something that the IETF should be doing. Here's an alternate formulation which gets the point across, but doesn't stray into the area of : 1. Routers are required to be able to send redirect messages. 2. It is recommended that routers should NOT do this by default. As was mentioned somewhere in the 6man thread, the root of the problem has to do with the ugliness of IPv6 in general, and the whole v6 ICMP/ND mess in particular. Unfortunately, those ships have long since sailed; while it's tempting to try and retrofit fixes for poor design decisions in the fundamental protocol specifications by mandating sane implementation defaults in conformance documents, a recommendation rather than a mandate seems more situationally-appropriate in this context. The 'right way', impractical though it may be, is in fact to fix this problem is to go back and fix the protocol specifications; since that isn't going to happen, making recommendations gets the point across without being overbearing. YMMV, of course. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From cscora at apnic.net Fri Aug 20 13:26:13 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 21 Aug 2010 04:26:13 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201008201826.o7KIQDCb009320@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 21 Aug, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 328585 Prefixes after maximum aggregation: 151394 Deaggregation factor: 2.17 Unique aggregates announced to Internet: 161190 Total ASes present in the Internet Routing Table: 34625 Prefixes per ASN: 9.49 Origin-only ASes present in the Internet Routing Table: 30038 Origin ASes announcing only one prefix: 14583 Transit ASes present in the Internet Routing Table: 4587 Transit-only ASes present in the Internet Routing Table: 105 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (41664) 21 Prefixes from unregistered ASNs in the Routing Table: 1213 Unregistered ASNs in the Routing Table: 618 Number of 32-bit ASNs allocated by the RIRs: 740 Prefixes from 32-bit ASNs in the Routing Table: 925 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 170 Number of addresses announced to Internet: 2258724928 Equivalent to 134 /8s, 161 /16s and 104 /24s Percentage of available address space announced: 60.9 Percentage of allocated address space announced: 65.1 Percentage of available address space allocated: 93.7 Percentage of address space in use by end-sites: 84.4 Total number of prefixes smaller than registry allocations: 155755 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 80054 Total APNIC prefixes after maximum aggregation: 27467 APNIC Deaggregation factor: 2.91 Prefixes being announced from the APNIC address blocks: 76989 Unique aggregates announced from the APNIC address blocks: 33885 APNIC Region origin ASes present in the Internet Routing Table: 4163 APNIC Prefixes per ASN: 18.49 APNIC Region origin ASes announcing only one prefix: 1166 APNIC Region transit ASes present in the Internet Routing Table: 641 Average APNIC Region AS path length visible: 3.7 Max APNIC Region AS path length visible: 21 Number of APNIC addresses announced to Internet: 541568800 Equivalent to 32 /8s, 71 /16s and 175 /24s Percentage of available APNIC address space announced: 76.9 APNIC AS Blocks 4608-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, 14/8, 27/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 135154 Total ARIN prefixes after maximum aggregation: 69850 ARIN Deaggregation factor: 1.93 Prefixes being announced from the ARIN address blocks: 107936 Unique aggregates announced from the ARIN address blocks: 42495 ARIN Region origin ASes present in the Internet Routing Table: 13862 ARIN Prefixes per ASN: 7.79 ARIN Region origin ASes announcing only one prefix: 5313 ARIN Region transit ASes present in the Internet Routing Table: 1369 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 731597472 Equivalent to 43 /8s, 155 /16s and 74 /24s Percentage of available ARIN address space announced: 62.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 75066 Total RIPE prefixes after maximum aggregation: 43881 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 68498 Unique aggregates announced from the RIPE address blocks: 45003 RIPE Region origin ASes present in the Internet Routing Table: 14701 RIPE Prefixes per ASN: 4.66 RIPE Region origin ASes announcing only one prefix: 7570 RIPE Region transit ASes present in the Internet Routing Table: 2202 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 24 Number of RIPE addresses announced to Internet: 436120704 Equivalent to 25 /8s, 254 /16s and 172 /24s Percentage of available RIPE address space announced: 76.5 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 29723 Total LACNIC prefixes after maximum aggregation: 7064 LACNIC Deaggregation factor: 4.21 Prefixes being announced from the LACNIC address blocks: 28237 Unique aggregates announced from the LACNIC address blocks: 15039 LACNIC Region origin ASes present in the Internet Routing Table: 1332 LACNIC Prefixes per ASN: 21.20 LACNIC Region origin ASes announcing only one prefix: 410 LACNIC Region transit ASes present in the Internet Routing Table: 239 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 20 Number of LACNIC addresses announced to Internet: 76854656 Equivalent to 4 /8s, 148 /16s and 181 /24s Percentage of available LACNIC address space announced: 57.3 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7417 Total AfriNIC prefixes after maximum aggregation: 1893 AfriNIC Deaggregation factor: 3.92 Prefixes being announced from the AfriNIC address blocks: 5736 Unique aggregates announced from the AfriNIC address blocks: 1684 AfriNIC Region origin ASes present in the Internet Routing Table: 395 AfriNIC Prefixes per ASN: 14.52 AfriNIC Region origin ASes announcing only one prefix: 124 AfriNIC Region transit ASes present in the Internet Routing Table: 88 Average AfriNIC Region AS path length visible: 3.7 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 20171264 Equivalent to 1 /8s, 51 /16s and 202 /24s Percentage of available AfriNIC address space announced: 60.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1864 8412 498 Korea Telecom (KIX) 4755 1477 298 162 TATA Communications formerly 7545 1380 234 86 TPG Internet Pty Ltd 17488 1341 151 131 Hathway IP Over Cable Interne 17974 1217 293 76 PT TELEKOMUNIKASI INDONESIA 9583 1010 75 494 Sify Limited 24560 996 303 179 Bharti Airtel Ltd., Telemedia 4808 898 1671 245 CNCGROUP IP network: China169 9829 819 689 35 BSNL National Internet Backbo 4134 796 22476 419 CHINANET-BACKBONE Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3850 3684 276 bellsouth.net, inc. 4323 2710 1116 395 Time Warner Telecom 19262 1800 4623 274 Verizon Global Networks 1785 1790 698 131 PaeTec Communications, Inc. 20115 1490 1527 653 Charter Communications 7018 1482 5736 956 AT&T WorldNet Services 6478 1301 272 125 AT&T Worldnet Services 2386 1287 554 909 AT&T Data Communications Serv 11492 1243 214 117 Cable One 22773 1177 2858 61 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 449 2026 390 TDC Tele Danmark 30890 443 99 211 Evolva Telecom 702 413 1870 326 UUNET - Commercial IP service 8866 403 117 18 Bulgarian Telecommunication C 8551 401 353 46 Bezeq International 3320 377 7329 326 Deutsche Telekom AG 3301 374 1416 329 TeliaNet Sweden 34984 367 89 182 BILISIM TELEKOM 12479 353 576 5 Uni2 Autonomous System 3215 321 3202 93 France Telecom Transpac Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1528 3049 247 UniNet S.A. de C.V. 10620 1093 244 150 TVCABLE BOGOTA 28573 1071 834 110 NET Servicos de Comunicao S.A 6503 811 187 263 AVANTEL, S.A. 7303 791 408 101 Telecom Argentina Stet-France 14420 552 35 78 CORPORACION NACIONAL DE TELEC 22047 549 310 15 VTR PUNTO NET S.A. 7738 477 922 30 Telecomunicacoes da Bahia S.A 3816 476 209 99 Empresa Nacional de Telecomun 11172 447 99 76 Servicios Alestra S.A de C.V Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1163 445 10 TEDATA 24863 728 147 39 LINKdotNET AS number 36992 657 279 183 Etisalat MISR 3741 270 898 232 The Internet Solution 33776 209 12 12 Starcomms Nigeria Limited 2018 197 277 64 Tertiary Education Network 6713 195 186 16 Itissalat Al-MAGHRIB 24835 193 78 9 RAYA Telecom - Egypt 29571 193 19 11 Ci Telecom Autonomous system 16637 149 440 95 MTN Network Solutions Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3850 3684 276 bellsouth.net, inc. 4323 2710 1116 395 Time Warner Telecom 4766 1864 8412 498 Korea Telecom (KIX) 19262 1800 4623 274 Verizon Global Networks 1785 1790 698 131 PaeTec Communications, Inc. 8151 1528 3049 247 UniNet S.A. de C.V. 20115 1490 1527 653 Charter Communications 7018 1482 5736 956 AT&T WorldNet Services 4755 1477 298 162 TATA Communications formerly 7545 1380 234 86 TPG Internet Pty Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2710 2315 Time Warner Telecom 1785 1790 1659 PaeTec Communications, Inc. 19262 1800 1526 Verizon Global Networks 4766 1864 1366 Korea Telecom (KIX) 4755 1477 1315 TATA Communications formerly 7545 1380 1294 TPG Internet Pty Ltd 8151 1528 1281 UniNet S.A. de C.V. 17488 1341 1210 Hathway IP Over Cable Interne 6478 1301 1176 AT&T Worldnet Services 8452 1163 1153 TEDATA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16734 UNALLOCATED 8.18.204.0/24 26914 Global Netoptex, Inc 22015 UNALLOCATED 8.22.137.0/24 14989 Broadview Networks 46856 UNALLOCATED 8.22.184.0/22 3561 Savvis 26169 UNALLOCATED 8.225.177.0/24 20225 TelJet 32249 UNALLOCATED 8.225.178.0/24 3356 Level 3 Communicatio 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 23054 UNALLOCATED 12.18.240.0/24 7018 AT&T WorldNet Servic 33198 UNALLOCATED 12.19.149.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.189.0/24 6453 Teleglobe Inc. 41.223.196.0/24 36990 Alkan Telecom Ltd 41.223.197.0/24 36990 Alkan Telecom Ltd 41.223.198.0/24 36990 Alkan Telecom Ltd 41.223.199.0/24 36990 Alkan Telecom Ltd Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:25 /11:67 /12:198 /13:413 /14:722 /15:1311 /16:11218 /17:5411 /18:9272 /19:18562 /20:23351 /21:23365 /22:30395 /23:29879 /24:171207 /25:1056 /26:1192 /27:734 /28:118 /29:47 /30:6 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2463 3850 bellsouth.net, inc. 4766 1487 1864 Korea Telecom (KIX) 4323 1373 2710 Time Warner Telecom 1785 1253 1790 PaeTec Communications, Inc. 11492 1086 1243 Cable One 17488 1084 1341 Hathway IP Over Cable Interne 18566 1068 1087 Covad Communications 8452 1052 1163 TEDATA 10620 1006 1093 TVCABLE BOGOTA 24560 895 996 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:55 2:2 4:13 8:299 12:2009 13:7 14:1 15:21 16:3 17:9 20:6 24:1430 27:297 31:1 32:61 33:22 38:698 40:97 41:2518 44:3 46:26 47:16 52:12 55:7 56:2 57:29 58:800 59:506 60:460 61:1075 62:1063 63:1968 64:3733 65:2309 66:4010 67:1823 68:1105 69:2771 70:745 71:357 72:1941 73:2 74:2318 75:263 76:327 77:889 78:618 79:438 80:1017 81:798 82:504 83:490 84:691 85:1047 86:473 87:692 88:307 89:1519 90:99 91:2974 92:417 93:1005 94:1176 95:679 96:521 97:216 98:612 99:34 108:64 109:635 110:449 111:542 112:277 113:312 114:447 115:574 116:1095 117:658 118:491 119:888 120:140 121:716 122:1532 123:945 124:1125 125:1246 128:227 129:164 130:201 131:539 132:247 133:16 134:195 135:45 136:237 137:135 138:270 139:105 140:474 141:197 142:342 143:374 144:472 145:52 146:413 147:172 148:677 149:303 150:153 151:228 152:299 153:169 154:3 155:361 156:166 157:328 158:118 159:361 160:316 161:183 162:255 163:168 164:414 165:367 166:457 167:413 168:652 169:159 170:718 171:60 172:2 173:981 174:511 175:154 176:1 177:1 178:406 180:586 181:1 182:169 183:238 184:210 186:565 187:423 188:796 189:759 190:3959 192:5761 193:4741 194:3418 195:2780 196:1186 198:3570 199:3575 200:5399 201:1586 202:8034 203:8262 204:4015 205:2393 206:2486 207:3063 208:3889 209:3466 210:2562 211:1315 212:1765 213:1682 214:658 215:67 216:4693 217:1556 218:502 219:379 220:1142 221:404 222:316 223:3 End of report From butche at butchevans.com Fri Aug 20 14:56:06 2010 From: butche at butchevans.com (Butch Evans) Date: Fri, 20 Aug 2010 14:56:06 -0500 Subject: Should routers send redirects by default? In-Reply-To: References: Message-ID: <1282334166.29483.291.camel@localhost.localdomain> On Fri, 2010-08-20 at 13:20 -0400, Christopher Morrow wrote: > Polling a little bit here, there's an active discussion going on > 6man at ietf about whether or not v6 routers should: > o be required to implement ip redirect functions (icmpv6 redirect) > o be sending these by default I do not currently have an IPv6 deployment, so my input may be lacking in real usefulness here. With IPv4, however, I have been a little irritated at a few situations where I NEEDED this to work and it did not (certain PIX routers come to mind here). There are risks involved with ANY "automated" type traffic to be sure, but for my money, it SHOULD be possible to configure every router to support the network needs. So for my money, I'd suggest: * routers MUST support ip redirect * "default" configurations irrelevant to me I do agree with one or two of the other posters that it should not be within the purview of the IETF to "mandate" these defaults. Each of us will learn the defaults of the particular gear we use and can adjust config templates to match, given the needs of the network we are deploying. Just my $0.02 (may be worth less than that) :-) -- ******************************************************************** * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/ * Network Engineering * * http://store.wispgear.net/ * Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * ******************************************************************** From jared at puck.nether.net Fri Aug 20 15:03:54 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 20 Aug 2010 16:03:54 -0400 Subject: Should routers send redirects by default? In-Reply-To: <1282334166.29483.291.camel@localhost.localdomain> References: <1282334166.29483.291.camel@localhost.localdomain> Message-ID: On Aug 20, 2010, at 3:56 PM, Butch Evans wrote: > On Fri, 2010-08-20 at 13:20 -0400, Christopher Morrow wrote: >> Polling a little bit here, there's an active discussion going on >> 6man at ietf about whether or not v6 routers should: >> o be required to implement ip redirect functions (icmpv6 redirect) >> o be sending these by default > > I do not currently have an IPv6 deployment, so my input may be lacking > in real usefulness here. With IPv4, however, I have been a little > irritated at a few situations where I NEEDED this to work and it did not > (certain PIX routers come to mind here). There are risks involved with > ANY "automated" type traffic to be sure, but for my money, it SHOULD be > possible to configure every router to support the network needs. So for > my money, I'd suggest: > > * routers MUST support ip redirect > * "default" configurations irrelevant to me > > I do agree with one or two of the other posters that it should not be > within the purview of the IETF to "mandate" these defaults. Each of us > will learn the defaults of the particular gear we use and can adjust > config templates to match, given the needs of the network we are > deploying. Just my $0.02 (may be worth less than that) :-) One of the challenges is that some vendors have a poor track-record of documenting these defaults. this means unless you frequently sample your network traffic, you may not see your device sending decnet mop messages, or ipv6 redirects :) Personally (and as the instigator in the ipv6/6man discussion) if the vendors could be trusted to expose their default settings in their configs, i would find a default of ON to be more acceptable. As their track-record is poor, and the harm has been realized in the network we operate (at least), I am advocating that as a matter of policy enabling redirects not be a default-on policy. If people want to hang themselves that's their problem, but at least they won't come with a hidden noose around their neck. - Jared From owen at delong.com Fri Aug 20 15:10:25 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 20 Aug 2010 13:10:25 -0700 Subject: Should routers send redirects by default? In-Reply-To: References: Message-ID: <2DDE1669-EF8B-4C64-9DBD-F2F2C9F0425D@delong.com> Redirects in IPv6 are no worse nor better an idea than unauthenticated RAs for default routers with nearly identical security implications. Owen Sent from my iPad On Aug 20, 2010, at 10:20 AM, Christopher Morrow wrote: > Polling a little bit here, there's an active discussion going on > 6man at ietf about whether or not v6 routers should: > o be required to implement ip redirect functions (icmpv6 redirect) > o be sending these by default > > Essentially 12+ years ago in RFC2461 > (http://www.ietf.org/rfc/rfc2461.txt) and later in RFC4861 > (http://tools.ietf.org/html/rfc4861) there are a set of message types > defined and use cases discussed which seem to lead to the idea that: > routers should be reqiured to implement redirect logic/functionality > routers should by default be enabled to send these redirect messages. > > In ipv4 there's a relatively widely used practice of disabling ip > redirects. secure router and secure host templates disable this > functionality, and have for quite some time. There are a host of > reasons for this I don't really want to debate them though :) It would > be instructive to get a sense of how many folks do NOT disable this > sort of thing, or how many folks RELY on these functions working in > their network build today. > > For the 6man discussion though, I presume that in ipv4 we take a set > of configs/actions because of somewhat sane reasons, I suspect we > would want to have the same config/end-state in v6? One proposal is to > do this with: > o routers are required to be able to send redirect messages > o routers should NOT do this by default > > With the proviso that some consenting adults may choose to enable by > default on certain platforms (cabl/dsl CPE, enterprise-LAN)... if that > muddies the waters it'd be nice to just hear about the proposal there > and leave the hinkiness of the rest out of the picture :) I hope that > folks who currently run v6 network(s) might respond, there are quite a > few v6 operators here... I'm looking at you owen/jjb/au-dsl-folk... :) > > thanks for your time, of couse if you want to chat more directly about > this the 6man list is open and at: > > > -Chris From christopher.morrow at gmail.com Fri Aug 20 16:05:43 2010 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Fri, 20 Aug 2010 17:05:43 -0400 Subject: Should routers send redirects by default? In-Reply-To: <2DDE1669-EF8B-4C64-9DBD-F2F2C9F0425D@delong.com> References: <2DDE1669-EF8B-4C64-9DBD-F2F2C9F0425D@delong.com> Message-ID: On Fri, Aug 20, 2010 at 4:10 PM, Owen DeLong wrote: > Redirects in IPv6 are no worse nor better an idea than unauthenticated RAs for default routers with nearly identical security implications. this answered a different question... wanna try answering the question I posed originally? :) -chris > Owen > > > Sent from my iPad > > On Aug 20, 2010, at 10:20 AM, Christopher Morrow wrote: > >> Polling a little bit here, there's an active discussion going on >> 6man at ietf about whether or not v6 routers should: >> ?o be required to implement ip redirect functions (icmpv6 redirect) >> ?o be sending these by default >> >> Essentially 12+ years ago in RFC2461 >> (http://www.ietf.org/rfc/rfc2461.txt) and later in RFC4861 >> (http://tools.ietf.org/html/rfc4861) there are a set of message types >> defined and use cases discussed which seem to lead to the idea that: >> ?routers should be reqiured to implement redirect logic/functionality >> ?routers should by default be enabled to send these redirect messages. >> >> In ipv4 there's a relatively widely used practice of disabling ip >> redirects. secure router and secure host templates disable this >> functionality, and have for quite some time. There are a host of >> reasons for this I don't really want to debate them though :) It would >> be instructive to get a sense of how many folks do NOT disable this >> sort of thing, or how many folks RELY on these functions working in >> their network build today. >> >> For the 6man discussion though, I presume that in ipv4 we take a set >> of configs/actions because of somewhat sane reasons, I suspect we >> would want to have the same config/end-state in v6? One proposal is to >> do this with: >> ?o routers are required to be able to send redirect messages >> ?o routers should NOT do this by default >> >> With the proviso that some consenting adults may choose to enable by >> default on certain platforms (cabl/dsl CPE, enterprise-LAN)... if that >> muddies the waters it'd be nice to just hear about the proposal there >> and leave the hinkiness of the rest out of the picture :) I hope that >> folks who currently run v6 network(s) might respond, there are quite a >> few v6 operators here... I'm looking at you owen/jjb/au-dsl-folk... :) >> >> thanks for your time, of couse if you want to chat more directly about >> this the 6man list is open and at: >> ? >> >> -Chris > From butche at butchevans.com Fri Aug 20 16:08:19 2010 From: butche at butchevans.com (Butch Evans) Date: Fri, 20 Aug 2010 16:08:19 -0500 Subject: Should routers send redirects by default? In-Reply-To: References: <1282334166.29483.291.camel@localhost.localdomain> Message-ID: <1282338499.29483.297.camel@localhost.localdomain> On Fri, 2010-08-20 at 16:03 -0400, Jared Mauch wrote: > One of the challenges is that some vendors have a poor track-record of > documenting these defaults. this means unless you frequently sample > your network traffic, you may not see your device sending decnet mop > messages, or ipv6 redirects :) I agree. > Personally (and as the instigator in the ipv6/6man discussion) if the > vendors could be trusted to expose their default settings in their > configs, i would find a default of ON to be more acceptable. The reason it doesn't matter to me WHICH one it is (on OR off) is because if/when a need arises to have ICMP redirect to be working (this is the exception and NOT the norm), it is easy to see why things do not work as expected. If my preferred gear is a Linux box (and it is, usually), and for some reason I need this to work, I simply run a tcpdump to capture the packets and I see that the redirect (which would be expected) is missing, then I can easily fix the problem by enabling that feature. Same is true for the reverse. > If people want to hang themselves > that's their problem, but at least they won't come with a hidden noose > around their neck. Maybe I'm missing something. Can you point me to something that will help my understand WHY an ICMP redirect is such a huge security concern? For most of the networks that I manage (or help to manage), I can see no reason why this would be an issue. -- ******************************************************************** * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/ * Network Engineering * * http://store.wispgear.net/ * Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * ******************************************************************** From christopher.morrow at gmail.com Fri Aug 20 16:11:55 2010 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Fri, 20 Aug 2010 17:11:55 -0400 Subject: Should routers send redirects by default? In-Reply-To: References: <1282334166.29483.291.camel@localhost.localdomain> Message-ID: On Fri, Aug 20, 2010 at 4:03 PM, Jared Mauch wrote: > > On Aug 20, 2010, at 3:56 PM, Butch Evans wrote: > >> On Fri, 2010-08-20 at 13:20 -0400, Christopher Morrow wrote: >>> Polling a little bit here, there's an active discussion going on >>> 6man at ietf about whether or not v6 routers should: >>> ?o be required to implement ip redirect functions (icmpv6 redirect) >>> ?o be sending these by default >> >> I do not currently have an IPv6 deployment, so my input may be lacking >> in real usefulness here. ?With IPv4, however, I have been a little >> irritated at a few situations where I NEEDED this to work and it did not >> (certain PIX routers come to mind here). ?There are risks involved with >> ANY "automated" type traffic to be sure, but for my money, it SHOULD be >> possible to configure every router to support the network needs. ?So for >> my money, I'd suggest: >> >> * routers MUST support ip redirect >> * "default" configurations irrelevant to me >> >> I do agree with one or two of the other posters that it should not be >> within the purview of the IETF to "mandate" these defaults. ?Each of us >> will learn the defaults of the particular gear we use and can adjust >> config templates to match, given the needs of the network we are >> deploying. ?Just my $0.02 (may be worth less than that) ?:-) > > One of the challenges is that some vendors have a poor track-record of > documenting these defaults. ?this means unless you frequently sample and changing them... so, picking a good default I think is important. You'd prefer less config headaches I bet vs having to constantly hack templates? > your network traffic, you may not see your device sending decnet mop > messages, or ipv6 redirects :) > > Personally (and as the instigator in the ipv6/6man discussion) if the yes thanks! :) (just following a path as requested by another 6man person) > vendors could be trusted to expose their default settings in their > configs, i would find a default of ON to be more acceptable. ?As their > track-record is poor, and the harm has been realized in the network we > operate (at least), I am advocating that as a matter of policy enabling > redirects not be a default-on policy. ?If people want to hang themselves > that's their problem, but at least they won't come with a hidden noose > around their neck. yes, that was my point as well. -chris > - Jared > From christopher.morrow at gmail.com Fri Aug 20 16:14:14 2010 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Fri, 20 Aug 2010 17:14:14 -0400 Subject: Should routers send redirects by default? In-Reply-To: References: <4C6EBA94.8040205@brightok.net> Message-ID: On Fri, Aug 20, 2010 at 1:40 PM, Mikael Abrahamsson wrote: > On Fri, 20 Aug 2010, Jack Bates wrote: > >> Why should the ietf dictate a default on this? > > Because that's what the IETF does, sets a SHOULD on "best common practice" > after discussion in the community. > >> Requiring implementation I could understand, but setting the default? >> Should the ietf also specify requirement of allowing configuration change of >> a default? > > I'd say by definition it's meaningless of talking about a default that can't > be changed. > > As I stated in the 6man discussion, I prefer routers to by default not send > redirects. We do that in our configuration template. as always, thanks! :) I am hoping we all don't have to continue to hack templates, if the option is sane to begin with and is documented in the code/config/docs by the vendor(s). -Chris From franck at genius.com Fri Aug 20 16:27:03 2010 From: franck at genius.com (Franck Martin) Date: Sat, 21 Aug 2010 09:27:03 +1200 (FJT) Subject: IPv6 PMTUD and OS-X In-Reply-To: <8955944.577.1282339354317.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <29058450.586.1282339621475.JavaMail.franck@franck-martins-macbook-pro.local> I'm trying to debug a pesky PMTUD issue with IPv6 on Mac OS-X 10.6. It happens only from home, on wireless, when connected to a mac aiport that does an automatic tunnel (teredo) to IPv6 backbone. There are IPv6 web site that I cannot browse until I lower the MTU to 1400. My Linux desktop in similar config works fine... With tracepath6, I see one end of the tunnel tells me MTU should be 1280, that's using linux tools. On mac, tracepath6 does not seem to exist, and I don't know what tool to use... I have seen scamper, but no binary... I have used wireshark (on mac) to detect the PTB packet, but don't see it either... I have not compared with my linux box... I'm doing this testing on the side, slowly because it is fun to try to understand what's wrong here... and I wonder if others have had similar issues... May be not fully on topic, but to bring it back to topic see this presentation: http://www.ripe.net/ripe/meetings/ripe-60/presentations/Stasiewicz-Measurements_of_IPv6_Path_MTU_Discovery_Behaviour.pdf Which states the PMTUD failure rate on IPv6 is about 1.9% From jeroen at unfix.org Fri Aug 20 16:34:23 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 20 Aug 2010 23:34:23 +0200 Subject: IPv6 PMTUD and OS-X In-Reply-To: <29058450.586.1282339621475.JavaMail.franck@franck-martins-macbook-pro.local> References: <29058450.586.1282339621475.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4C6EF4DF.90709@unfix.org> On 2010-08-20 23:27, Franck Martin wrote: > I'm trying to debug a pesky PMTUD issue with IPv6 on Mac OS-X 10.6. > > It happens only from home, on wireless, when connected to a mac aiport > that does an automatic tunnel (teredo) to IPv6 backbone. Welcome to the great world of Teredo/6to4 where the endpoints/relays of the tunnel are anycasted in both IPv4 and IPv6 and thus can be quite difficult to debug, it can be done but requires quite a lot of vision in the network on both IPv4 and which will be generally near impossible. > There are IPv6 web site that I cannot browse until I lower the MTU to 1400. Why don't you just do 1280 which is the default? Do also note that you have two levels of PMTU, the IPv6 one and the IPv4 one. If you configure your MTU of the tunnel incorrectly compared to the relay that you are using you will not see the PMTU's coming through either or they might not accept your large packets. Both MTUs can be broken due to folks filtering ICMP which is generally a bad thing to do. Greets, Jeroen From Valdis.Kletnieks at vt.edu Fri Aug 20 16:54:32 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 20 Aug 2010 17:54:32 -0400 Subject: Should routers send redirects by default? In-Reply-To: Your message of "Fri, 20 Aug 2010 16:08:19 CDT." <1282338499.29483.297.camel@localhost.localdomain> References: <1282334166.29483.291.camel@localhost.localdomain> <1282338499.29483.297.camel@localhost.localdomain> Message-ID: <156200.1282341272@localhost> On Fri, 20 Aug 2010 16:08:19 CDT, Butch Evans said: > Maybe I'm missing something. Can you point me to something that will > help my understand WHY an ICMP redirect is such a huge security concern? > For most of the networks that I manage (or help to manage), I can see no > reason why this would be an issue. In general, it's not a big deal, except that unlike a proper routing protocol where you can redirect a /16 or a /default at a time and withdraw it when needed, ICMP redirects tend to form host routes that have to individually be redirected back if the routing flips back to its original status. Until a PC or something on the network gets pwned, and issues selective forged ICMP redirects to declare itself a router and the appropriate destination for some traffic, which it can then MITM to its heart's content. *Then* you truly have a manure-on-fan situation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From cidr-report at potaroo.net Fri Aug 20 17:00:03 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Aug 2010 22:00:03 GMT Subject: BGP Update Report Message-ID: <201008202200.o7KM03KW025630@wattle.apnic.net> BGP Update Report Interval: 12-Aug-10 -to- 19-Aug-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS3303 26875 2.2% 144.5 -- SWISSCOM Swisscom (Switzerland) Ltd 2 - AS3464 26141 2.2% 2010.8 -- ASC-NET - Alabama Supercomputer Network 3 - AS7552 22624 1.9% 28.1 -- VIETEL-AS-AP Vietel Corporation 4 - AS21332 21803 1.8% 427.5 -- NTC-AS JSC "NTC" (New Telephone Company) 5 - AS7018 17719 1.5% 5.4 -- ATT-INTERNET4 - AT&T WorldNet Services 6 - AS5416 16956 1.4% 144.9 -- BATELCO-BH 7 - AS5536 14238 1.2% 135.6 -- Internet-Egypt 8 - AS45464 12413 1.0% 326.7 -- NEXTWEB-AS-AP Room 201, TGU Bldg 9 - AS3816 11661 1.0% 28.0 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 10 - AS11351 11526 0.9% 36.2 -- RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 11 - AS32528 10734 0.9% 2683.5 -- ABBOTT Abbot Labs 12 - AS35931 10633 0.9% 3544.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 13 - AS8452 10213 0.8% 15.2 -- TEDATA TEDATA 14 - AS10474 10205 0.8% 275.8 -- NETACTIVE 15 - AS6503 10190 0.8% 9.6 -- Axtel, S.A.B. de C. V. 16 - AS8151 9378 0.8% 18.1 -- Uninet S.A. de C.V. 17 - AS31204 8006 0.7% 307.9 -- SUNCOMMUNICATIONS-AS JV "Sun Communications" Autonomous System 18 - AS21017 7945 0.7% 794.5 -- VSI-AS VSI AS 19 - AS5800 7078 0.6% 37.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 20 - AS17894 5987 0.5% 285.1 -- APMI-AS-AP AyalaPort Makati, Inc. / Data Center Operator TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS35931 10633 0.9% 3544.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 2 - AS32528 10734 0.9% 2683.5 -- ABBOTT Abbot Labs 3 - AS3464 26141 2.2% 2010.8 -- ASC-NET - Alabama Supercomputer Network 4 - AS3 1788 0.1% 181.0 -- PREDATOR-AS LTD Predatori 5 - AS2472 3361 0.3% 1680.5 -- FR-DOM-GUYANE Guyane Francaise 6 - AS53532 1528 0.1% 1528.0 -- KINGMETALS - King Architectural Metals 7 - AS48565 1390 0.1% 1390.0 -- POCZTAPOLSKA-AS Poczta Polska Spolka Akcyjna 8 - AS21184 3806 0.3% 1268.7 -- FARPOST Farpost Int. 9 - AS11196 1127 0.1% 1127.0 -- NESTLE-USA - Nestle USA 10 - AS26615 993 0.1% 993.0 -- Tim Celular S.A. 11 - AS47144 822 0.1% 822.0 -- WELLNET-AS LLC "WellNet" 12 - AS53083 802 0.1% 802.0 -- 13 - AS21017 7945 0.7% 794.5 -- VSI-AS VSI AS 14 - AS11613 786 0.1% 786.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 15 - AS50010 1353 0.1% 676.5 -- NAWRAS-AS Omani Qatari Telecommunications Company SAOC 16 - AS16861 458 0.0% 458.0 -- REVELEX - Revelex.com 17 - AS9556 1714 0.1% 428.5 -- ADAM-AS-AP Adam Internet Pty Ltd 18 - AS21332 21803 1.8% 427.5 -- NTC-AS JSC "NTC" (New Telephone Company) 19 - AS26383 2986 0.2% 426.6 -- CHILITECH - CHILITECH INTERNET SOLUTIONS, INC. 20 - AS45936 345 0.0% 345.0 -- AE-MANILA-AS-AP Affinity Express TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 129.66.128.0/17 13061 1.0% AS3464 -- ASC-NET - Alabama Supercomputer Network 2 - 129.66.0.0/17 13058 1.0% AS3464 -- ASC-NET - Alabama Supercomputer Network 3 - 196.2.16.0/24 10063 0.8% AS10474 -- NETACTIVE 4 - 63.211.68.0/22 6107 0.5% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - 190.65.228.0/22 5588 0.4% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 6 - 130.36.34.0/24 5355 0.4% AS32528 -- ABBOTT Abbot Labs 7 - 130.36.35.0/24 5352 0.4% AS32528 -- ABBOTT Abbot Labs 8 - 148.204.141.0/24 5100 0.4% AS8151 -- Uninet S.A. de C.V. 9 - 216.126.136.0/22 4768 0.4% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 10 - 198.140.43.0/24 4519 0.3% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 11 - 84.255.152.0/24 4066 0.3% AS5416 -- BATELCO-BH 12 - 84.255.146.0/24 4061 0.3% AS5416 -- BATELCO-BH 13 - 84.255.145.0/24 4060 0.3% AS5416 -- BATELCO-BH 14 - 84.255.147.0/24 4057 0.3% AS5416 -- BATELCO-BH 15 - 95.32.128.0/18 3954 0.3% AS21017 -- VSI-AS VSI AS 16 - 95.32.192.0/18 3951 0.3% AS21017 -- VSI-AS VSI AS 17 - 203.28.157.0/24 3419 0.3% AS4802 -- ASN-IINET iiNet Limited 18 - 93.81.204.0/23 3050 0.2% AS8402 -- CORBINA-AS Corbina Telecom 19 - 206.184.16.0/24 3036 0.2% AS174 -- COGENT Cogent/PSI 20 - 202.92.235.0/24 2211 0.2% AS9498 -- BBIL-AP BHARTI Airtel Ltd. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Aug 20 17:00:01 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Aug 2010 22:00:01 GMT Subject: The Cidr Report Message-ID: <201008202200.o7KM019R025625@wattle.apnic.net> This report has been generated at Fri Aug 20 21:12:23 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 Prefixes CIDR Agg 13-08-10 331362 204688 14-08-10 331685 204585 15-08-10 331552 204754 16-08-10 331652 205014 17-08-10 331723 205160 18-08-10 331801 205480 19-08-10 333149 205770 20-08-10 333340 205938 AS Summary 35161 Number of ASes in routing system 14950 Number of ASes announcing only one prefix 4451 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 97264960 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'). --- 20Aug10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 333341 205949 127392 38.2% All ASes AS6389 3848 281 3567 92.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4451 1843 2608 58.6% TWTC - tw telecom holdings, inc. AS19262 1800 274 1526 84.8% VZGNI-TRANSIT - Verizon Online LLC AS4766 1864 512 1352 72.5% KIXS-AS-KR Korea Telecom AS22773 1178 66 1112 94.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1478 425 1053 71.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS18566 1087 63 1024 94.2% COVAD - Covad Communications Co. AS5668 1114 99 1015 91.1% AS-5668 - CenturyTel Internet Holdings, Inc. AS17488 1341 326 1015 75.7% HATHWAY-NET-AP Hathway IP Over Cable Internet AS6478 1301 374 927 71.3% ATT-INTERNET3 - AT&T WorldNet Services AS8151 1526 638 888 58.2% Uninet S.A. de C.V. AS10620 1094 287 807 73.8% Telmex Colombia S.A. AS8452 1162 425 737 63.4% TEDATA TEDATA AS7545 1402 723 679 48.4% TPG-INTERNET-AP TPG Internet Pty Ltd AS7303 790 114 676 85.6% Telecom Argentina S.A. AS4808 898 277 621 69.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS1785 1790 1180 610 34.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS4804 678 73 605 89.2% MPX-AS Microplex PTY LTD AS13343 965 376 589 61.0% SCRR-13343 - Road Runner HoldCo LLC AS7552 654 91 563 86.1% VIETEL-AS-AP Vietel Corporation AS4780 691 161 530 76.7% SEEDNET Digital United Inc. AS7018 1480 956 524 35.4% ATT-INTERNET4 - AT&T WorldNet Services AS28573 1071 558 513 47.9% NET Servicos de Comunicao S.A. AS17676 576 76 500 86.8% GIGAINFRA Softbank BB Corp. AS3356 1149 674 475 41.3% LEVEL3 Level 3 Communications AS7011 1132 658 474 41.9% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS22047 549 76 473 86.2% VTR BANDA ANCHA S.A. AS14420 552 83 469 85.0% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS24560 996 533 463 46.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS36992 657 209 448 68.2% ETISALAT-MISR Total 39274 12431 26843 68.3% Top 30 total Possible Bogus Routes 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.189.0/24 AS6453 GLOBEINTERNET TATA Communications 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 116.68.136.0/21 AS28045 Pantel Communications 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.51.100.0/24 AS16953 ASCENT-MEDIA-GROUP-LLC - Ascent Media Group, LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 204.238.70.0/24 AS36826 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.196.24.0/22 AS33724 BIZNESSHOSTING - VOLICO 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.72.192.0/23 AS27375 IDS-TELECOM - IDS Telecom 206.72.194.0/23 AS27375 IDS-TELECOM - IDS Telecom 206.72.196.0/23 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 206.72.208.0/24 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.209.0/24 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 208.84.76.0/22 AS18561 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From butche at butchevans.com Fri Aug 20 17:04:35 2010 From: butche at butchevans.com (Butch Evans) Date: Fri, 20 Aug 2010 17:04:35 -0500 Subject: Should routers send redirects by default? In-Reply-To: <156200.1282341272@localhost> References: <1282334166.29483.291.camel@localhost.localdomain> <1282338499.29483.297.camel@localhost.localdomain> <156200.1282341272@localhost> Message-ID: <1282341875.29483.301.camel@localhost.localdomain> On Fri, 2010-08-20 at 17:54 -0400, Valdis.Kletnieks at vt.edu wrote: > Until a PC or something on the network gets pwned, and issues selective forged > ICMP redirects to declare itself a router and the appropriate destination for > some traffic, which it can then MITM to its heart's content. *Then* you truly > have a manure-on-fan situation. While I don't disagree with your assessment, isn't this true beyond JUST this one function? I mean, if I understand the "problem" correctly, is it the EXISTENCE of ICMP redirect that is the "security hole" or is it that it is used by a router? Don't most host operating systems ignore an ICMP redirect for a host if they are not asking for a route anyway? (I'm not sure I stated that very well...) In other words, ICMP redirect is NOT a broadcast and so it would be ignored if it wasn't directed to my specific MAC. Am I mistaken in that assumption? -- ******************************************************************** * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/ * Network Engineering * * http://store.wispgear.net/ * Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * ******************************************************************** From franck at genius.com Fri Aug 20 17:09:14 2010 From: franck at genius.com (Franck Martin) Date: Sat, 21 Aug 2010 10:09:14 +1200 (FJT) Subject: IPv6 PMTUD and OS-X In-Reply-To: <4C6EF4DF.90709@unfix.org> Message-ID: <23967857.615.1282342151403.JavaMail.franck@franck-martins-macbook-pro.local> What puzzles me, is that my linux machine on same network has no issues... ----- Original Message ----- From: "Jeroen Massar" To: "Franck Martin" Cc: nanog at nanog.org Sent: Saturday, 21 August, 2010 9:34:23 AM Subject: Re: IPv6 PMTUD and OS-X On 2010-08-20 23:27, Franck Martin wrote: > I'm trying to debug a pesky PMTUD issue with IPv6 on Mac OS-X 10.6. > > It happens only from home, on wireless, when connected to a mac aiport > that does an automatic tunnel (teredo) to IPv6 backbone. Welcome to the great world of Teredo/6to4 where the endpoints/relays of the tunnel are anycasted in both IPv4 and IPv6 and thus can be quite difficult to debug, it can be done but requires quite a lot of vision in the network on both IPv4 and which will be generally near impossible. > There are IPv6 web site that I cannot browse until I lower the MTU to 1400. Why don't you just do 1280 which is the default? Do also note that you have two levels of PMTU, the IPv6 one and the IPv4 one. If you configure your MTU of the tunnel incorrectly compared to the relay that you are using you will not see the PMTU's coming through either or they might not accept your large packets. Both MTUs can be broken due to folks filtering ICMP which is generally a bad thing to do. Greets, Jeroen From bross at pobox.com Fri Aug 20 17:16:35 2010 From: bross at pobox.com (Brandon Ross) Date: Fri, 20 Aug 2010 18:16:35 -0400 (EDT) Subject: Should routers send redirects by default? In-Reply-To: <156200.1282341272@localhost> References: <1282334166.29483.291.camel@localhost.localdomain> <1282338499.29483.297.camel@localhost.localdomain> <156200.1282341272@localhost> Message-ID: On Fri, 20 Aug 2010, Valdis.Kletnieks at vt.edu wrote: > Until a PC or something on the network gets pwned, and issues selective forged > ICMP redirects to declare itself a router and the appropriate destination for > some traffic, which it can then MITM to its heart's content. *Then* you truly > have a manure-on-fan situation. I believe the question was along the lines of, "why do I turn this off on my router?" How does turning off ICMP redirects on the router prevent a rouge PC from sending ICMP redirects to it's neighbors? I'm in the same boat here. I know there's a lot of conventional wisdom that says to turn it off, but I'm yet to hear a convincing argument as to why I should bother. Now configuring your hosts to ignore them, that I could understand. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From jared at puck.nether.net Fri Aug 20 17:29:07 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 20 Aug 2010 18:29:07 -0400 Subject: Should routers send redirects by default? In-Reply-To: References: <1282334166.29483.291.camel@localhost.localdomain> <1282338499.29483.297.camel@localhost.localdomain> <156200.1282341272@localhost> Message-ID: <1E8FD27F-3952-45A7-A025-C417314EC742@puck.nether.net> See below Jared Mauch On Aug 20, 2010, at 6:16 PM, Brandon Ross wrote: > On Fri, 20 Aug 2010, Valdis.Kletnieks at vt.edu wrote: > >> Until a PC or something on the network gets pwned, and issues selective forged >> ICMP redirects to declare itself a router and the appropriate destination for >> some traffic, which it can then MITM to its heart's content. *Then* you truly >> have a manure-on-fan situation. > > I believe the question was along the lines of, "why do I turn this off on my router?" > > How does turning off ICMP redirects on the router prevent a rouge PC from sending ICMP redirects to it's neighbors? > > I'm in the same boat here. I know there's a lot of conventional wisdom that says to turn it off, but I'm yet to hear a convincing argument as to why I should bother. Now configuring your hosts to ignore them, that I could understand. The issue is routers typically do this in software requiring a punt and CPU theft from bgp, ospf etc. > > -- > Brandon Ross AIM: BrandonNRoss > ICQ: 2269442 > Skype: brandonross Yahoo: BrandonNRoss From owen at delong.com Fri Aug 20 17:34:17 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 20 Aug 2010 15:34:17 -0700 Subject: Should routers send redirects by default? In-Reply-To: <156200.1282341272@localhost> References: <1282334166.29483.291.camel@localhost.localdomain> <1282338499.29483.297.camel@localhost.localdomain> <156200.1282341272@localhost> Message-ID: <4DB601C2-426D-4FAA-B837-750EECC3D85E@delong.com> On Aug 20, 2010, at 2:54 PM, Valdis.Kletnieks at vt.edu wrote: > On Fri, 20 Aug 2010 16:08:19 CDT, Butch Evans said: > >> Maybe I'm missing something. Can you point me to something that will >> help my understand WHY an ICMP redirect is such a huge security concern? >> For most of the networks that I manage (or help to manage), I can see no >> reason why this would be an issue. > > In general, it's not a big deal, except that unlike a proper routing protocol > where you can redirect a /16 or a /default at a time and withdraw it when > needed, ICMP redirects tend to form host routes that have to individually be > redirected back if the routing flips back to its original status. > > Until a PC or something on the network gets pwned, and issues selective forged > ICMP redirects to declare itself a router and the appropriate destination for > some traffic, which it can then MITM to its heart's content. *Then* you truly > have a manure-on-fan situation. This is worse than said PC issuing rogue RAs exactly how? Perhaps we should pressure switch vendors to add ICMP Redirect protection to the RA Guard feature they haven't implemented yet? Owen From bross at pobox.com Fri Aug 20 17:36:22 2010 From: bross at pobox.com (Brandon Ross) Date: Fri, 20 Aug 2010 18:36:22 -0400 (EDT) Subject: Should routers send redirects by default? In-Reply-To: <1E8FD27F-3952-45A7-A025-C417314EC742@puck.nether.net> References: <1282334166.29483.291.camel@localhost.localdomain> <1282338499.29483.297.camel@localhost.localdomain> <156200.1282341272@localhost> <1E8FD27F-3952-45A7-A025-C417314EC742@puck.nether.net> Message-ID: On Fri, 20 Aug 2010, Jared Mauch wrote: > The issue is routers typically do this in software requiring a punt and > CPU theft from bgp, ospf etc. You mean like ICMP echo, ICMP can't fragment, ICMP unreachable...? -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From jared at puck.nether.net Fri Aug 20 18:16:08 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 20 Aug 2010 19:16:08 -0400 Subject: Should routers send redirects by default? In-Reply-To: References: <1282334166.29483.291.camel@localhost.localdomain> <1282338499.29483.297.camel@localhost.localdomain> <156200.1282341272@localhost> <1E8FD27F-3952-45A7-A025-C417314EC742@puck.nether.net> Message-ID: <5647079B-5E51-4BEC-8690-FF1D47D17489@puck.nether.net> Yea the stuff that sometimes is done in hw and sometimes in sw and causes varying pain. You may find the discussion interesting to read if you feel redirects are "ok" or tolerable. If vendors can't expose their defaults they really should not be enabling these things as it causes trouble. I've had problems with both v4 and v6 redirects. Perhaps you have not. Jared Mauch On Aug 20, 2010, at 6:36 PM, Brandon Ross wrote: > On Fri, 20 Aug 2010, Jared Mauch wrote: > >> The issue is routers typically do this in software requiring a punt and CPU theft from bgp, ospf etc. > > You mean like ICMP echo, ICMP can't fragment, ICMP unreachable...? > > -- > Brandon Ross AIM: BrandonNRoss > ICQ: 2269442 > Skype: brandonross Yahoo: BrandonNRoss From jared at puck.nether.net Fri Aug 20 18:21:14 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 20 Aug 2010 19:21:14 -0400 Subject: Should routers send redirects by default? In-Reply-To: <4DB601C2-426D-4FAA-B837-750EECC3D85E@delong.com> References: <1282334166.29483.291.camel@localhost.localdomain> <1282338499.29483.297.camel@localhost.localdomain> <156200.1282341272@localhost> <4DB601C2-426D-4FAA-B837-750EECC3D85E@delong.com> Message-ID: <8FC5103C-F8B3-40B6-A195-9860D6C6C611@puck.nether.net> See below Jared Mauch On Aug 20, 2010, at 6:34 PM, Owen DeLong wrote: > > On Aug 20, 2010, at 2:54 PM, Valdis.Kletnieks at vt.edu wrote: > >> On Fri, 20 Aug 2010 16:08:19 CDT, Butch Evans said: >> >>> Maybe I'm missing something. Can you point me to something that will >>> help my understand WHY an ICMP redirect is such a huge security concern? >>> For most of the networks that I manage (or help to manage), I can see no >>> reason why this would be an issue. >> >> In general, it's not a big deal, except that unlike a proper routing protocol >> where you can redirect a /16 or a /default at a time and withdraw it when >> needed, ICMP redirects tend to form host routes that have to individually be >> redirected back if the routing flips back to its original status. >> >> Until a PC or something on the network gets pwned, and issues selective forged >> ICMP redirects to declare itself a router and the appropriate destination for >> some traffic, which it can then MITM to its heart's content. *Then* you truly >> have a manure-on-fan situation. > > This is worse than said PC issuing rogue RAs exactly how? > > Perhaps we should pressure switch vendors to add ICMP Redirect > protection to the RA Guard feature they haven't implemented yet? One of my points is that redirects are routing updates of a dynamic nature. If the hosts are intended to participate in the routing process perhaps they should speak a protocol that can be secured further vs something that can't. Please join the discussion on ipv6 at ietf. It's part of a router and host requirements document. > > Owen > > From Valdis.Kletnieks at vt.edu Fri Aug 20 18:31:38 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 20 Aug 2010 19:31:38 -0400 Subject: Should routers send redirects by default? In-Reply-To: Your message of "Fri, 20 Aug 2010 18:16:35 EDT." References: <1282334166.29483.291.camel@localhost.localdomain> <1282338499.29483.297.camel@localhost.localdomain> <156200.1282341272@localhost> Message-ID: <158470.1282347098@localhost> On Fri, 20 Aug 2010 18:16:35 EDT, Brandon Ross said: > How does turning off ICMP redirects on the router prevent a rouge PC from > sending ICMP redirects to it's neighbors? If I know for a fact that the network is designed such that I will never ever receive a valid ICMP redirect because there is exactly one route off the network, I can safely turn off "accept ICMP redirects" and be done with it. If I have to allow ICMP in, it becomes a much more interesting iptables/whatever issue. On Fri, 20 Aug 2010 15:34:17 PDT, Owen DeLong said: > This is worse than said PC issuing rogue RAs exactly how? It's the exact same problem, actually. > Perhaps we should pressure switch vendors to add ICMP Redirect > protection to the RA Guard feature they haven't implemented yet? You mean you aren't already? ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jfbeam at gmail.com Fri Aug 20 18:49:43 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 20 Aug 2010 19:49:43 -0400 Subject: Should routers send redirects by default? In-Reply-To: References: Message-ID: On Fri, 20 Aug 2010 13:20:58 -0400, Christopher Morrow wrote: > Polling a little bit here, there's an active discussion going on > 6man at ietf about whether or not v6 routers should: > o be required to implement ip redirect functions (icmpv6 redirect) > o be sending these by default ... > In ipv4 there's a relatively widely used practice of disabling ip > redirects. I think it's almost universally disabled (by default) everywhere in IPv4 purely for security (traffic interception.) In a perfectly run network, redirects should never be necessary, so I'd think IPv6 should avoid going down that road again. (support OPTIONAL, never enabled by default.) [It's another insecure mistake IPv6 doesn't need to repeat.] As I recall from long long ago, Cisco IOS would deal with traffic differently depending on redirects... with redirects enabled, a redirect was sent and the packet dropped; with redirects disabled, the router hairpined the packets. I honestly don't know what today's versions do because I've never checked -- A can ping B, I move on. I turn redirects off on *outside* interfaces. Inside (trustable) interfaces vary -- I don't go out of my way to disable them. --Ricky From bross at pobox.com Fri Aug 20 19:08:34 2010 From: bross at pobox.com (Brandon Ross) Date: Fri, 20 Aug 2010 20:08:34 -0400 (EDT) Subject: Should routers send redirects by default? In-Reply-To: References: Message-ID: On Fri, 20 Aug 2010, Ricky Beam wrote: > I think it's almost universally disabled (by default) everywhere in IPv4 > purely for security (traffic interception.) Okay, I'll ask again. Exactly how does disabling ICMP redirects on my router prevent traffic from being intercepted? -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Aug 20 19:43:39 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 21 Aug 2010 10:13:39 +0930 Subject: Should routers send redirects by default? In-Reply-To: References: Message-ID: <20100821101339.7e5d8e62@opy.nosense.org> On Fri, 20 Aug 2010 19:49:43 -0400 "Ricky Beam" wrote: > On Fri, 20 Aug 2010 13:20:58 -0400, Christopher Morrow > wrote: > > Polling a little bit here, there's an active discussion going on > > 6man at ietf about whether or not v6 routers should: > > o be required to implement ip redirect functions (icmpv6 redirect) > > o be sending these by default > ... > > In ipv4 there's a relatively widely used practice of disabling ip > > redirects. > > I think it's almost universally disabled (by default) everywhere in IPv4 > purely for security (traffic interception.) In a perfectly run network, > redirects should never be necessary, so I'd think IPv6 should avoid going > down that road again. (support OPTIONAL, never enabled by default.) [It's > another insecure mistake IPv6 doesn't need to repeat.] > You're assuming the cost of always hair pinning traffic on an interface is cheaper than issuing a redirect. Sometimes it won't be. 1 ICMP redirect could result in potentially congestion inducing load being shifted off of a single router's interface. It seems that there might be a common and unstated assumption here that ever router uses hardware forwarding and has high speed 1Gbps+ interfaces that have <50% utilisation. The majority of routers - CPE - don't meet that assumption. > As I recall from long long ago, Cisco IOS would deal with traffic > differently depending on redirects... with redirects enabled, a redirect > was sent and the packet dropped; with redirects disabled, the router > hairpined the packets. I honestly don't know what today's versions do > because I've never checked -- A can ping B, I move on. I turn redirects > off on *outside* interfaces. Inside (trustable) interfaces vary -- I > don't go out of my way to disable them. > > --Ricky > From leen at consolejunkie.net Fri Aug 20 20:01:16 2010 From: leen at consolejunkie.net (Leen Besselink) Date: Sat, 21 Aug 2010 03:01:16 +0200 Subject: Should routers send redirects by default? In-Reply-To: References: Message-ID: <4C6F255C.3030302@consolejunkie.net> On 08/21/2010 02:08 AM, Brandon Ross wrote: > On Fri, 20 Aug 2010, Ricky Beam wrote: > >> I think it's almost universally disabled (by default) everywhere in >> IPv4 purely for security (traffic interception.) > > Okay, I'll ask again. Exactly how does disabling ICMP redirects on my > router prevent traffic from being intercepted? > As was mentioned in an other part of the thread. You disable it on the host and if no host is using it, you might as well disable it on the router as wel. Others mentioned some routers need to handle this in software instead of hardware, which is obviously slower. It might also help you notice you have a roque host when you are looking at your network-traffic and if you know your network doesn't have any ICMP-redirects normally. disabling on the host: OpenBSD: echo net.inet.icmp.rediraccept=0 >> /etc/sysctl.conf echo net.inet6.icmp6.rediraccept=0 >> /etc/sysctl.conf sysctl net.inet.icmp.rediraccept=0 sysctl net.inet6.icmp6.rediraccept=0 FreeBSD: echo net.inet.icmp.drop_redirect=0 >> /etc/sysctl.conf echo net.inet6.icmp6.rediraccept=0 >> /etc/sysctl.conf sysctl net.inet.icmp.drop_redirect=0 sysctl net.inet6.icmp6.rediraccept=0 Linux: echo net.ipv4.conf.all.accept_redirects = 0 >> /etc/sysctl.conf echo net.ipv4.conf.all.send_redirects = 0 >> /etc/sysctl.conf sysctl -p /etc/sysctl.conf From ekat at onyxlight.net Fri Aug 20 20:08:17 2010 From: ekat at onyxlight.net (Eric J. Katanich) Date: Fri, 20 Aug 2010 21:08:17 -0400 Subject: Should routers send redirects by default? In-Reply-To: References: Message-ID: <3887672486120547ACEB7B3ACA6E46EC1B40E46A@exchange> On Fri, 20 Aug 2010 19:49:43 -0400 "Ricky Beam" wrote: > On Fri, 20 Aug 2010 13:20:58 -0400, Christopher Morrow > wrote: > > Polling a little bit here, there's an active discussion going on > > 6man at ietf about whether or not v6 routers should: > > o be required to implement ip redirect functions (icmpv6 redirect) > > o be sending these by default > ... > > In ipv4 there's a relatively widely used practice of disabling ip > > redirects. > > I think it's almost universally disabled (by default) everywhere in IPv4 > purely for security (traffic interception.) In a perfectly run network, > redirects should never be necessary, so I'd think IPv6 should avoid going > down that road again. (support OPTIONAL, never enabled by default.) [It's > another insecure mistake IPv6 doesn't need to repeat.] > You're assuming the cost of always hair pinning traffic on an interface is cheaper than issuing a redirect. Sometimes it won't be. 1 ICMP redirect could result in potentially congestion inducing load being shifted off of a single router's interface. It seems that there might be a common and unstated assumption here that ever router uses hardware forwarding and has high speed 1Gbps+ interfaces that have <50% utilisation. The majority of routers - CPE - don't meet that assumption. > As I recall from long long ago, Cisco IOS would deal with traffic > differently depending on redirects... with redirects enabled, a redirect > was sent and the packet dropped; with redirects disabled, the router > hairpined the packets. I honestly don't know what today's versions do > because I've never checked -- A can ping B, I move on. I turn redirects > off on *outside* interfaces. Inside (trustable) interfaces vary -- I > don't go out of my way to disable them. > > --Ricky > From ekat at onyxlight.net Fri Aug 20 20:08:17 2010 From: ekat at onyxlight.net (Eric J. Katanich) Date: Fri, 20 Aug 2010 21:08:17 -0400 Subject: Should routers send redirects by default? In-Reply-To: Your message of "Fri, 20 Aug 2010 18:16:35 EDT." References: <1282334166.29483.291.camel@localhost.localdomain> <1282338499.29483.297.camel@localhost.localdomain> <156200.1282341272@localhost> Message-ID: <3887672486120547ACEB7B3ACA6E46EC1B40E46B@exchange> On Fri, 20 Aug 2010 18:16:35 EDT, Brandon Ross said: > How does turning off ICMP redirects on the router prevent a rouge PC from > sending ICMP redirects to it's neighbors? If I know for a fact that the network is designed such that I will never ever receive a valid ICMP redirect because there is exactly one route off the network, I can safely turn off "accept ICMP redirects" and be done with it. If I have to allow ICMP in, it becomes a much more interesting iptables/whatever issue. On Fri, 20 Aug 2010 15:34:17 PDT, Owen DeLong said: > This is worse than said PC issuing rogue RAs exactly how? It's the exact same problem, actually. > Perhaps we should pressure switch vendors to add ICMP Redirect > protection to the RA Guard feature they haven't implemented yet? You mean you aren't already? ;) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT61001..txt URL: From ekat at onyxlight.net Fri Aug 20 20:08:17 2010 From: ekat at onyxlight.net (Eric J. Katanich) Date: Fri, 20 Aug 2010 21:08:17 -0400 Subject: Should routers send redirects by default? In-Reply-To: References: Message-ID: <3887672486120547ACEB7B3ACA6E46EC1B40E46C@exchange> On Fri, 20 Aug 2010, Ricky Beam wrote: > I think it's almost universally disabled (by default) everywhere in IPv4 > purely for security (traffic interception.) Okay, I'll ask again. Exactly how does disabling ICMP redirects on my router prevent traffic from being intercepted? -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From ekat at onyxlight.net Fri Aug 20 20:08:17 2010 From: ekat at onyxlight.net (Eric J. Katanich) Date: Fri, 20 Aug 2010 21:08:17 -0400 Subject: Should routers send redirects by default? In-Reply-To: References: Message-ID: <3887672486120547ACEB7B3ACA6E46EC1B40E46D@exchange> On Fri, 20 Aug 2010 13:20:58 -0400, Christopher Morrow wrote: > Polling a little bit here, there's an active discussion going on > 6man at ietf about whether or not v6 routers should: > o be required to implement ip redirect functions (icmpv6 redirect) > o be sending these by default ... > In ipv4 there's a relatively widely used practice of disabling ip > redirects. I think it's almost universally disabled (by default) everywhere in IPv4 purely for security (traffic interception.) In a perfectly run network, redirects should never be necessary, so I'd think IPv6 should avoid going down that road again. (support OPTIONAL, never enabled by default.) [It's another insecure mistake IPv6 doesn't need to repeat.] As I recall from long long ago, Cisco IOS would deal with traffic differently depending on redirects... with redirects enabled, a redirect was sent and the packet dropped; with redirects disabled, the router hairpined the packets. I honestly don't know what today's versions do because I've never checked -- A can ping B, I move on. I turn redirects off on *outside* interfaces. Inside (trustable) interfaces vary -- I don't go out of my way to disable them. --Ricky From ekat at onyxlight.net Fri Aug 20 20:08:18 2010 From: ekat at onyxlight.net (Eric J. Katanich) Date: Fri, 20 Aug 2010 21:08:18 -0400 Subject: Should routers send redirects by default? In-Reply-To: References: Message-ID: <3887672486120547ACEB7B3ACA6E46EC1B40E46E@exchange> On 08/21/2010 02:08 AM, Brandon Ross wrote: > On Fri, 20 Aug 2010, Ricky Beam wrote: > >> I think it's almost universally disabled (by default) everywhere in >> IPv4 purely for security (traffic interception.) > > Okay, I'll ask again. Exactly how does disabling ICMP redirects on my > router prevent traffic from being intercepted? > As was mentioned in an other part of the thread. You disable it on the host and if no host is using it, you might as well disable it on the router as wel. Others mentioned some routers need to handle this in software instead of hardware, which is obviously slower. It might also help you notice you have a roque host when you are looking at your network-traffic and if you know your network doesn't have any ICMP-redirects normally. disabling on the host: OpenBSD: echo net.inet.icmp.rediraccept=0 >> /etc/sysctl.conf echo net.inet6.icmp6.rediraccept=0 >> /etc/sysctl.conf sysctl net.inet.icmp.rediraccept=0 sysctl net.inet6.icmp6.rediraccept=0 FreeBSD: echo net.inet.icmp.drop_redirect=0 >> /etc/sysctl.conf echo net.inet6.icmp6.rediraccept=0 >> /etc/sysctl.conf sysctl net.inet.icmp.drop_redirect=0 sysctl net.inet6.icmp6.rediraccept=0 Linux: echo net.ipv4.conf.all.accept_redirects = 0 >> /etc/sysctl.conf echo net.ipv4.conf.all.send_redirects = 0 >> /etc/sysctl.conf sysctl -p /etc/sysctl.conf From jfbeam at gmail.com Fri Aug 20 20:09:43 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 20 Aug 2010 21:09:43 -0400 Subject: Should routers send redirects by default? In-Reply-To: References: Message-ID: On Fri, 20 Aug 2010 20:08:34 -0400, Brandon Ross wrote: > Okay, I'll ask again. Exactly how does disabling ICMP redirects on my > router prevent traffic from being intercepted? It stops *one vector* of MITM attack. If a router honors redirects (and it never should), an evil host can intercept traffic of hosts that aren't on the local network. This is 5000% beyond the scope of the original question, btw. --Ricky From jfbeam at gmail.com Fri Aug 20 20:24:43 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 20 Aug 2010 21:24:43 -0400 Subject: Should routers send redirects by default? In-Reply-To: <20100821101339.7e5d8e62@opy.nosense.org> References: <20100821101339.7e5d8e62@opy.nosense.org> Message-ID: On Fri, 20 Aug 2010 20:43:39 -0400, Mark Smith wrote: > You're assuming the cost of always hair pinning traffic on an interface > is cheaper than issuing a redirect. I am saying no such thing. (a single redirect packet is always more efficient.) I *am* saying ICMP redirects are a mistake that should not be replicated in IPv6. They are too easy to abuse, which is why they are almost universally ignored by IPv4 hosts. In a *properly* configured network, redirects should not be necessary. (everything on the local LAN should know what's on the local LAN.) [For the record, my own networks don't follow that rule. :-) Coworkers throwing random crap on the wire doesn't help. *sigh* Don't go there.] IPv6 has more than enough mistakes glued into it. Redirects are a mess that does not need to be there. For the purests who insist on making ugly networks that are trival to subvert, make ICMPv6 redirects *OPTIONAL*, *REQUIRING* explicit configuration to enable. Without strong authentication/authorization mechanisms, it'll be the same mess that it is in IPv4. --Ricky From bross at pobox.com Fri Aug 20 20:34:15 2010 From: bross at pobox.com (Brandon Ross) Date: Fri, 20 Aug 2010 21:34:15 -0400 (EDT) Subject: Should routers send redirects by default? In-Reply-To: References: Message-ID: On Fri, 20 Aug 2010, Ricky Beam wrote: > On Fri, 20 Aug 2010 20:08:34 -0400, Brandon Ross wrote: >> Okay, I'll ask again. Exactly how does disabling ICMP redirects on my >> router prevent traffic from being intercepted? > > It stops *one vector* of MITM attack. If a router honors redirects (and it > never should), an evil host can intercept traffic of hosts that aren't on the > local network. Are you saying that turning off the transmittal of ICMP redirects on most routers will simultaniously disable the honoring of ICMP redirects that that router receives? If that's not what you are saying then you are wrong. > This is 5000% beyond the scope of the original question, btw. I disagree. The decision about whether or not a feature should be on by default or not should be clear evidence that said feature is/could be harmful. So far I have not heard a single compelling argument for how the _transmittal_ of ICMP redirects can cause any signficicant harm to a network other than what the other typical protocols that are enabled by defualt (ping, can't fragement, etc) cause. I will make the statement: The transmittal of ICMP redirects by a router _cannot_ be exploited to create a man in the middle attack. Before anyone responds to that statement, please read it very carefully. This statement does not comment on whether a host or router should be configured to _receive_ an ICMP redirect and act on it, that clearly can be used to create a MITM attack. How many of you that routinely disable ICMP redirect on your routers also routinely disable the reception of ICMP redirects on your hosts? For those of you that do not, why not? -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Aug 20 20:52:48 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 21 Aug 2010 11:22:48 +0930 Subject: Should routers send redirects by default? In-Reply-To: References: <20100821101339.7e5d8e62@opy.nosense.org> Message-ID: <20100821112248.1b2e0d86@opy.nosense.org> On Fri, 20 Aug 2010 21:24:43 -0400 "Ricky Beam" wrote: > On Fri, 20 Aug 2010 20:43:39 -0400, Mark Smith > wrote: > > You're assuming the cost of always hair pinning traffic on an interface > > is cheaper than issuing a redirect. > > I am saying no such thing. (a single redirect packet is always more > efficient.) I *am* saying ICMP redirects are a mistake that should not be > replicated in IPv6. They are too easy to abuse, which is why they are > almost universally ignored by IPv4 hosts. > I thought we were talking about IPv6 redirects not IPv4 ones. How much do you know about their operation and purposes? > In a *properly* configured network, redirects should not be necessary. > (everything on the local LAN should know what's on the local LAN.) [For > the record, my own networks don't follow that rule. :-) Coworkers throwing > random crap on the wire doesn't help. *sigh* Don't go there.] > > IPv6 has more than enough mistakes glued into it. Redirects are a mess > that does not need to be there. For the purests who insist on making ugly > networks that are trival to subvert, make ICMPv6 redirects *OPTIONAL*, > *REQUIRING* explicit configuration to enable. Without strong > authentication/authorization mechanisms, it'll be the same mess that it is > in IPv4. > Know anything about IPv6 SeND? > --Ricky From yann.gauteron at gmail.com Sat Aug 21 01:11:05 2010 From: yann.gauteron at gmail.com (Yann GAUTERON) Date: Sat, 21 Aug 2010 08:11:05 +0200 Subject: Should routers send redirects by default? In-Reply-To: References: <1282334166.29483.291.camel@localhost.localdomain> Message-ID: 2010/8/20 Jared Mauch > > Personally (and as the instigator in the ipv6/6man discussion) if the > vendors could be trusted to expose their default settings in their > configs, i would find a default of ON to be more acceptable. As their > track-record is poor, and the harm has been realized in the network we > operate (at least), I am advocating that as a matter of policy enabling > redirects not be a default-on policy. If people want to hang themselves > that's their problem, but at least they won't come with a hidden noose > around their neck. > On Cisco routers (at least some of them), have you tried the command show running-config all This command displays all configuration, including hidden default values. This may help when this command is present. Don't know about other vendors. Yann From bmanning at vacation.karoshi.com Sat Aug 21 02:18:57 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 21 Aug 2010 07:18:57 +0000 Subject: IPv6 PMTUD and OS-X In-Reply-To: <4C6EF4DF.90709@unfix.org> References: <29058450.586.1282339621475.JavaMail.franck@franck-martins-macbook-pro.local> <4C6EF4DF.90709@unfix.org> Message-ID: <20100821071857.GC1654@vacation.karoshi.com.> On Fri, Aug 20, 2010 at 11:34:23PM +0200, Jeroen Massar wrote: > On 2010-08-20 23:27, Franck Martin wrote: > > I'm trying to debug a pesky PMTUD issue with IPv6 on Mac OS-X 10.6. > > > > It happens only from home, on wireless, when connected to a mac aiport > > that does an automatic tunnel (teredo) to IPv6 backbone. > > Welcome to the great world of Teredo/6to4 where the endpoints/relays of > the tunnel are anycasted in both IPv4 and IPv6 and thus can be quite > difficult to debug, it can be done but requires quite a lot of vision in > the network on both IPv4 and which will be generally near impossible. > > > There are IPv6 web site that I cannot browse until I lower the MTU to > 1400. > > Why don't you just do 1280 which is the default? > > Do also note that you have two levels of PMTU, the IPv6 one and the IPv4 > one. If you configure your MTU of the tunnel incorrectly compared to the > relay that you are using you will not see the PMTU's coming through > either or they might not accept your large packets. > > Both MTUs can be broken due to folks filtering ICMP which is generally a > bad thing to do. > > Greets, > Jeroen or - if you are tunneled more than once, you might be ultra conservative and drop your MTU to 1220 - that should weed out the edge cases where even 1280 is too large. --bill From jeroen at unfix.org Sat Aug 21 04:42:04 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 21 Aug 2010 11:42:04 +0200 Subject: IPv6 PMTUD and OS-X In-Reply-To: <20100821071857.GC1654@vacation.karoshi.com.> References: <29058450.586.1282339621475.JavaMail.franck@franck-martins-macbook-pro.local> <4C6EF4DF.90709@unfix.org> <20100821071857.GC1654@vacation.karoshi.com.> Message-ID: <4C6F9F6C.80609@unfix.org> On 2010-08-21 09:18, bmanning at vacation.karoshi.com wrote: > On Fri, Aug 20, 2010 at 11:34:23PM +0200, Jeroen Massar wrote: >> On 2010-08-20 23:27, Franck Martin wrote: >>> I'm trying to debug a pesky PMTUD issue with IPv6 on Mac OS-X 10.6. >>> >>> It happens only from home, on wireless, when connected to a mac aiport >>> that does an automatic tunnel (teredo) to IPv6 backbone. >> >> Welcome to the great world of Teredo/6to4 where the endpoints/relays of >> the tunnel are anycasted in both IPv4 and IPv6 and thus can be quite >> difficult to debug, it can be done but requires quite a lot of vision in >> the network on both IPv4 and which will be generally near impossible. >> >>> There are IPv6 web site that I cannot browse until I lower the MTU to >> 1400. >> >> Why don't you just do 1280 which is the default? >> >> Do also note that you have two levels of PMTU, the IPv6 one and the IPv4 >> one. If you configure your MTU of the tunnel incorrectly compared to the >> relay that you are using you will not see the PMTU's coming through >> either or they might not accept your large packets. >> >> Both MTUs can be broken due to folks filtering ICMP which is generally a >> bad thing to do. >> >> Greets, >> Jeroen > > > or - if you are tunneled more than once, you might be ultra conservative > and drop your MTU to 1220 - that should weed out the edge cases where even 1280 > is too large. 1220? I am pretty sure the minimal IPv6 MTU is 1280 and that below it fragmentation should be handled by the medium that transports packets smaller than that.... Can you enlighten me Bill? :) Greets, Jeroen From jbates at brightok.net Sat Aug 21 09:12:47 2010 From: jbates at brightok.net (Jack Bates) Date: Sat, 21 Aug 2010 09:12:47 -0500 Subject: Should routers send redirects by default? In-Reply-To: <3887672486120547ACEB7B3ACA6E46EC1B40E46E@exchange> References: <3887672486120547ACEB7B3ACA6E46EC1B40E46E@exchange> Message-ID: <4C6FDEDF.2060400@brightok.net> Eric J. Katanich wrote: > > You disable it on the host and if no host is using it, you might as well > disable it on the router as wel. Others mentioned > some routers need to handle this in software instead of hardware, which > is obviously slower. Most redirects are limited in their rate, so it generally is unnoticed on the router, but yes, to be fully optimized, turning it off isn't a bad idea. Here's a better one. Put the router's choice in the RA on a per prefix basis (and of course DHCPv6 for non-RA setups). Any router/host communication agreements really should have a profile setup. If the router is acting in a certain way, it should be able to notify the host. If RA is disabled and a pure DHCPv6 setup was deployed, obviously the DHCPv6 server would need to provide the necessary router information (mtu, icmp unreachable support, etc). It bugs me that we setup automation support such as between routers and hosts and don't include all the different details that both really should agree on (such as icmp redirects, or even the ability to push routes to hosts, ie modify redirects to support prefix or host based redirects since we are starting over here). Jack From jared at puck.nether.net Sat Aug 21 09:26:59 2010 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 21 Aug 2010 10:26:59 -0400 Subject: Should routers send redirects by default? In-Reply-To: References: <1282334166.29483.291.camel@localhost.localdomain> Message-ID: On Aug 21, 2010, at 2:11 AM, Yann GAUTERON wrote: > > > 2010/8/20 Jared Mauch > > Personally (and as the instigator in the ipv6/6man discussion) if the > vendors could be trusted to expose their default settings in their > configs, i would find a default of ON to be more acceptable. As their > track-record is poor, and the harm has been realized in the network we > operate (at least), I am advocating that as a matter of policy enabling > redirects not be a default-on policy. If people want to hang themselves > that's their problem, but at least they won't come with a hidden noose > around their neck. > > On Cisco routers (at least some of them), have you tried the command > show running-config all > > This command displays all configuration, including hidden default values. > > This may help when this command is present. > > Don't know about other vendors. This varies by IOS (software revision), and because not all devices actually have the access to this "mainline" featureset due to when they branched for their localized hardware support. I certainly wish they could get there now, and it's better in the newer access (CPE) hardware. While related, the larger problem IMHO is them removing stuff like "show parser dump exec" and "show parser dump config". I have been a supporter of exposed defaults for years, including "more secure" and "more robust" defaults. The folks on the IETF list seem to think that the existing rate-limit mechanics will protect the routers. We did not arrive at these settings as a result of those rate-limits working properly sadly. - Jared From jared at puck.nether.net Sat Aug 21 09:32:00 2010 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 21 Aug 2010 10:32:00 -0400 Subject: Should routers send redirects by default? In-Reply-To: <4C6FDEDF.2060400@brightok.net> References: <3887672486120547ACEB7B3ACA6E46EC1B40E46E@exchange> <4C6FDEDF.2060400@brightok.net> Message-ID: <1328F816-25F6-4708-BB0A-8FF5C58046EE@puck.nether.net> On Aug 21, 2010, at 10:12 AM, Jack Bates wrote: > Eric J. Katanich wrote: >> You disable it on the host and if no host is using it, you might as well disable it on the router as wel. Others mentioned >> some routers need to handle this in software instead of hardware, which is obviously slower. > > Most redirects are limited in their rate, so it generally is unnoticed on the router, but yes, to be fully optimized, turning it off isn't a bad idea. Here's a better one. Put the router's choice in the RA on a per prefix basis (and of course DHCPv6 for non-RA setups). > > Any router/host communication agreements really should have a profile setup. If the router is acting in a certain way, it should be able to notify the host. If RA is disabled and a pure DHCPv6 setup was deployed, obviously the DHCPv6 server would need to provide the necessary router information (mtu, icmp unreachable support, etc). > > It bugs me that we setup automation support such as between routers and hosts and don't include all the different details that both really should agree on (such as icmp redirects, or even the ability to push routes to hosts, ie modify redirects to support prefix or host based redirects since we are starting over here). One of the use cases for the redirects listed is that someone may DHCPv6 a prefix, but (!!!) not know the netmask of the prefix, so may not know what is on-net. ie: here's your host address, good luck! This surely isn't something I had expected as an output of the IETF, as i figured that even the most basic folks advocating for "internet engineering" would tell a host the netmask so it would know what is on-net vs off-net. This tells me that the use of redirects isn't quite as straightforward as "helping" but more as "crutch" for not wanting to consume an extra byte for mask and few bytes for a default-router. It also means they are unlikely to be as limited in their rate as you suggest, it will make the IPv6 router look more like a flow-swithced device (having to send a redirect for each subnet/mask that is different) and effectively make the host participate (via redirects) in this routing protocol. - Jared From morrowc.lists at gmail.com Sat Aug 21 10:19:30 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 21 Aug 2010 11:19:30 -0400 Subject: Should routers send redirects by default? In-Reply-To: <3887672486120547ACEB7B3ACA6E46EC1B40E46E@exchange> References: <3887672486120547ACEB7B3ACA6E46EC1B40E46E@exchange> Message-ID: I appreciate the discussion.. Eric, are you reflecting messages back to the list without additional content for a reason? list-admin folks, could we ping eric and see what's busted? On Fri, Aug 20, 2010 at 9:08 PM, Eric J. Katanich wrote: > On 08/21/2010 02:08 AM, Brandon Ross wrote: >> On Fri, 20 Aug 2010, Ricky Beam wrote: >> >>> I think it's almost universally disabled (by default) everywhere in >>> IPv4 purely for security (traffic interception.) >> >> Okay, I'll ask again. ?Exactly how does disabling ICMP redirects on my >> router prevent traffic from being intercepted? >> > As was mentioned in an other part of the thread. > > You disable it on the host and if no host is using it, you might as well > disable it on the router as wel. Others mentioned > some routers need to handle this in software instead of hardware, which > is obviously slower. > > It might also help you notice you have a roque host when you are looking > at your network-traffic and if you know your > network doesn't have any ICMP-redirects normally. > > disabling on the host: > OpenBSD: > echo net.inet.icmp.rediraccept=0 >> /etc/sysctl.conf > echo net.inet6.icmp6.rediraccept=0 >> /etc/sysctl.conf > sysctl net.inet.icmp.rediraccept=0 > sysctl net.inet6.icmp6.rediraccept=0 > > FreeBSD: > echo net.inet.icmp.drop_redirect=0 >> /etc/sysctl.conf > echo net.inet6.icmp6.rediraccept=0 >> /etc/sysctl.conf > sysctl net.inet.icmp.drop_redirect=0 > sysctl net.inet6.icmp6.rediraccept=0 > > Linux: > echo net.ipv4.conf.all.accept_redirects = 0 >> /etc/sysctl.conf > echo net.ipv4.conf.all.send_redirects = 0 >> /etc/sysctl.conf > sysctl -p /etc/sysctl.conf > > > > From joelja at bogus.com Sat Aug 21 13:57:02 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 21 Aug 2010 11:57:02 -0700 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: References: <20100818200447.162288b6@opy.nosense.org> <20100819064648.6c90e970@opy.nosense.org> Message-ID: <4C70217E.90107@bogus.com> On 8/18/10 4:20 PM, Hannes Frederic Sowa wrote: > On Wed, Aug 18, 2010 at 11:16 PM, Mark Smith wrote: >>> In IPv4-land I have the possibility to >>> reconnect and get a new unrelated ip-address every time. >>> >> >> They're issued by the same ISP, to they're related. > > Ups. Unrelated in the sense of random ip from their pool, of course. except of course that in practice if your lease hasn't expired and the ip reassigned, or even if you manually release it you're very likely to receive the same one. > hannes > From travis+ml-nanog at subspacefield.org Sat Aug 21 16:57:42 2010 From: travis+ml-nanog at subspacefield.org (travis+ml-nanog at subspacefield.org) Date: Sat, 21 Aug 2010 14:57:42 -0700 Subject: on network monitoring and security - req for monitoring tools Message-ID: <20100821215742.GF10007@subspacefield.org> Hi, I'm putting together a book on security*, and wanted some expert input onto network monitoring solutions... http://www.subspacefield.org/security/security_concepts.html Nagios, Net-SNMP, ifgraph, cacti, OpenNMS... any others? Any summaries of when one is better than the other? Any suggestions on section 13-15? I imagine I'll offend some of you by not distinguishing between system and network adminsitration, but... it's a small section right now, maybe if it grows. OT: I had issues with understanding MIBs and SNMP tools... specifically, I wanted to query and graph the pf-specific MIB... any suggested places to ask? Do I ask on the Net-SNMP list, or is there a better place? Also, cacti... seemed to behave differently based on whether the target was Linux-based or BSD-based... I suppose the cacti-users is the right place to ask, but if anyone has any suggestions, please LMK. I hate the UI. -- My emails do not have attachments; it's a digital signature that your mail program doesn't understand. | http://www.subspacefield.org/~travis/ If you are a spammer, please email john at subspacefield.org to get blacklisted. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From joelja at bogus.com Sat Aug 21 17:26:21 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 21 Aug 2010 15:26:21 -0700 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: <20100819175832.GA2079@maya.aronius.com> References: <20100818200447.162288b6@opy.nosense.org> <20100819064648.6c90e970@opy.nosense.org> <20100819123007.GA27242@maya.aronius.com> <4C6D606B.1020403@bogus.com> <20100819175832.GA2079@maya.aronius.com> Message-ID: <4C70528D.9060802@bogus.com> On 8/19/10 10:58 AM, Joakim Aronius wrote: > * Joel Jaeggli (joelja at bogus.com) wrote: >> >> manual configuration of ip address name mappings seems like a >> rather low priority for the average home user... >> >> I don't expect that will be a big activity in the future either, >> more devices means less manual intervention not more. >> > > Ok, ok, so that argument sucked. I guess I'm still stuck in the IPv4 > mindset and have not yet grasped the full blessing of IPv6, zeroconf > etc. etc. I'm not sure I'd characterize zeroconf, or rendezvous or anything other technology for device mapping and discovery to be a blessing, that said the use case for "take shiny new toy out of the box an plug it in is not that different from the use case of device needs to discard it's old mapping and use a new one. > Anyway, constantly changing prefixes for home users still seem like > begging for trouble. (Could be a service though, as mentioned, but on > the other hand I expect a fair number of anonymity services to arise > so charging for it might be tough.) a device might get plugged in and be in the same location for the entirety of it service life or it might move ever couple hours as a number of increasing portable devices tend to do, the later set of devices already cope with a lack of address stability fairly well and pulling the run out from under them every once in a while supports renumbering behavior... I can remember early network printers using bootp and the assuming that they could use that one ip address forever. today the printer will dhcp and advertise it's availability in the same broadcast domain and may well reregister it's name in dynamic dns if possible. > Cheers, /Joakim > > From francois at menards.ca Sat Aug 21 18:50:59 2010 From: francois at menards.ca (=?utf-8?Q? Fran=C3=A7ois_D._M=C3=A9nard ?=) Date: Sat, 21 Aug 2010 19:50:59 -0400 Subject: on network monitoring and security - req for monitoring tools In-Reply-To: <20100821215742.GF10007@subspacefield.org> References: <20100821215742.GF10007@subspacefield.org> Message-ID: <83B7FB27-B61C-450A-A58F-96E7C51DE874@menards.ca> Mikrotik TheDude -- fmenard at xittel.net On 2010-08-21, at 17:57, travis+ml-nanog at subspacefield.org wrote: > Hi, I'm putting together a book on security*, and wanted some expert > input onto network monitoring solutions... > > http://www.subspacefield.org/security/security_concepts.html > > Nagios, Net-SNMP, ifgraph, cacti, OpenNMS... any others? > > Any summaries of when one is better than the other? > > Any suggestions on section 13-15? I imagine I'll offend some of you > by not distinguishing between system and network adminsitration, > but... it's a small section right now, maybe if it grows. > > OT: > I had issues with understanding MIBs and SNMP tools... specifically, > I wanted to query and graph the pf-specific MIB... any suggested places > to ask? Do I ask on the Net-SNMP list, or is there a better place? > > Also, cacti... seemed to behave differently based on whether the > target was Linux-based or BSD-based... I suppose the cacti-users is > the right place to ask, but if anyone has any suggestions, please LMK. > I hate the UI. > -- > My emails do not have attachments; it's a digital signature that your mail > program doesn't understand. | http://www.subspacefield.org/~travis/ > If you are a spammer, please email john at subspacefield.org to get blacklisted. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Aug 21 19:07:20 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 22 Aug 2010 09:37:20 +0930 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: References: <4C6C53A4.7060005@brightok.net> Message-ID: <20100822093720.57d46204@opy.nosense.org> On Thu, 19 Aug 2010 01:35:50 +0200 Hannes Frederic Sowa wrote: > On Wed, Aug 18, 2010 at 11:41 PM, Jack Bates wrote: > > Web portals work fine, and honestly, it's not like you need to switch > > subnets, either. PPPoE/A implementations work great, as they are already > > designed to utilize radius backends to quickly alter static/dynamic on a > > session. For bridging setups, you have a variety of implementations and it > > becomes messier. Cisco, while maintaining RBE did away with the concept of > > proxy-nd, and didn't provide a mechanism for dynamically allocating the > > prefixes to the unnumbered interface. If you use dslam level controls, > > you'll most likely being using DHCPv6 TA addressing with PD on top of it, > > which works well. Most of which can support quick static/dynamic > > capabilities as it does with v4. > > Thanks. I will have a deeper look in the standards. This sounds like a > viable solution to me. Albeit, I wonder if there is a drive for the > big ISPs to implement such features. > Potentially it's a value add that small ISPs can use to distinguish their basic packet transport services from their larger competitors. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Aug 21 19:24:41 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 22 Aug 2010 09:54:41 +0930 Subject: Should routers send redirects by default? In-Reply-To: <1328F816-25F6-4708-BB0A-8FF5C58046EE@puck.nether.net> References: <3887672486120547ACEB7B3ACA6E46EC1B40E46E@exchange> <4C6FDEDF.2060400@brightok.net> <1328F816-25F6-4708-BB0A-8FF5C58046EE@puck.nether.net> Message-ID: <20100822095441.78cce98c@opy.nosense.org> On Sat, 21 Aug 2010 10:32:00 -0400 Jared Mauch wrote: > > On Aug 21, 2010, at 10:12 AM, Jack Bates wrote: > > > Eric J. Katanich wrote: > >> You disable it on the host and if no host is using it, you might as well disable it on the router as wel. Others mentioned > >> some routers need to handle this in software instead of hardware, which is obviously slower. > > > > Most redirects are limited in their rate, so it generally is unnoticed on the router, but yes, to be fully optimized, turning it off isn't a bad idea. Here's a better one. Put the router's choice in the RA on a per prefix basis (and of course DHCPv6 for non-RA setups). > > > > Any router/host communication agreements really should have a profile setup. If the router is acting in a certain way, it should be able to notify the host. If RA is disabled and a pure DHCPv6 setup was deployed, obviously the DHCPv6 server would need to provide the necessary router information (mtu, icmp unreachable support, etc). > > > > It bugs me that we setup automation support such as between routers and hosts and don't include all the different details that both really should agree on (such as icmp redirects, or even the ability to push routes to hosts, ie modify redirects to support prefix or host based redirects since we are starting over here). > > One of the use cases for the redirects listed is that someone may DHCPv6 a prefix, but (!!!) not know the netmask of the prefix, so may not know what is on-net. ie: here's your host address, good luck! > That's not the case. What they're saying is that an address by itself does not _imply_ a prefix length i.e. don't assume a /64. This isn't any different to IPv4 in the last 15 years - "192.168.0.1" by itself doesn't imply a /24 since CIDR came along. RFC5942 does into details. Basically it says if a node doesn't have a separate indication that a prefix is onlink (i.e. via a configured prefix length, or via PIO options in an RA), then don't assume the internal structure of the address is known (i.e. don't assume a /64). > This surely isn't something I had expected as an output of the IETF, as i figured that even the most basic folks advocating for "internet engineering" would tell a host the netmask so it would know what is on-net vs off-net. > > This tells me that the use of redirects isn't quite as straightforward as "helping" but more as "crutch" for not wanting to consume an extra byte for mask and few bytes for a default-router. > > It also means they are unlikely to be as limited in their rate as you suggest, it will make the IPv6 router look more like a flow-swithced device (having to send a redirect for each subnet/mask that is different) and effectively make the host participate (via redirects) in this routing protocol. > > - Jared From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Aug 21 19:42:01 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 22 Aug 2010 10:12:01 +0930 Subject: Should routers send redirects by default? In-Reply-To: <4C6FDEDF.2060400@brightok.net> References: <3887672486120547ACEB7B3ACA6E46EC1B40E46E@exchange> <4C6FDEDF.2060400@brightok.net> Message-ID: <20100822101201.37215017@opy.nosense.org> On Sat, 21 Aug 2010 09:12:47 -0500 Jack Bates wrote: > Eric J. Katanich wrote: > > > > You disable it on the host and if no host is using it, you might as well > > disable it on the router as wel. Others mentioned > > some routers need to handle this in software instead of hardware, which > > is obviously slower. > > Most redirects are limited in their rate, so it generally is unnoticed > on the router, but yes, to be fully optimized, turning it off isn't a > bad idea. Here's a better one. Put the router's choice in the RA on a > per prefix basis (and of course DHCPv6 for non-RA setups). > I'm don't think that would work. In IPv6, redirects serve two purposes, where as in IPv4 they only served one - o allow an IPv6 router to indicate to an end-node that another onlink IPv6 router is a better path towards the destination (i.e. the IPv4 purpose). This situation doesn't seem to occur very often - when there are two routers on a link they're usually there for availability, rather than presenting a significantly different set of paths to potential offlink destinations. Usually they'll be hidden behind a single virtual router via HSRP or VRRP. o allow an IPv6 router to indicate to an end-node that the destination it is attempting to send to is onlink. This situation occurs when the router is more informed than the origin end-node about what prefixes are onlink. This shouldn't happen very often either, as multiple onlink IPv6 routers should be announcing the same Prefix Information Options in their RAs, and therefore end-nodes should be fully informed as to all the onlink prefixes. ICMPv6 redirects in this scenario would only occur during the introduction of that new prefix information i.e. the time gap between when the first and second onlink routers are configured with new prefix information. So a redirect status parameter isn't prefix specific. > Any router/host communication agreements really should have a profile > setup. If the router is acting in a certain way, it should be able to > notify the host. If RA is disabled and a pure DHCPv6 setup was deployed, > obviously the DHCPv6 server would need to provide the necessary router > information (mtu, icmp unreachable support, etc). > > It bugs me that we setup automation support such as between routers and > hosts and don't include all the different details that both really > should agree on (such as icmp redirects, or even the ability to push > routes to hosts, ie modify redirects to support prefix or host based > redirects since we are starting over here). > > > Jack > From ml at kenweb.org Sat Aug 21 20:00:37 2010 From: ml at kenweb.org (ML) Date: Sat, 21 Aug 2010 21:00:37 -0400 Subject: DNSSEC and SSL Message-ID: <4C7076B5.9050103@kenweb.org> Would a future with a ubiquitous DNSSEC deployment eliminate the market for commercial CAs? Would functioning DNSSEC + self signed certs be more secure/trustworthy than our current system of trusted CAs chosen by OS/browser developers? From gary.buhrmaster at gmail.com Sat Aug 21 20:46:39 2010 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Sat, 21 Aug 2010 18:46:39 -0700 Subject: DNSSEC and SSL In-Reply-To: <4C7076B5.9050103@kenweb.org> References: <4C7076B5.9050103@kenweb.org> Message-ID: On Sat, Aug 21, 2010 at 18:00, ML wrote: > Would a future with a ubiquitous DNSSEC deployment eliminate the market > for commercial CAs? > > Would functioning DNSSEC + self signed certs be more secure/trustworthy > than our current system of trusted CAs chosen by OS/browser developers? See Dan Kaminski's presentation at this years BlackHat & Defcon for a proposal, and the prototype "glue" that provides a proof of concept. http://www.recursion.com/talks.html (I seem to recall the X.509/CA part starts about 3/4 of the way through the deck). That said, Dan does not suggest that everything a CA does is obsolete, there will still be a market for making sure that BankOfAmerica.com really is the bank you want to do business with (branding). From swmike at swm.pp.se Sun Aug 22 01:38:03 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 22 Aug 2010 08:38:03 +0200 (CEST) Subject: DNSSEC and SSL In-Reply-To: <4C7076B5.9050103@kenweb.org> References: <4C7076B5.9050103@kenweb.org> Message-ID: On Sat, 21 Aug 2010, ML wrote: > Would a future with a ubiquitous DNSSEC deployment eliminate the market > for commercial CAs? No, but it might eliminate the cheapest certs that people might use. I'd like my personal server to have a self-signed cert with it's fingerprint handled via DNSSEC, because I don't want to pay a CA. > Would functioning DNSSEC + self signed certs be more secure/trustworthy > than our current system of trusted CAs chosen by OS/browser developers? No, because DNSSEC isn't secured all the way from the DNS server to the application, only to the resolver. Both systems have problems, I'd imagine the best security is when they work together. -- Mikael Abrahamsson email: swmike at swm.pp.se From owen at delong.com Sun Aug 22 01:52:42 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 21 Aug 2010 23:52:42 -0700 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: <4C70528D.9060802@bogus.com> References: <20100818200447.162288b6@opy.nosense.org> <20100819064648.6c90e970@opy.nosense.org> <20100819123007.GA27242@maya.aronius.com> <4C6D606B.1020403@bogus.com> <20100819175832.GA2079@maya.aronius.com> <4C70528D.9060802@bogus.com> Message-ID: <7E55F0C3-A9CF-4F10-B744-ADBD8FD999DC@delong.com> > > I can remember early network printers using bootp and the assuming that > they could use that one ip address forever. today the printer will dhcp > and advertise it's availability in the same broadcast domain and may > well reregister it's name in dynamic dns if possible. Funny... I remember printers only thinking that if they were going to get moved, they'd also likely get unplugged and get a new address after the move. Owen From joelja at bogus.com Sun Aug 22 02:13:59 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 22 Aug 2010 00:13:59 -0700 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: <7E55F0C3-A9CF-4F10-B744-ADBD8FD999DC@delong.com> References: <20100818200447.162288b6@opy.nosense.org> <20100819064648.6c90e970@opy.nosense.org> <20100819123007.GA27242@maya.aronius.com> <4C6D606B.1020403@bogus.com> <20100819175832.GA2079@maya.aronius.com> <4C70528D.9060802@bogus.com> <7E55F0C3-A9CF-4F10-B744-ADBD8FD999DC@delong.com> Message-ID: <4C70CE37.60700@bogus.com> On 8/21/10 11:52 PM, Owen DeLong wrote: >> >> I can remember early network printers using bootp and the assuming that >> they could use that one ip address forever. today the printer will dhcp >> and advertise it's availability in the same broadcast domain and may >> well reregister it's name in dynamic dns if possible. > > Funny... I remember printers only thinking that if they were going to get > moved, they'd also likely get unplugged and get a new address after > the move. rfc 951 made no provision in the protocol for the recovery of an address. you may well get a new one but the old one is assigned forever until someone prunes the cruft > Owen > From jakob at kirei.se Sun Aug 22 04:46:41 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Sun, 22 Aug 2010 11:46:41 +0200 Subject: DNSSEC and SSL In-Reply-To: <4C7076B5.9050103@kenweb.org> References: <4C7076B5.9050103@kenweb.org> Message-ID: <952651BE-04F4-4D16-A46C-937C371C6840@kirei.se> On 22 aug 2010, at 03.00, ML wrote: > Would a future with a ubiquitous DNSSEC deployment eliminate the market > for commercial CAs? > > Would functioning DNSSEC + self signed certs be more secure/trustworthy > than our current system of trusted CAs chosen by OS/browser developers? For DV (domain validation) certificates one can definitely make that claim, but for EV (extended validation) I would see certificate validation in DNSSEC as a complement to EV. DNSSEC and EV together looks like a promising combination. Disclaimer: I am co-author of http://tools.ietf.org/html/draft-hoffman-keys-linkage-from-dns-00 (work in progress, see http://www.ietf.org/mailman/listinfo/keyassure for more information). jakob From ml at kenweb.org Sun Aug 22 08:11:43 2010 From: ml at kenweb.org (ML) Date: Sun, 22 Aug 2010 09:11:43 -0400 Subject: DNSSEC and SSL In-Reply-To: References: <4C7076B5.9050103@kenweb.org> Message-ID: <4C71220F.6040806@kenweb.org> On 8/22/2010 2:38 AM, Mikael Abrahamsson wrote: > No, because DNSSEC isn't secured all the way from the DNS server to the > application, only to the resolver. Both systems have problems, I'd > imagine the best security is when they work together. > Is a DNSSEC capable stub resolver not in the cards? From scubacuda at gmail.com Sun Aug 22 08:52:13 2010 From: scubacuda at gmail.com (Rogelio) Date: Sun, 22 Aug 2010 06:52:13 -0700 Subject: Other NOGs around the world? Message-ID: What other "network operator groups" are there around the world (besides NANOG)? (I'd like to follow them to see what types of issues they see in their countries) From scubacuda at gmail.com Sun Aug 22 08:55:14 2010 From: scubacuda at gmail.com (Rogelio) Date: Sun, 22 Aug 2010 06:55:14 -0700 Subject: iPad apps tested at cable companies Message-ID: A lot of cable operators I'm working seem to be doing a lot with the iPad (particularly apps that control TV programming). Is anyone else seeing a lot of this? (Wish I could find a URL of what I was looking at, but can't find anything) From tme at americafree.tv Sun Aug 22 09:17:17 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Sun, 22 Aug 2010 10:17:17 -0400 Subject: Other NOGs around the world? In-Reply-To: References: Message-ID: <0D80E28E-8779-4EA7-9000-949957FFFA9B@americafree.tv> On Aug 22, 2010, at 9:52 AM, Rogelio wrote: > What other "network operator groups" are there around the world (besides NANOG)? > This is what comes to mind. I am sure that others out there have more. There is MENOG (Middle East) - http://www.menog.net/ - with some list traffic SANOG (Southeast Asia) - http://www.sanog.org/ PACNOG (Pacific) - http://www.pacnog.org/ LACNOG - Latin America and Caribbean - https://mail.lacnic.net/mailman/listinfo/lacnog AFNOG - Africa - http://www.afnog.org/ For country specific groups, there is DENOG - Germany - http://www.denog.de/ A search reveals a bunch of other country specific ones (France, Switzerland, New Zealand, etc.) - I have no idea how active they are. And, RIPE of course has mailing lists for Europe (but they are not like NANOG) - http://www.ripe.net/ripe/maillists/index.html Regards Marshall > (I'd like to follow them to see what types of issues they see in their > countries) > > From fm-lists at st-kilda.org Sun Aug 22 09:27:19 2010 From: fm-lists at st-kilda.org (Fearghas McKay) Date: Sun, 22 Aug 2010 15:27:19 +0100 Subject: Other NOGs around the world? In-Reply-To: <0D80E28E-8779-4EA7-9000-949957FFFA9B@americafree.tv> References: <0D80E28E-8779-4EA7-9000-949957FFFA9B@americafree.tv> Message-ID: <50DC8BD4-95B8-4B05-BCB0-671EA72F55C3@st-kilda.org> On 22 Aug 2010, at 15:17, Marshall Eubanks wrote: > For country specific groups, there is > DENOG - Germany - http://www.denog.de/ UKNOF UK http://www.uknof.org.uk/ Next meeting in Edinburgh Scotland on September 7th. f From tme at americafree.tv Sun Aug 22 09:41:30 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Sun, 22 Aug 2010 10:41:30 -0400 Subject: iPad apps tested at cable companies In-Reply-To: References: Message-ID: <4AE41216-CE49-435E-BCA4-600893B95A05@americafree.tv> On Aug 22, 2010, at 9:55 AM, Rogelio wrote: > A lot of cable operators I'm working seem to be doing a lot with the > iPad (particularly apps that control TV programming). > > Is anyone else seeing a lot of this? I know several companies that have ported / are porting remote control functions to the iPad. (The sort of thing that might be done currently using a Crestron control panel.) It seems to be a good fit for an intelligent remote control, and the same code can be used on the iPhone too. You should considering becoming an Apple Developer and enrolling in the iPhone Developer Program if you want to do this. > > (Wish I could find a URL of what I was looking at, but can't find anything) > > Regards Marshall From kauer at biplane.com.au Sun Aug 22 09:42:03 2010 From: kauer at biplane.com.au (Karl Auer) Date: Mon, 23 Aug 2010 00:42:03 +1000 Subject: Other NOGs around the world? In-Reply-To: <0D80E28E-8779-4EA7-9000-949957FFFA9B@americafree.tv> References: <0D80E28E-8779-4EA7-9000-949957FFFA9B@americafree.tv> Message-ID: <1282488123.30443.3251.camel@karl> On Sun, 2010-08-22 at 10:17 -0400, Marshall Eubanks wrote: > On Aug 22, 2010, at 9:52 AM, Rogelio wrote: > > What other "network operator groups" are there around the world (besides NANOG)? AusNOG. At a bit of a low S:N right now. We have been leading up to a Federal election, with two big tech issues involved - a new national broadband network and Internet censorship. These two topics have rather dominated discussions of late. http://lists.ausnog.net/mailman/listinfo/ausnog Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ops.lists at gmail.com Sun Aug 22 09:54:29 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 22 Aug 2010 20:24:29 +0530 Subject: Other NOGs around the world? In-Reply-To: <0D80E28E-8779-4EA7-9000-949957FFFA9B@americafree.tv> References: <0D80E28E-8779-4EA7-9000-949957FFFA9B@americafree.tv> Message-ID: and of course apricot (www.apricot.net) On Sun, Aug 22, 2010 at 7:47 PM, Marshall Eubanks wrote: > > SANOG (Southeast Asia) - http://www.sanog.org/ > > PACNOG (Pacific) - http://www.pacnog.org/ -- Suresh Ramasubramanian (ops.lists at gmail.com) From nanog at maunier.org Sun Aug 22 10:29:42 2010 From: nanog at maunier.org (Pierre-Yves Maunier) Date: Sun, 22 Aug 2010 17:29:42 +0200 Subject: Other NOGs around the world? In-Reply-To: References: Message-ID: 2010/8/22 Rogelio > What other "network operator groups" are there around the world (besides > NANOG)? > > (I'd like to follow them to see what types of issues they see in their > countries) > > FRNOG : France http://www.frnog.org : mail archive : http://www.mail-archive.com/frnog at frnog.org/ It's active but exclusively in French. -- Pierre-Yves Maunier From yann.gauteron at gmail.com Sun Aug 22 10:49:47 2010 From: yann.gauteron at gmail.com (Yann GAUTERON) Date: Sun, 22 Aug 2010 17:49:47 +0200 Subject: Other NOGs around the world? In-Reply-To: <0D80E28E-8779-4EA7-9000-949957FFFA9B@americafree.tv> References: <0D80E28E-8779-4EA7-9000-949957FFFA9B@americafree.tv> Message-ID: In Switzerland, you have SwiNOG acting in English: http://www.swinog.ch/ From lists at nexus6.co.za Sun Aug 22 11:26:20 2010 From: lists at nexus6.co.za (Andy Ashley) Date: Sun, 22 Aug 2010 17:26:20 +0100 Subject: Other NOGs around the world? In-Reply-To: <0D80E28E-8779-4EA7-9000-949957FFFA9B@americafree.tv> References: <0D80E28E-8779-4EA7-9000-949957FFFA9B@americafree.tv> Message-ID: <4C714FAC.2010003@nexus6.co.za> On Aug 22, 2010, at 9:52 >> What other "network operator groups" are there around the world (besides NANOG)? >> IOZ (South Africa) - http://lists.internet.org.za/mailman/listinfo Regards, Andy. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From karim.adel at gmail.com Sun Aug 22 11:29:52 2010 From: karim.adel at gmail.com (Kasper Adel) Date: Sun, 22 Aug 2010 18:29:52 +0200 Subject: Calculating Cost Message-ID: Hello everyone, How would you calculate the cost of a network outage, specifically if its related to a software bug or a misconfiguration. Suppose that this could have been avoided by testing in a lab before deployment, how can i calculate that too? Unicast replies are welcomed. Cheerio, Kim From woody at pch.net Sun Aug 22 11:31:35 2010 From: woody at pch.net (Bill Woodcock) Date: Sun, 22 Aug 2010 09:31:35 -0700 Subject: Other NOGs around the world? In-Reply-To: References: <0D80E28E-8779-4EA7-9000-949957FFFA9B@americafree.tv> Message-ID: <7FC74E5B-6FD8-419C-AAA6-1D186B973F64@pch.net> You should be able to find of these at http://www.internetmeetings.org . A few not mentioned so far: CaribNOG - http://www.caribnog.org/ NZNOG - http://www.nznog.org/ LacNOG - http://www.lacnog.org/ There were a couple attempts at Nordic, Scandinavian and Northern European NOGs, which are now defunct, to the best of my knowledge... NordNOG - http://www.nordnog.org/ -Bill From lists at quux.de Sun Aug 22 11:35:52 2010 From: lists at quux.de (Jens Link) Date: Sun, 22 Aug 2010 18:35:52 +0200 Subject: Other NOGs around the world? In-Reply-To: (Rogelio's message of "Sun, 22 Aug 2010 06:52:13 -0700") References: Message-ID: <87vd72vc47.fsf@oban.berlin.quux.de> Rogelio writes: > What other "network operator groups" are there around the world (besides NANOG)? PLNOG, http://www.plnog.pl Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From Valdis.Kletnieks at vt.edu Sun Aug 22 11:43:48 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 22 Aug 2010 12:43:48 -0400 Subject: Calculating Cost In-Reply-To: Your message of "Sun, 22 Aug 2010 18:29:52 +0200." References: Message-ID: <44142.1282495428@localhost> On Sun, 22 Aug 2010 18:29:52 +0200, Kasper Adel said: > How would you calculate the cost of a network outage, specifically if its > related to a software bug or a misconfiguration. Just your actual costs, or your costs plus refunds due on SLAs, or your costs plus refunds after SLAs once you finish sleazing out of paying off (you providers who make opening a ticket hard enough so most outages are fixed before the ticket is opened know who you are), or your customer's costs, or some other number? Calculating the cost once you have a definition is usually pretty simple actually. It's nailing the jello definition to the tree that's the hard part. > Suppose that this could have been avoided by testing in a lab before > deployment, how can i calculate that too? Same as above, plus merciless mocking from anybody who finds out you could have found out about it in your lab. Calculating the cost of running a lab large-scale enough to detect the issue is a different and equally hard question. Do you need to just catch the obvious stuff, or do you need to also catch the backplane lockup that happens when you have features A and C, but not B or Z, enabled, a prime number of interfaces, 3 of which are down, and between 57 and 61 percent capacity on at least 7 links? (You think I'm kidding, ask the list if that sort of stuff actually happens. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From michiel at klaver.it Sun Aug 22 14:13:06 2010 From: michiel at klaver.it (Michiel Klaver) Date: Sun, 22 Aug 2010 21:13:06 +0200 Subject: Other NOGs around the world? In-Reply-To: References: Message-ID: <4C7176C2.2030703@klaver.it> > What other "network operator groups" are there around the world (besides NANOG)? > > (I'd like to follow them to see what types of issues they see in their > countries) > > NLNOG www.nlnog.net - The Netherlands http://www.linkedin.com/groups?gid=2600071 From mpalmer at hezmatt.org Sun Aug 22 14:51:53 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Mon, 23 Aug 2010 05:51:53 +1000 Subject: Other NOGs around the world? In-Reply-To: <1282488123.30443.3251.camel@karl> References: <0D80E28E-8779-4EA7-9000-949957FFFA9B@americafree.tv> <1282488123.30443.3251.camel@karl> Message-ID: <20100822195153.GD776@hezmatt.org> On Mon, Aug 23, 2010 at 12:42:03AM +1000, Karl Auer wrote: > On Sun, 2010-08-22 at 10:17 -0400, Marshall Eubanks wrote: > > On Aug 22, 2010, at 9:52 AM, Rogelio wrote: > > > What other "network operator groups" are there around the world (besides NANOG)? > > AusNOG. At a bit of a low S:N right now. > > We have been leading up to a Federal election, with two big tech issues > involved - a new national broadband network and Internet censorship. > These two topics have rather dominated discussions of late. Politics on an operational list? NEVAH! - Matt From mansaxel at besserwisser.org Sun Aug 22 14:57:27 2010 From: mansaxel at besserwisser.org (Mans Nilsson) Date: Sun, 22 Aug 2010 21:57:27 +0200 Subject: DNSSEC and SSL In-Reply-To: <4C71220F.6040806@kenweb.org> References: <4C7076B5.9050103@kenweb.org> <4C71220F.6040806@kenweb.org> Message-ID: <20100822195727.GA26860@besserwisser.org> Subject: Re: DNSSEC and SSL Date: Sun, Aug 22, 2010 at 09:11:43AM -0400 Quoting ML (ml at kenweb.org): > On 8/22/2010 2:38 AM, Mikael Abrahamsson wrote: > > No, because DNSSEC isn't secured all the way from the DNS server to the > > application, only to the resolver. Both systems have problems, I'd > > imagine the best security is when they work together. > > > > Is a DNSSEC capable stub resolver not in the cards? The best option today is to run a full-service resolver on the host; which is a tad heavy for most desktops, not to speak about the cache misses that would cause root server system load. The latter of course can be avoided by setting forwarders. OTOH: A thicker stub resolver does indeed exist; lwresd in the BIND suite. Calling it from applications does however mean using new API calls; since the traditional resolver API is oblivious to DNSSEC. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 What PROGRAM are they watching? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From james at freedomnet.co.nz Sun Aug 22 15:01:19 2010 From: james at freedomnet.co.nz (James Jones) Date: Sun, 22 Aug 2010 16:01:19 -0400 Subject: Other NOGs around the world? In-Reply-To: <20100822195153.GD776@hezmatt.org> References: <0D80E28E-8779-4EA7-9000-949957FFFA9B@americafree.tv> <1282488123.30443.3251.camel@karl> <20100822195153.GD776@hezmatt.org> Message-ID: I am a member of NZNOG (New Zealand) as well. Moved back to the states last year. Sent from my iPhone On Aug 22, 2010, at 3:51 PM, Matthew Palmer wrote: > On Mon, Aug 23, 2010 at 12:42:03AM +1000, Karl Auer wrote: >> On Sun, 2010-08-22 at 10:17 -0400, Marshall Eubanks wrote: >>> On Aug 22, 2010, at 9:52 AM, Rogelio wrote: >>>> What other "network operator groups" are there around the world (besides NANOG)? >> >> AusNOG. At a bit of a low S:N right now. >> >> We have been leading up to a Federal election, with two big tech issues >> involved - a new national broadband network and Internet censorship. >> These two topics have rather dominated discussions of late. > > Politics on an operational list? NEVAH! > > - Matt > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Aug 22 16:12:04 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 23 Aug 2010 06:42:04 +0930 Subject: Other NOGs around the world? In-Reply-To: <20100822195153.GD776@hezmatt.org> References: <0D80E28E-8779-4EA7-9000-949957FFFA9B@americafree.tv> <1282488123.30443.3251.camel@karl> <20100822195153.GD776@hezmatt.org> Message-ID: <20100823064204.734fa345@opy.nosense.org> On Mon, 23 Aug 2010 05:51:53 +1000 Matthew Palmer wrote: > On Mon, Aug 23, 2010 at 12:42:03AM +1000, Karl Auer wrote: > > On Sun, 2010-08-22 at 10:17 -0400, Marshall Eubanks wrote: > > > On Aug 22, 2010, at 9:52 AM, Rogelio wrote: > > > > What other "network operator groups" are there around the world (besides NANOG)? > > > > AusNOG. At a bit of a low S:N right now. > > > > We have been leading up to a Federal election, with two big tech issues > > involved - a new national broadband network and Internet censorship. > > These two topics have rather dominated discussions of late. > > Politics on an operational list? NEVAH! > Fighting off censorship means not having to find rack space and cooling for large amounts of gear, and trying to engineer to have gobs of bandwidth go through latency inducing single points of failure :-) Regards, Mark. From Valdis.Kletnieks at vt.edu Sun Aug 22 16:33:10 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 22 Aug 2010 17:33:10 -0400 Subject: Other NOGs around the world? In-Reply-To: Your message of "Mon, 23 Aug 2010 05:51:53 +1000." <20100822195153.GD776@hezmatt.org> References: <0D80E28E-8779-4EA7-9000-949957FFFA9B@americafree.tv> <1282488123.30443.3251.camel@karl> <20100822195153.GD776@hezmatt.org> Message-ID: <50307.1282512790@localhost> On Mon, 23 Aug 2010 05:51:53 +1000, Matthew Palmer said: > > We have been leading up to a Federal election, with two big tech issues > > involved - a new national broadband network and Internet censorship. > > These two topics have rather dominated discussions of late. > > Politics on an operational list? NEVAH! Politics on an operational list is *totally* appropriate when said politics has the likelyhood of impacting your operations. Remember who's going to have to install and maintain the hardware doing the censorship. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bmanning at vacation.karoshi.com Sun Aug 22 16:34:02 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 22 Aug 2010 21:34:02 +0000 Subject: DNSSEC and SSL In-Reply-To: <4C71220F.6040806@kenweb.org> References: <4C7076B5.9050103@kenweb.org> <4C71220F.6040806@kenweb.org> Message-ID: <20100822213402.GA15113@vacation.karoshi.com.> On Sun, Aug 22, 2010 at 09:11:43AM -0400, ML wrote: > On 8/22/2010 2:38 AM, Mikael Abrahamsson wrote: > > No, because DNSSEC isn't secured all the way from the DNS server to the > > application, only to the resolver. Both systems have problems, I'd > > imagine the best security is when they work together. > > > > Is a DNSSEC capable stub resolver not in the cards? > yes it is. unbound was originally designed for that very niche. --bill From bmanning at vacation.karoshi.com Sun Aug 22 16:38:28 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 22 Aug 2010 21:38:28 +0000 Subject: DNSSEC and SSL In-Reply-To: <20100822195727.GA26860@besserwisser.org> References: <4C7076B5.9050103@kenweb.org> <4C71220F.6040806@kenweb.org> <20100822195727.GA26860@besserwisser.org> Message-ID: <20100822213828.GB15113@vacation.karoshi.com.> On Sun, Aug 22, 2010 at 09:57:27PM +0200, Mans Nilsson wrote: > Subject: Re: DNSSEC and SSL Date: Sun, Aug 22, 2010 at 09:11:43AM -0400 Quoting ML (ml at kenweb.org): > > On 8/22/2010 2:38 AM, Mikael Abrahamsson wrote: > > > No, because DNSSEC isn't secured all the way from the DNS server to the > > > application, only to the resolver. Both systems have problems, I'd > > > imagine the best security is when they work together. > > > > > > > Is a DNSSEC capable stub resolver not in the cards? > > The best option today is to run a full-service resolver on the host; > which is a tad heavy for most desktops, not to speak about the cache > misses that would cause root server system load. The latter of course > can be avoided by setting forwarders. that assertion is unverified. i suspect that cache misses would not overload the system as it currently stands. (modulo a ramp up of DNSSEC capable stubs/full service IMRs). > OTOH: A thicker stub resolver does indeed exist; lwresd in the BIND > suite. Calling it from applications does however mean using new API > calls; since the traditional resolver API is oblivious to DNSSEC. perhaps a review of lwresd/unbound would be worth a gander. --bill > > -- > Mens Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE +46 705 989668 > What PROGRAM are they watching? From piotr.1234 at interia.pl Sun Aug 22 18:22:20 2010 From: piotr.1234 at interia.pl (piotr.1234 at interia.pl) Date: 23 Aug 2010 01:22:20 +0200 Subject: diffrence between two bgp router =?UTF-8?q?router:?= Message-ID: <20100822232220.A27183D1841@f53.poczta.interia.pl> Hi I try to compare two routers to new DC: Juniper mx240/480 with card "R" and Foundry NetIron XMR 8/16000. There is big diffrence in price. I don't know Foundry router's so it's hard to me to compare this two routers. Someone has expierence with both ? configuration Foundry: NI-XMR-16-AC NI-XMR-10Gx4 NI-XMR-1Gx20-SFP and Juniper: MX240BASE-AC-HIGH DPCE-R-4XGE-XFP DPCE-R-40GE-SFP thx for help Piotr ---------------------------------------------------------------------- Teraz w PZU, kupuj?c AC, otrzymujesz 10% zni?ki na OC http://linkint.pl/f27de From mehmet at akcin.net Sun Aug 22 19:17:54 2010 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 22 Aug 2010 17:17:54 -0700 Subject: Other NOGs around the world? In-Reply-To: References: Message-ID: On Aug 22, 2010, at 6:52 AM, Rogelio wrote: > What other "network operator groups" are there around the world (besides NANOG)? > > (I'd like to follow them to see what types of issues they see in their > countries) > Hi, We are trying to start TRnog with few friends arounds the world who speaks Turkish, the URL is http://www.trnog.org , The list isn't very active but we usually chat in an IRC network and trying to move the conversations to the list. We are planning to have a 1/2 day event on October sometime before or after MENOG 7 October 2010.. The day isn't decided yet. The official language is Turkish. Any other language is welcome with google translator link to Turkish ;) Regards Mehmet From kawamucho at mesh.ad.jp Sun Aug 22 19:36:35 2010 From: kawamucho at mesh.ad.jp (Seiichi Kawamura) Date: Mon, 23 Aug 2010 09:36:35 +0900 Subject: Other NOGs around the world? In-Reply-To: References: Message-ID: <4C71C293.2040909@mesh.ad.jp> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We have JANOG in Japan. The list and meetings are in Japanese, but we have several non-natives attend every time. http://www.janog.gr.jp/en This english version of the site is not a complete translation of the original site, but should give you a picture of what issues we are discussing. Regards, Seiichi Rogelio wrote: > What other "network operator groups" are there around the world (besides NANOG)? > > (I'd like to follow them to see what types of issues they see in their > countries) > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkxxwpIACgkQcrhTYfxyMkIDtwCaA75yTs3pXNZdLzszYrLaoed7 I2YAnR7sya6m6q5zDDe+cy/sMuyfBssv =UzPp -----END PGP SIGNATURE----- From Stephen.Lee at congressmail.com Sun Aug 22 20:52:11 2010 From: Stephen.Lee at congressmail.com (Stephen Lee) Date: Sun, 22 Aug 2010 21:52:11 -0400 Subject: Other NOGs around the world? In-Reply-To: References: Message-ID: <52E4255C695C6549B8F9B1DCC4D3301B0D0D0E0538@gdcmiaexch01.cgct.net> CaribNOG, www.caribnog.org, has been operative for approx. one year and just had its first Regional Gathering on Aug 15-20 in St. Maarten. CaribNOG 2 is scheduled for the first week in November, location to be finalized this week. Current emphases are: establishing IXPs, IPv6 transition, VoIP and video services, and developing CSIRTs. The list is cranking up slowly and we welcome your participation. Regards, Stephen -----Original Message----- From: Rogelio [mailto:scubacuda at gmail.com] Sent: Sunday, August 22, 2010 9:52 AM To: nanog at nanog.org Subject: Other NOGs around the world? What other "network operator groups" are there around the world (besides NANOG)? (I'd like to follow them to see what types of issues they see in their countries) From MBORBA at trf3.jus.br Sun Aug 22 21:40:23 2010 From: MBORBA at trf3.jus.br (MARLON BORBA) Date: Sun, 22 Aug 2010 23:40:23 -0300 Subject: Other NOGs around the world? Message-ID: <4C71B5670200004600037C99@d-gws03.jfsp.gov.br> Brazil's GTER (portuguese acronym for Network Operation and Engineering Workgroup). Exclusively in Brazilian Portuguese. http://gter.nic.br Next national meeting scheduled for November 25-27. Abra?os, Marlon Borba, CISSP, APC DataCenter Associate T?cnico Judici?rio ? Seguran?a da Informa??o IPv6 Evangelist ? Moreq-Jus Evangelist Comiss?o Local de Resposta a Incidentes - CLRI TRF 3 Regi?o (11) 3012-2030 (VoIP) -- Voc? j? elaborou seu PLANO DE CONTINUIDADE DE NEG?CIOS? -- >>> Pierre-Yves Maunier 22/08/10 20:15 >>> 2010/8/22 Rogelio > What other "network operator groups" are there around the world (besides > NANOG)? [...] From feldman at twincreeks.net Mon Aug 23 00:38:08 2010 From: feldman at twincreeks.net (Steve Feldman) Date: Sun, 22 Aug 2010 22:38:08 -0700 Subject: [NANOG-announce] Reminder: NANOG Steering Committee nominations are open Message-ID: <2E74F72E-843F-48D7-9A72-C124A32CE327@twincreeks.net> This is a quick reminder that nominations for the NANOG Steering Committee election are still open. The deadline for nominations is in about a week, on Monday, August 30. Also, nominations for Program Committee membership will be accepted beginning this Tuesday, August 24. Elections for three of the six elected positions on the NANOG Steering Committee will be held in October, 2010, for two-year terms ending in October, 2012. The current SC members whose terms are expiring are Patrick Gilmore, Joe Provo, and Robert Seastrom. Joe is finishing his second consecutive term, so per the charter, cannot be considered for reelection until October 2011. If you care about NANOG as a forum, and think you would like to take a turn at volunteering your time to help make it better, please consider either volunteering yourself or nominating someone else. For more information about the role of the Steering Committee, or to find out more about what's involved in being a Steering Committee member, please consult the NANOG charter or contact someone who is already serving and ask them directly. http://www.nanog.org/governance/charter/ http://www.nanog.org/governance/steering/steeringcommittee.php Per the charter, Steering Committee members must attend at least two of three NANOG meetings per year while in office. HOW TO NOMINATE SOMEONE You may nominate someone else, or yourself. There is no limit to the number of nominations that may be submitted by a single person. Individual nominees will be contacted directly to confirm that they are willing to accept the nomination, and so that they can supply a biography for the NANOG web page. To submit a nomination, send the nominee's full name and contact details to nominations at nanog.org. The deadline for nominations is 11:59 PM EDT on Monday, August 30. The candidates will be given an opportunity to make brief comments and/or accept questions from the community at the NANOG 50 Community Meeting on Sunday, October 3. As a reminder, the full election timeline is: Aug. 2 - SC Nominations begin Aug. 24 - Potential charter amendments discussed in nanog-futures Aug. 24 - PC Nominations begin Aug. 30 - SC Candidate information posted/nominations close Sep. 13 - Call for Communications Committee nominations Sep. 21 - Ballot approved Oct. 3 - Voting opens at 12:00 EDT Oct. 4 - PC Candidate Information posted/nominations close Oct. 6 - Voting closes at 09:15 EDT, results announced before the close of NANOG 50. For the SC, Steve Feldman _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From tvhawaii at shaka.com Mon Aug 23 03:23:19 2010 From: tvhawaii at shaka.com (Michael Painter) Date: Sun, 22 Aug 2010 22:23:19 -1000 Subject: PacketShader Message-ID: <00BC692B904D4C4CB380A3074CB0E4EA@DELL16> Researchers in South Korea have built a networking router that transmits data at record speeds from components found in most high-end desktop computers. A team from the Korea Advanced Institute of Science and Technology created the router, which transmits data at nearly 40 gigabytes per second--many times faster than the previous record for such a device. The techniques used by the researchers could lead to a number of breakthroughs, including the use of cheaper commodity chips, such as those made by Intel and Nvidia, in high-performance routers, in place of custom-made hardware. The software developed by the researchers could also serve as a testbed for novel networking protocols that might eventually replace the decades-old ones on which the Internet currently runs. http://www.technologyreview.com/communications/26096/?nlid=3423 From leigh.porter at ukbroadband.com Mon Aug 23 04:31:34 2010 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 23 Aug 2010 10:31:34 +0100 Subject: BCP38 exceptions for RFC1918 space In-Reply-To: <135798.1281965216@localhost> References: <201008161150.o7GBo08b044855@aurora.sol.net> <135798.1281965216@localhost> Message-ID: I very often see 1918 space in ICMP responses. It's quite dumb. -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: 16 August 2010 14:27 To: Joe Greco Cc: nanog at merit.edu Subject: Re: BCP38 exceptions for RFC1918 space On Mon, 16 Aug 2010 06:50:00 CDT, Joe Greco said: > > What *possible* use case would require a 1918-sourced packet to be > > traversing the public internet? We're all waiting with bated breath > > to hear this one. ;) > > It's great for showing in traceroutes who the heel is. Like I said, at that point it's name-n-shame time. From Valdis.Kletnieks at vt.edu Mon Aug 23 04:59:43 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 23 Aug 2010 05:59:43 -0400 Subject: PacketShader In-Reply-To: Your message of "Sun, 22 Aug 2010 22:23:19 -1000." <00BC692B904D4C4CB380A3074CB0E4EA@DELL16> References: <00BC692B904D4C4CB380A3074CB0E4EA@DELL16> Message-ID: <104783.1282557583@localhost> On Sun, 22 Aug 2010 22:23:19 -1000, Michael Painter said: > Researchers in South Korea have built a networking router that transmits data > at record speeds from components found in most high-end desktop computers > http://www.technologyreview.com/communications/26096/?nlid=3423 Two great quotes from the article: "That isn't fast enough to take advantage of the full speed of a typical network card, which operates at 10 gigabytes per second." Anybody got a network of PCs that have cards that run at 10GBytes/sec? ;) For that matter, have enough 10Gbit network cards shipped that they are now considered "typical" (as in "more than 5%")? A Lamborghini costs about 10 times as much as a nice Camry. 10Gig cards are closer to 30-50 times as much as 1gig cards. Now, if Lambos aren't typical cars, are 10Gig cards typical? Just sayin'.... "Lash enough software routers together that run at 40 gigabytes per second, and you get what is essentially a single-terabit router. Using such a system, routers might some day run completely in software." Ahh.. but the lashing is the tricky part that costs the big bucks, as these guys will undoubtedly discover - life will get a lot more complicated once they saturate the first PCI backplane and need a second. Who wants to bet they'll end up re-inventing SGI's NUMAlink or similar interconnect? ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Aug 23 07:00:06 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 23 Aug 2010 21:30:06 +0930 Subject: PacketShader In-Reply-To: <104783.1282557583@localhost> References: <00BC692B904D4C4CB380A3074CB0E4EA@DELL16> <104783.1282557583@localhost> Message-ID: <20100823213006.58dc2540@opy.nosense.org> On Mon, 23 Aug 2010 05:59:43 -0400 Valdis.Kletnieks at vt.edu wrote: > On Sun, 22 Aug 2010 22:23:19 -1000, Michael Painter said: > > Researchers in South Korea have built a networking router that transmits data > > at record speeds from components found in most high-end desktop computers > > http://www.technologyreview.com/communications/26096/?nlid=3423 > > Two great quotes from the article: > > "That isn't fast enough to take advantage of the full speed of a typical > network card, which operates at 10 gigabytes per second." > > Anybody got a network of PCs that have cards that run at 10GBytes/sec? ;) > I missed that, and that answers the "was it a GigaBytes verses Gigabits error" question. Nothing new here by the looks of it - people in this thread were getting those sorts of speeds a year ago out of PC hardware under Linux - http://lkml.org/lkml/2009/7/15/234 "I have achieved a collective throughput of 66.25 Gbit/s." "We've achieved 70 Gbps aggregate unidirectional TCP performance from one P6T6 based system to another." From nanog at shankland.org Mon Aug 23 08:27:00 2010 From: nanog at shankland.org (Jim Shankland) Date: Mon, 23 Aug 2010 06:27:00 -0700 Subject: PacketShader In-Reply-To: <20100823213006.58dc2540@opy.nosense.org> References: <00BC692B904D4C4CB380A3074CB0E4EA@DELL16> <104783.1282557583@localhost> <20100823213006.58dc2540@opy.nosense.org> Message-ID: <4C727724.6050007@shankland.org> Mark Smith wrote: > On Mon, 23 Aug 2010 05:59:43 -0400 > Valdis.Kletnieks at vt.edu wrote: > > I missed that, and that answers the "was it a GigaBytes verses Gigabits > error" question. Nothing new here by the looks of it - people in this > thread were getting those sorts of speeds a year ago out of PC hardware > under Linux - > > http://lkml.org/lkml/2009/7/15/234 > > "I have achieved a collective throughput of 66.25 Gbit/s." > > "We've achieved 70 Gbps aggregate unidirectional TCP performance from > one P6T6 based system to another." Very nice, but doing this with 1514-byte packets is the low-hanging fruit. (9K packets? That's the fruit that falls off the tree and into your basket while you're napping :-).) The more interesting limit: how many 40-byte packets per second can you shovel into this system and still have all of them come out the other end? Jim Shankland From christian.oflaherty at hotmail.com Mon Aug 23 09:13:22 2010 From: christian.oflaherty at hotmail.com (Chris O'Fla O'Flaherty) Date: Mon, 23 Aug 2010 11:13:22 -0300 Subject: Other NOGs around the world? In-Reply-To: <4C71B5670200004600037C99@d-gws03.jfsp.gov.br> References: <4C71B5670200004600037C99@d-gws03.jfsp.gov.br> Message-ID: > > What other "network operator groups" are there around the world The Latin America and the Caribbean NOG meeting will be 19-22 October.http://www.lacnog.org/en/eventos/lacnog-2010/inicio Call for Presentations deadline, 30 August.http://www.lacnog.org/en/meetings/lacnog-2010/call-presentations Registration:http://lacnic.net/en/eventos/lacnicxiv/form-reg.html Sponsorship opportunities:http://www.lacnog.org/en/meetings/lacnog-2010/sponsors From wjhns61 at hardakers.net Mon Aug 23 09:31:36 2010 From: wjhns61 at hardakers.net (Wes Hardaker) Date: Mon, 23 Aug 2010 07:31:36 -0700 Subject: DNSSEC and SSL In-Reply-To: <20100822195727.GA26860@besserwisser.org> (Mans Nilsson's message of "Sun, 22 Aug 2010 21:57:27 +0200") References: <4C7076B5.9050103@kenweb.org> <4C71220F.6040806@kenweb.org> <20100822195727.GA26860@besserwisser.org> Message-ID: >>>>> On Sun, 22 Aug 2010 21:57:27 +0200, Mans Nilsson said: MN> The best option today is to run a full-service resolver on the host; The DNSSEC-Tools project has instrumented a large number of applications with an in-application validating resolver. Including OpenSSH (with a new auto-accept-keys option!), sendmail, postfix, libspf, thunderbird, lftp, wget, ncftp, ... -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ From dot at dotat.at Mon Aug 23 09:35:55 2010 From: dot at dotat.at (Tony Finch) Date: Mon, 23 Aug 2010 15:35:55 +0100 Subject: DNSSEC and SSL In-Reply-To: <20100822213402.GA15113@vacation.karoshi.com.> References: <4C7076B5.9050103@kenweb.org> <4C71220F.6040806@kenweb.org> <20100822213402.GA15113@vacation.karoshi.com.> Message-ID: On Sun, 22 Aug 2010, bmanning at vacation.karoshi.com wrote: > On Sun, Aug 22, 2010 at 09:11:43AM -0400, ML wrote: > > > > Is a DNSSEC capable stub resolver not in the cards? > > yes it is. unbound was originally designed for that very niche. Unbound is a full service resolver not a stub resolver. Tony. -- f.anthony.n.finch http://dotat.at/ VIKING NORTH UTSIRE SOUTH UTSIRE: NORTHEASTERLY 3 OR 4, INCREASING 5 TO 7, OCCASIONALLY GALE 8 IN SOUTH UTSIRE, BACKING NORTHWESTERLY LATER. MODERATE OR ROUGH. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD. From scott at sberkman.net Mon Aug 23 09:40:29 2010 From: scott at sberkman.net (Scott Berkman) Date: Mon, 23 Aug 2010 10:40:29 -0400 Subject: on network monitoring and security - req for monitoring tools In-Reply-To: <20100821215742.GF10007@subspacefield.org> References: <20100821215742.GF10007@subspacefield.org> Message-ID: <00e001cb42d1$22b311b0$68193510$@net> Are you looking only at Open Source tools? If not you are missing all of the most widely deployed tools out there (including): HP Open View Cisco Works IBM Tivoli/NetCool Smarts (now EMC Ionix) Also a few other open tools: ZenOSS Zabbix You will also need to look at separate security monitoring software if your goal is to cover that. Not including any commercial vendors, I'd say you at least need to include: SNORT (possibly including a front end like BASE/ACID) Suricata Nessus Sguil As to one solution being "better" than the other, a lot of it comes down to opinion and exactly what you need. Also are you willing to do a lot of coding to get it to do exactly what you want? What is your budget? How big is your network? What are the vendors in question? What is most important to you (graphing, alerting, automated fault resolution, topology discovery,...)? How much staff do you have dedicated to the project? And on and on... -Scott -----Original Message----- From: travis+ml-nanog at subspacefield.org [mailto:travis+ml-nanog at subspacefield.org] Sent: Saturday, August 21, 2010 5:58 PM To: nanog at nanog.org Subject: on network monitoring and security - req for monitoring tools Hi, I'm putting together a book on security*, and wanted some expert input onto network monitoring solutions... http://www.subspacefield.org/security/security_concepts.html Nagios, Net-SNMP, ifgraph, cacti, OpenNMS... any others? Any summaries of when one is better than the other? Any suggestions on section 13-15? I imagine I'll offend some of you by not distinguishing between system and network adminsitration, but... it's a small section right now, maybe if it grows. OT: I had issues with understanding MIBs and SNMP tools... specifically, I wanted to query and graph the pf-specific MIB... any suggested places to ask? Do I ask on the Net-SNMP list, or is there a better place? Also, cacti... seemed to behave differently based on whether the target was Linux-based or BSD-based... I suppose the cacti-users is the right place to ask, but if anyone has any suggestions, please LMK. I hate the UI. -- My emails do not have attachments; it's a digital signature that your mail program doesn't understand. | http://www.subspacefield.org/~travis/ If you are a spammer, please email john at subspacefield.org to get blacklisted. From dot at dotat.at Mon Aug 23 09:49:52 2010 From: dot at dotat.at (Tony Finch) Date: Mon, 23 Aug 2010 15:49:52 +0100 Subject: DNSSEC and SSL In-Reply-To: <20100822195727.GA26860@besserwisser.org> References: <4C7076B5.9050103@kenweb.org> <4C71220F.6040806@kenweb.org> <20100822195727.GA26860@besserwisser.org> Message-ID: On Sun, 22 Aug 2010, Mans Nilsson wrote: > > OTOH: A thicker stub resolver does indeed exist; lwresd in the BIND > suite. Calling it from applications does however mean using new API > calls; since the traditional resolver API is oblivious to DNSSEC. lwresd is in fact a full service resolver, though it is designed for forward-only usage. Although its man page says it is "stripped-down", it is in fact just the normal named binary running in a mode with a simple canned configuration that gets its forwarders from /etc/resolv.conf. AIUI, lwresd was originally conceived to deal with the original IPv6 DNS support (A6 records and binary labels). It would need quite a lot of re-working in the lwres client library (and possibly also the lwres protocol) to provide proper DNSSEC support. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT: CYCLONIC, BECOMING SOUTHWEST, GALE 8 TO STORM 10, INCREASING VIOLENT STORM 11 FOR A TIME. ROUGH OR VERY ROUGH. RAIN OR SQUALLY SHOWERS. MODERATE OR POOR. From jakob at kirei.se Mon Aug 23 09:55:18 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 23 Aug 2010 16:55:18 +0200 Subject: DNSSEC and SSL In-Reply-To: References: <4C7076B5.9050103@kenweb.org> <4C71220F.6040806@kenweb.org> <20100822213402.GA15113@vacation.karoshi.com.> Message-ID: On 23 aug 2010, at 16.35, Tony Finch wrote: > Unbound is a full service resolver not a stub resolver. depending on configuration, unbound can be used as both a full service resolve and a stub. jakob From sterbeats at gmail.com Mon Aug 23 10:03:11 2010 From: sterbeats at gmail.com (Ali) Date: Mon, 23 Aug 2010 08:03:11 -0700 Subject: BCP38 exceptions for RFC1918 space In-Reply-To: References: <201008161150.o7GBo08b044855@aurora.sol.net> <135798.1281965216@localhost> Message-ID: <10B25AD7-B5D0-4E93-94C2-094A35E37EBA@gmail.com> Hahahahah How do we prevent BGP loops? Hahahhaahb Sent via mobile. On Aug 23, 2010, at 2:31 AM, "Leigh Porter" wrote: > I very often see 1918 space in ICMP responses. It's quite dumb. > > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: 16 August 2010 14:27 > To: Joe Greco > Cc: nanog at merit.edu > Subject: Re: BCP38 exceptions for RFC1918 space > > On Mon, 16 Aug 2010 06:50:00 CDT, Joe Greco said: > >>> What *possible* use case would require a 1918-sourced packet to be >>> traversing the public internet? We're all waiting with bated breath >>> to hear this one. ;) >> >> It's great for showing in traceroutes who the heel is. > > Like I said, at that point it's name-n-shame time. > From cmaurand at xyonet.com Mon Aug 23 10:03:56 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Mon, 23 Aug 2010 11:03:56 -0400 Subject: DNSSEC and SSL In-Reply-To: <20100822195727.GA26860@besserwisser.org> References: <4C7076B5.9050103@kenweb.org> <4C71220F.6040806@kenweb.org> <20100822195727.GA26860@besserwisser.org> Message-ID: <4C728DDC.6050607@xyonet.com> On 8/22/2010 3:57 PM, Mans Nilsson wrote: > a DNSSEC capable stub resolver not in the cards? > The best option today is to run a full-service resolver on the host; > which is a tad heavy for most desktops, not to speak about the cache > misses that would cause root server system load. The latter of course > can be avoided by setting forwarders. > > OTOH: A thicker stub resolver does indeed exist; lwresd in the BIND > suite. Calling it from applications does however mean using new API > calls; since the traditional resolver API is oblivious to DNSSEC. > PowerDNS resolver. Very fast, very light. --Curtis From rubensk at gmail.com Mon Aug 23 10:47:21 2010 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 23 Aug 2010 12:47:21 -0300 Subject: DNSSEC and SSL In-Reply-To: <4C7076B5.9050103@kenweb.org> References: <4C7076B5.9050103@kenweb.org> Message-ID: The fact hat Verisign kept the domain business and sold the CA business to Symantec tells which business they think is stronger. Rubens On Sat, Aug 21, 2010 at 10:00 PM, ML wrote: > Would a future with a ubiquitous DNSSEC deployment eliminate the market > for commercial CAs? > > Would functioning DNSSEC + self signed certs be more secure/trustworthy > than our current system of trusted CAs chosen by OS/browser developers? > > > > From joelja at bogus.com Mon Aug 23 10:48:22 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 23 Aug 2010 08:48:22 -0700 Subject: BCP38 exceptions for RFC1918 space In-Reply-To: References: <201008161150.o7GBo08b044855@aurora.sol.net> <135798.1281965216@localhost> Message-ID: <4C729846.1070201@bogus.com> On 8/23/10 2:31 AM, Leigh Porter wrote: > I very often see 1918 space in ICMP responses. It's quite dumb. you wouldn't if you filtered rfc 1918 source addresses on your border. > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: 16 August 2010 14:27 > To: Joe Greco > Cc: nanog at merit.edu > Subject: Re: BCP38 exceptions for RFC1918 space > > On Mon, 16 Aug 2010 06:50:00 CDT, Joe Greco said: > >>> What *possible* use case would require a 1918-sourced packet to be >>> traversing the public internet? We're all waiting with bated breath >>> to hear this one. ;) >> >> It's great for showing in traceroutes who the heel is. > > Like I said, at that point it's name-n-shame time. > > From leigh.porter at ukbroadband.com Mon Aug 23 10:51:40 2010 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 23 Aug 2010 16:51:40 +0100 Subject: BCP38 exceptions for RFC1918 space In-Reply-To: <4C729846.1070201@bogus.com> References: <201008161150.o7GBo08b044855@aurora.sol.net> <135798.1281965216@localhost> <4C729846.1070201@bogus.com> Message-ID: Oh I do, just not to my workstation ;-) -----Original Message----- From: Joel Jaeggli [mailto:joelja at bogus.com] Sent: 23 August 2010 16:48 To: Leigh Porter Cc: Valdis.Kletnieks at vt.edu; Joe Greco; nanog at merit.edu Subject: Re: BCP38 exceptions for RFC1918 space On 8/23/10 2:31 AM, Leigh Porter wrote: > I very often see 1918 space in ICMP responses. It's quite dumb. you wouldn't if you filtered rfc 1918 source addresses on your border. > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: 16 August 2010 14:27 > To: Joe Greco > Cc: nanog at merit.edu > Subject: Re: BCP38 exceptions for RFC1918 space > > On Mon, 16 Aug 2010 06:50:00 CDT, Joe Greco said: > >>> What *possible* use case would require a 1918-sourced packet to be >>> traversing the public internet? We're all waiting with bated breath >>> to hear this one. ;) >> >> It's great for showing in traceroutes who the heel is. > > Like I said, at that point it's name-n-shame time. > > From charles at knownelement.com Mon Aug 23 11:15:28 2010 From: charles at knownelement.com (Charles N Wyble) Date: Mon, 23 Aug 2010 09:15:28 -0700 Subject: on network monitoring and security - req for monitoring tools In-Reply-To: <00e001cb42d1$22b311b0$68193510$@net> References: <20100821215742.GF10007@subspacefield.org> <00e001cb42d1$22b311b0$68193510$@net> Message-ID: <4C729EA0.9020801@knownelement.com> On 08/23/2010 07:40 AM, Scott Berkman wrote: > Are you looking only at Open Source tools? If not you are missing all of > the most widely deployed tools out there (including): > > > You will also need to look at separate security monitoring software if your > goal is to cover that. Not including any commercial vendors, I'd say you at > least need to include: > SNORT (possibly including a front end like BASE/ACID) > Suricata > Nessus > These days I use openvas.org instead of nessus. From lorddoskias at gmail.com Mon Aug 23 11:49:23 2010 From: lorddoskias at gmail.com (lorddoskias) Date: Mon, 23 Aug 2010 19:49:23 +0300 Subject: Tagged vlan inside isolated pvlan Message-ID: <4C72A693.2080304@gmail.com> Hello, I have a catalyst 6503 with sup32 and was trying to set a tagged vlan inside a pvlan. Basically I wanna have the behavior of: switchport mode access switchport access vlan 101 switchport protected. So that other machines connected to the 6503 won't be able to communicate with this port (apart from the uplink) and in the same time I want to have vlan 101 tagged in the isolated port. Regards, Nikolay From joelja at bogus.com Mon Aug 23 12:17:31 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 23 Aug 2010 10:17:31 -0700 Subject: PacketShader In-Reply-To: <104783.1282557583@localhost> References: <00BC692B904D4C4CB380A3074CB0E4EA@DELL16> <104783.1282557583@localhost> Message-ID: <4C72AD2B.8020702@bogus.com> On 8/23/10 2:59 AM, Valdis.Kletnieks at vt.edu wrote: > On Sun, 22 Aug 2010 22:23:19 -1000, Michael Painter said: >> Researchers in South Korea have built a networking router that >> transmits data at record speeds from components found in most >> high-end desktop computers >> http://www.technologyreview.com/communications/26096/?nlid=3423 > > Two great quotes from the article: > > "That isn't fast enough to take advantage of the full speed of a > typical network card, which operates at 10 gigabytes per second." > > Anybody got a network of PCs that have cards that run at > 10GBytes/sec? ;) I have a journalist who can keep track of signficant digits... > For that matter, have enough 10Gbit network cards shipped that they > are now considered "typical" (as in "more than 5%")? A Lamborghini > costs about 10 times as much as a nice Camry. 10Gig cards are closer > to 30-50 times as much as 1gig cards. Now, if Lambos aren't typical > cars, are 10Gig cards typical? Just sayin'.... 10gig nics are becoming ubiquitous in datacenters. 10Gigabit on mainboard is pretty ubiquitous in in bladeservers and adds about $150 to the BOM of a 1u pizza box in volume (for copper). > "Lash enough software routers together that run at 40 gigabytes per > second, and you get what is essentially a single-terabit router. > Using such a system, routers might some day run completely in > software." > > Ahh.. but the lashing is the tricky part that costs the big bucks, as > these guys will undoubtedly discover - life will get a lot more > complicated once they saturate the first PCI backplane and need a > second. Who wants to bet they'll end up re-inventing SGI's NUMAlink > or similar interconnect? ;) pci isn't a shared bus anymore it's a series of tubes... In any event, they don't have to, we have quick-path which 100Gb/s per-direction per path at 3.2ghz or pci-e 3.0 which is 8Gb/s per lane and comes with all the lovely logic you expect from a (non-ethernet) switch fabric. What it really comes down to is packets per watt or packets per dollar, if it's cheaper to do it this way then people will, if not BFD. > From bzs at world.std.com Mon Aug 23 12:23:23 2010 From: bzs at world.std.com (Barry Shein) Date: Mon, 23 Aug 2010 13:23:23 -0400 Subject: DNSSEC and SSL In-Reply-To: References: <4C7076B5.9050103@kenweb.org> Message-ID: <19570.44683.227473.698613@world.std.com> > The fact hat Verisign kept the domain business and sold the CA > business to Symantec tells which business they think is stronger. FWIW, I remember being at a tech company some of you have heard of when the CEO announced we'd just sold one of the more profitable non-core units to help fund core product devpt. Someone in the audience pointed out it was probably our strongest (non-core) unit, why not sell one of the weaker ones? "We wouldn't get a lot of money for a weak unit now would we?" he answered. So, maybe yes, maybe no. But this reasoning alone doesn't settle it. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From sfouant at shortestpathfirst.net Mon Aug 23 12:50:00 2010 From: sfouant at shortestpathfirst.net (sfouant at shortestpathfirst.net) Date: Mon, 23 Aug 2010 11:50:00 -0600 Subject: Tagged vlan inside isolated pvlan In-Reply-To: <4C72A693.2080304@gmail.com> References: <4C72A693.2080304@gmail.com> Message-ID: > Hello, > > I have a catalyst 6503 with sup32 and was trying to set a tagged vlan > inside a pvlan. Basically I wanna have the behavior of: > > switchport mode access > switchport access vlan 101 > switchport protected. > > So that other machines connected to the 6503 won't be able to > communicate with this port (apart from the uplink) and in the same time > I want to have vlan 101 tagged in the isolated port. Check out http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sga/configuration/guide/pvlans.html#wp1130380 for more information on configuring PVLANs for trunking. You're going to want to configure VLAN 101 as your Isolated VLAN inside the Native (Primary) VLAN, and you'll enable the trunking on the secondary VLAN. Something along the following will give you the expected behavior: switchport mode private-vlan trunk secondary HTHs. Stefan Fouant From frnkblk at iname.com Mon Aug 23 13:52:46 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Mon, 23 Aug 2010 13:52:46 -0500 Subject: Looking for suggestions for an internet content filtering appliance Message-ID: We offer an optional internet content filtering service to our residential and business customers using M86's appliance (http://www.m86security.com/products/web_security/m86-web-filtering-reportin g-suite.asp). I've been in conversation with them since Q1 regards IPv6 support, but the update I received today was that IPv6 support won't be available until middle to late next year. That's not ideal, because the local college is a significant user and they started with IPv6 this summer. College students can easily bypass content filtering by using the IPv6 version of the site (i.e. http://www.playboy.com.sixxs.org) Wondering if anyone can point me to a similar appliance. I know that Barracuda has such an appliance but it has one limitation I don't like, and that Fortinet and Ironport have more expensive products. It must be able to operate in pass-by/SPAN mode, not inline, and handle traffic rates up to 1 Gbps. We currently move 400+ Mbps "by" it and internet usage only goes up. Thanks in advance for any suggestions you have. Kind regards, Frank From oberman at es.net Mon Aug 23 13:56:29 2010 From: oberman at es.net (Kevin Oberman) Date: Mon, 23 Aug 2010 11:56:29 -0700 Subject: PacketShader In-Reply-To: Your message of "Mon, 23 Aug 2010 06:27:00 PDT." <4C727724.6050007@shankland.org> Message-ID: <20100823185630.072D81CC3B@ptavv.es.net> > Date: Mon, 23 Aug 2010 06:27:00 -0700 > From: Jim Shankland > > Mark Smith wrote: > > On Mon, 23 Aug 2010 05:59:43 -0400 > > Valdis.Kletnieks at vt.edu wrote: > > > > I missed that, and that answers the "was it a GigaBytes verses Gigabits > > error" question. Nothing new here by the looks of it - people in this > > thread were getting those sorts of speeds a year ago out of PC hardware > > under Linux - > > > > http://lkml.org/lkml/2009/7/15/234 > > > > "I have achieved a collective throughput of 66.25 Gbit/s." > > > > "We've achieved 70 Gbps aggregate unidirectional TCP performance from > > one P6T6 based system to another." > > Very nice, but doing this with 1514-byte packets is the low-hanging > fruit. (9K packets? That's the fruit that falls off the tree and > into your basket while you're napping :-).) The more interesting limit: > how many 40-byte packets per second can you shovel into this system > and still have all of them come out the other end? Seems reasonable, but in our testing of 100G Ethernet capable routers we found one that handled 8000 bytes just fine, but could only run 9000 byte packets at about 90G. Just a bit unexpected. Really, in this day and age, a chassis throughput of 100G is pretty trivial. When you start getting up to the Tbps range on a system using "standard components", then I'll be really interested. We do have a network of many end systems attached with 10Gbps Ethernet cards. I'm sure that we are not unique, though probably unusual. We are achieving stable disk to disk transfer rates of well over 3G between the US and Australia. I don't think that PacketShader would handle the load too well. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From jeroen at unfix.org Mon Aug 23 14:15:38 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 23 Aug 2010 21:15:38 +0200 Subject: Looking for suggestions for an internet content filtering appliance In-Reply-To: References: Message-ID: <4C72C8DA.4040605@unfix.org> On 2010-08-23 20:52, Frank Bulk - iName.com wrote: > We offer an optional internet content filtering service to our residential > and business customers using M86's appliance > (http://www.m86security.com/products/web_security/m86-web-filtering-reportin > g-suite.asp). > > I've been in conversation with them since Q1 regards IPv6 support, but the > update I received today was that IPv6 support won't be available until > middle to late next year. That's not ideal, because the local college is a > significant user and they started with IPv6 this summer. College students > can easily bypass content filtering by using the IPv6 version of the site > (i.e. http://www.playboy.com.sixxs.org) Emmm.. if they can use that to circumvent your filter don't you think those same people won't be able to find out about other proxy servers, it is not like the internet is not filled with them or anything. Please note to yourself that you are fighting a lost cause as there are more locations on the Internet that are annoying for the policy than you can list, thus one of the very few ways to make it very hard to 'filter' is to only allow approved sites, and with 'approve' I mean fetch the URL on a controlled machine, scrub it and pass it back, as the moment somebody can have a host on the outside and can send a few bits to it and get an answer back they are outside, if you like it or not. That said, there are loads of free HTTP proxies, anonymizers and other such tools and most of them are not caught by your filtering toy anyway. But indeed, it is a bad thing that they are unable to update their little box to do IPv6, there really is not that much different there. Greets, Jeroen (Who could block stuff on the above URL actually, but except for silly people trying to run torrents over it which does not work but which do hammer those boxes nothing gets blocked [CP is the except]) From trelane at trelane.net Mon Aug 23 14:25:38 2010 From: trelane at trelane.net (Andrew Kirch) Date: Mon, 23 Aug 2010 15:25:38 -0400 Subject: PacketShader In-Reply-To: <4C72AD2B.8020702@bogus.com> References: <00BC692B904D4C4CB380A3074CB0E4EA@DELL16> <104783.1282557583@localhost> <4C72AD2B.8020702@bogus.com> Message-ID: <4C72CB32.70805@trelane.net> On 8/23/2010 1:17 PM, Joel Jaeggli wrote: > What it really comes down to is packets per watt or packets per dollar, > if it's cheaper to do it this way then people will, if not BFD. I disagree here. Core routing isn't purchased based on cost, it's purchased based on support. People have not adopted Vayetta, or Mikrotik or many of the other small routing platforms which are in fact MUCH cheaper than the bridge or the tree (cisco or juniper), and the reason is simply support. If my router breaks beyond my ability to fix it I have a certified engineer (of some value or other) at my site with parts to fix it within 4 hours. This is why people go with Cisco and Juniper. It's also a mechanism of CYA. Would we rather tell our boss that the company has responded and dropped the replacement part in the mail, or that a technician from the router supplier is on their way and will be here very shortly, and ooh, by the way, you did recommend redundant hardware when the piece that broke was purchased, and it was available at a discount. Andrew From khatfield at socllc.net Mon Aug 23 14:46:59 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Mon, 23 Aug 2010 19:46:59 +0000 Subject: Looking for suggestions for an internet content filteringappliance In-Reply-To: <4C72C8DA.4040605@unfix.org> References: <4C72C8DA.4040605@unfix.org> Message-ID: <99222389-1282592820-cardhu_decombobulator_blackberry.rim.net-1041460579-@bda903.bisx.prod.on.blackberry> (Excuse me if I missed part of the email chain. This may have already been mentioned) It could be a bit of an annoyance for configuration but the one method you could use is to force a proxy internally. I am a bit unsure why most don't do this already but it has it's flaws. 1) Lack of static/dynamic IP's 2) More work for tracking 3) Management of additional infrastructure However, you could force a proxy and run it inhouse, like squid or some other type. This would give you some advantages: 1) Content caching - increasing speeds for users while decreasing your overall bandwidth utilization. 2) Increased security for filtering out malware/virii. --- Now that is more of a sledgehammer approach and I am not sure I would highly recommend it. A better solution which will not work for the more advanced users but it will likely work for the majority, which is to work with a provider like OpenDNS for your dns resolution. They have an easily configurable filtering system which you can apply to your users. This would allow you to block specific content and/or generalized content like (hardcore porn vs educational nudity) This is a better approach. Otherwise, you are likely going to cause real issues with people doing homework or webmd searches, for example. There is not a foolproof method when trying to blanket an entire provider but this would get you closer and it is likely going to be more accurate than keyword blocking/proxy blocking. Best of luck. -----Original Message----- From: Jeroen Massar Date: Mon, 23 Aug 2010 21:15:38 To: Cc: Subject: Re: Looking for suggestions for an internet content filtering appliance On 2010-08-23 20:52, Frank Bulk - iName.com wrote: > We offer an optional internet content filtering service to our residential > and business customers using M86's appliance > (http://www.m86security.com/products/web_security/m86-web-filtering-reportin > g-suite.asp). > > I've been in conversation with them since Q1 regards IPv6 support, but the > update I received today was that IPv6 support won't be available until > middle to late next year. That's not ideal, because the local college is a > significant user and they started with IPv6 this summer. College students > can easily bypass content filtering by using the IPv6 version of the site > (i.e. http://www.playboy.com.sixxs.org) Emmm.. if they can use that to circumvent your filter don't you think those same people won't be able to find out about other proxy servers, it is not like the internet is not filled with them or anything. Please note to yourself that you are fighting a lost cause as there are more locations on the Internet that are annoying for the policy than you can list, thus one of the very few ways to make it very hard to 'filter' is to only allow approved sites, and with 'approve' I mean fetch the URL on a controlled machine, scrub it and pass it back, as the moment somebody can have a host on the outside and can send a few bits to it and get an answer back they are outside, if you like it or not. That said, there are loads of free HTTP proxies, anonymizers and other such tools and most of them are not caught by your filtering toy anyway. But indeed, it is a bad thing that they are unable to update their little box to do IPv6, there really is not that much different there. Greets, Jeroen (Who could block stuff on the above URL actually, but except for silly people trying to run torrents over it which does not work but which do hammer those boxes nothing gets blocked [CP is the except]) From nenolod at systeminplace.net Mon Aug 23 14:55:39 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 23 Aug 2010 14:55:39 -0500 Subject: PacketShader Message-ID: Vyatta's commercial products (the bundles with OS+Hardware) come with adequate support in my experience. William (Sorry for topposting. The android email experience is depressingly lacking.) Andrew Kirch wrote: > On 8/23/2010 1:17 PM, Joel Jaeggli wrote: >> What it really comes down to is packets per watt or packets per dollar, >> if it's cheaper to do it this way then people will, if not BFD. > >I disagree here. Core routing isn't purchased based on cost, it's >purchased based on support. People have not adopted Vayetta, or >Mikrotik or many of the other small routing platforms which are in fact >MUCH cheaper than the bridge or the tree (cisco or juniper), and the >reason is simply support. > >If my router breaks beyond my ability to fix it I have a certified >engineer (of some value or other) at my site with parts to fix it within >4 hours. This is why people go with Cisco and Juniper. It's also a >mechanism of CYA. Would we rather tell our boss that the company has >responded and dropped the replacement part in the mail, or that a >technician from the router supplier is on their way and will be here >very shortly, and ooh, by the way, you did recommend redundant hardware >when the piece that broke was purchased, and it was available at a discount. > >Andrew > From Valdis.Kletnieks at vt.edu Mon Aug 23 15:14:39 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 23 Aug 2010 16:14:39 -0400 Subject: Looking for suggestions for an internet content filteringappliance In-Reply-To: Your message of "Mon, 23 Aug 2010 19:46:59 -0000." <99222389-1282592820-cardhu_decombobulator_blackberry.rim.net-1041460579-@bda903.bisx.prod.on.blackberry> References: <4C72C8DA.4040605@unfix.org> <99222389-1282592820-cardhu_decombobulator_blackberry.rim.net-1041460579-@bda903.bisx.prod.on.blackberry> Message-ID: <26245.1282594479@localhost> On Mon, 23 Aug 2010 19:46:59 -0000, khatfield at socllc.net said: > This would give you some advantages: > 1) Content caching - increasing speeds for users while decreasing your overall bandwidth utilization. Does anybody have any real-world stats on what size local Squid/whatever cache they're using and what % of bandwidth savings they're seeing? (Bonus points if you've identified specific things it helps, like Patch Tuesday or whatever). Might be interesting to see what impact a local Akamai node has on your own caching savings too... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From owen at delong.com Mon Aug 23 15:15:01 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 23 Aug 2010 13:15:01 -0700 Subject: PacketShader In-Reply-To: <4C72CB32.70805@trelane.net> References: <00BC692B904D4C4CB380A3074CB0E4EA@DELL16> <104783.1282557583@localhost> <4C72AD2B.8020702@bogus.com> <4C72CB32.70805@trelane.net> Message-ID: <5D230D21-2679-419E-AAA0-50A632042362@delong.com> On Aug 23, 2010, at 12:25 PM, Andrew Kirch wrote: > On 8/23/2010 1:17 PM, Joel Jaeggli wrote: >> What it really comes down to is packets per watt or packets per dollar, >> if it's cheaper to do it this way then people will, if not BFD. > > I disagree here. Core routing isn't purchased based on cost, it's purchased based on support. People have not adopted Vayetta, or Mikrotik or many of the other small routing platforms which are in fact MUCH cheaper than the bridge or the tree (cisco or juniper), and the reason is simply support. > I disagree. Core routing is about performance, and, the bridge and the tree simply outperform Vayetta and Mikrotik on more realistic small packet sizes when it comes to forwarding rate, interface density, and other issues. Outside the core, you might be right about it being a question of support. > If my router breaks beyond my ability to fix it I have a certified engineer (of some value or other) at my site with parts to fix it within 4 hours. This is why people go with Cisco and Juniper. It's also a mechanism of CYA. Would we rather tell our boss that the company has responded and dropped the replacement part in the mail, or that a technician from the router supplier is on their way and will be here very shortly, and ooh, by the way, you did recommend redundant hardware when the piece that broke was purchased, and it was available at a discount. > That doesn't help as much as you might hope. I've had situations where it tool (bridge or tree) several months to resolve a problem. I have a case open with one of those vendors now for a PMTU-D problem which has been ongoing for many months. Often, I get an update saying it's been escalated to engineering, several weeks go by and I get a request for information already provided. Owen From joelja at bogus.com Mon Aug 23 15:19:23 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 23 Aug 2010 13:19:23 -0700 Subject: PacketShader In-Reply-To: <4C72CB32.70805@trelane.net> References: <00BC692B904D4C4CB380A3074CB0E4EA@DELL16> <104783.1282557583@localhost> <4C72AD2B.8020702@bogus.com> <4C72CB32.70805@trelane.net> Message-ID: <4C72D7CB.4080207@bogus.com> On 8/23/10 12:25 PM, Andrew Kirch wrote: > On 8/23/2010 1:17 PM, Joel Jaeggli wrote: >> What it really comes down to is packets per watt or packets per dollar, >> if it's cheaper to do it this way then people will, if not BFD. > > I disagree here. Core routing isn't purchased based on cost, it's > purchased based on support. People have not adopted Vayetta, or > Mikrotik or many of the other small routing platforms which are in fact > MUCH cheaper than the bridge or the tree (cisco or juniper), and the > reason is simply support. Neither of those are in the running for .5-1Tb/s forwarding devices. stack up enough vyatta boxs to equal an mx960 or a t1600 and I think you'll get my point. > If my router breaks beyond my ability to fix it I have a certified > engineer (of some value or other) at my site with parts to fix it within > 4 hours. This is why people go with Cisco and Juniper. It's also a > mechanism of CYA. Would we rather tell our boss that the company has > responded and dropped the replacement part in the mail, or that a > technician from the router supplier is on their way and will be here > very shortly, and ooh, by the way, you did recommend redundant hardware > when the piece that broke was purchased, and it was available at a > discount. > > Andrew > From frnkblk at iname.com Mon Aug 23 15:52:18 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Mon, 23 Aug 2010 15:52:18 -0500 Subject: Looking for suggestions for an internet content filtering appliance In-Reply-To: <4C72C8DA.4040605@unfix.org> References: <4C72C8DA.4040605@unfix.org> Message-ID: Jeroen: Their filtering appliance also filters out free HTTP proxies and anonymizers, some because their known, others because of signatures. It's not perfect, but it catches a lot more than what you might think. And we don't market it as the silver bullet and we let our customers know that this is not the be-all and end-all of content filtering, but something that catches the vast majority accidental site visits. If someone wants to work around it they can run a VPN, but for 99.99% of the subscribers of this service, it's a lot better than nothing or running software on each PC (which doesn't help for Xbox, etc). If you have a URL you want me to try, let me know and I'll be able to tell you what the appliance thinks. Regards, Frank -----Original Message----- From: Jeroen Massar [mailto:jeroen at unfix.org] Sent: Monday, August 23, 2010 2:16 PM To: frnkblk at iname.com Cc: nanog at nanog.org Subject: Re: Looking for suggestions for an internet content filtering appliance On 2010-08-23 20:52, Frank Bulk - iName.com wrote: > We offer an optional internet content filtering service to our residential > and business customers using M86's appliance > (http://www.m86security.com/products/web_security/m86-web-filtering-reportin > g-suite.asp). > > I've been in conversation with them since Q1 regards IPv6 support, but the > update I received today was that IPv6 support won't be available until > middle to late next year. That's not ideal, because the local college is a > significant user and they started with IPv6 this summer. College students > can easily bypass content filtering by using the IPv6 version of the site > (i.e. http://www.playboy.com.sixxs.org) Emmm.. if they can use that to circumvent your filter don't you think those same people won't be able to find out about other proxy servers, it is not like the internet is not filled with them or anything. Please note to yourself that you are fighting a lost cause as there are more locations on the Internet that are annoying for the policy than you can list, thus one of the very few ways to make it very hard to 'filter' is to only allow approved sites, and with 'approve' I mean fetch the URL on a controlled machine, scrub it and pass it back, as the moment somebody can have a host on the outside and can send a few bits to it and get an answer back they are outside, if you like it or not. That said, there are loads of free HTTP proxies, anonymizers and other such tools and most of them are not caught by your filtering toy anyway. But indeed, it is a bad thing that they are unable to update their little box to do IPv6, there really is not that much different there. Greets, Jeroen (Who could block stuff on the above URL actually, but except for silly people trying to run torrents over it which does not work but which do hammer those boxes nothing gets blocked [CP is the except]) From graham at apolix.co.za Mon Aug 23 16:05:07 2010 From: graham at apolix.co.za (Graham Beneke) Date: Mon, 23 Aug 2010 23:05:07 +0200 Subject: Looking for suggestions for an internet content filteringappliance In-Reply-To: <26245.1282594479@localhost> References: <4C72C8DA.4040605@unfix.org> <99222389-1282592820-cardhu_decombobulator_blackberry.rim.net-1041460579-@bda903.bisx.prod.on.blackberry> <26245.1282594479@localhost> Message-ID: <4C72E283.6080903@apolix.co.za> On 23/08/2010 22:14, Valdis.Kletnieks at vt.edu wrote: > Does anybody have any real-world stats on what size local Squid/whatever cache > they're using and what % of bandwidth savings they're seeing? (Bonus points if > you've identified specific things it helps, like Patch Tuesday or whatever). I have seen 30-50% savings on some networks when patch Tuesday hits. Its not achievable on a vanilla squid though and needs some code magic. With general traffic the savings tend to be around the 10-20% mark. Unforunately much of the stuff you really want to cache like your YouTube vids is intentionally filled with cookies that make it un-cachable. This is done intentionally for copyright compliance and various other things. -- Graham Beneke From jfbeam at gmail.com Mon Aug 23 16:39:47 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 23 Aug 2010 17:39:47 -0400 Subject: Should routers send redirects by default? In-Reply-To: <20100822101201.37215017@opy.nosense.org> References: <3887672486120547ACEB7B3ACA6E46EC1B40E46E@exchange> <4C6FDEDF.2060400@brightok.net> <20100822101201.37215017@opy.nosense.org> Message-ID: On Sat, 21 Aug 2010 20:42:01 -0400, Mark Smith wrote: > In IPv6, redirects serve two purposes, where as in IPv4 they only > served one - IPv4 redirects serve exactly the same two situations... both are situations where a router would be required to hairpin a packet -- either the destination is on-wire or the path to it is elsewhere on-wire. Let's say host 1.100 has a default gw of 1.1 and no other routes. A packet destined for 2.1 would go to 1.1, even if 2.1 is on the same wire. Following old rules, 1.1 sends a redirect and drops the packet. Most hosts would ignore that redirect as it "makes no sense" (redirects are not a substitute for device routes. I've seen this happen too many times.) Now, if 2.1 was behind 1.2, the redirect would tell 1.100 to go there instead. (This isn't as much of a problem these days since routers don't to the "drop packet" part -- which used to be mandated by RFC. And "secondary" networks have given way to inter-VLAN routing.) --Ricky From tim2.sanderson at gmail.com Mon Aug 23 17:13:30 2010 From: tim2.sanderson at gmail.com (Tim Sanderson) Date: Mon, 23 Aug 2010 18:13:30 -0400 Subject: web site counter-phishing services Message-ID: <00c801cb4310$6c893460$459b9d20$@gmail.com> My company has used Perimeter E-Security's CounterPhish service for a while but we are not completely happy with it. Is anyone familiar with any other vendors that provide such service and are you happy with it? From dougb at dougbarton.us Mon Aug 23 17:12:28 2010 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 23 Aug 2010 15:12:28 -0700 Subject: DNSSEC and SSL In-Reply-To: <4C728DDC.6050607@xyonet.com> References: <4C7076B5.9050103@kenweb.org> <4C71220F.6040806@kenweb.org> <20100822195727.GA26860@besserwisser.org> <4C728DDC.6050607@xyonet.com> Message-ID: <4C72F24C.1020503@dougbarton.us> On 08/23/2010 08:03, Curtis Maurand wrote: > PowerDNS resolver. Very fast, very light. For the purpose of DNSSEC support powerdns might not be the best choice. They are late to the game, and only added DNSSEC support reluctantly due to market pressure. There have been other good suggestions in this thread already, but as always evaluate all possible solutions for your particular use case(s). Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From randy at psg.com Mon Aug 23 17:25:05 2010 From: randy at psg.com (Randy Bush) Date: Tue, 24 Aug 2010 07:25:05 +0900 Subject: PacketShader In-Reply-To: <20100823185630.072D81CC3B@ptavv.es.net> References: <4C727724.6050007@shankland.org> <20100823185630.072D81CC3B@ptavv.es.net> Message-ID: > Really, in this day and age, a chassis throughput of 100G is pretty > trivial. When you start getting up to the Tbps range on a system using > "standard components", then I'll be really interested. i suspect that a rule of thumb is that leading edge home appliances are one decimal digit behind leading edge routers and cost two decimal digits less. so it's a trade-off. which is why we get the big bucks. randy From jtk at cymru.com Mon Aug 23 17:38:13 2010 From: jtk at cymru.com (John Kristoff) Date: Mon, 23 Aug 2010 17:38:13 -0500 Subject: Real ops talking to future ops Message-ID: <20100823173813.5b1b7c1c@t61p> I'm afraid this is only slightly operational and limited to a subset of the NANOG crowd. I apologize profusely in advance for abusing the list as I might, but I can't think of a more suitable group of people to approach. I think the essence of the request is in line with the spirit of NANOG. As some of you know, I teach networking classes at DePaul University in Chicago. What has gone over extremely well in the past is when I've had a real op come talk to the students, even if its just about what they do on a daily basis. If any of you are in or around the Loop in Chicago area on a Wednesday night between September and November of this year and wouldn't mind getting up in front a few geeky undergrads, I would be forever grateful if you do so with my class. I'm not asking for anything polished. If you've presented something recently that you think a computer science undergrad should be able to grasp or even if just have enable, your future ops want you to tell them about it. ...and yes, many of the other instructors they come into contact with are focusing only on class A, B, C addressing. So you'll be doing the world a favor and maybe even me, by saying some things I'm not the only one saying to them before they interview circuit. Here's what things looked like last quarter to give you an idea of the general topics covered: Thanks, John From dhc2 at dcrocker.net Mon Aug 23 18:54:18 2010 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Mon, 23 Aug 2010 16:54:18 -0700 Subject: Real ops talking to future ops In-Reply-To: <20100823173813.5b1b7c1c@t61p> References: <20100823173813.5b1b7c1c@t61p> Message-ID: <4C730A2A.5030100@dcrocker.net> On 8/23/2010 3:38 PM, John Kristoff wrote: > many of the other instructors they come into contact with > are focusing only on class A, B, C addressing wow. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ml at kenweb.org Mon Aug 23 19:17:53 2010 From: ml at kenweb.org (ML) Date: Mon, 23 Aug 2010 20:17:53 -0400 Subject: Real ops talking to future ops In-Reply-To: <4C730A2A.5030100@dcrocker.net> References: <20100823173813.5b1b7c1c@t61p> <4C730A2A.5030100@dcrocker.net> Message-ID: <4C730FB1.9060509@kenweb.org> On 8/23/2010 7:54 PM, Dave CROCKER wrote: > > > On 8/23/2010 3:38 PM, John Kristoff wrote: >> many of the other instructors they come into contact with >> are focusing only on class A, B, C addressing > > > wow. I'm just as surprised as you are. They left out AppleTalk. From jtk at cymru.com Mon Aug 23 20:39:57 2010 From: jtk at cymru.com (John Kristoff) Date: Mon, 23 Aug 2010 20:39:57 -0500 Subject: Real ops talking to future ops In-Reply-To: <4C730FB1.9060509@kenweb.org> References: <20100823173813.5b1b7c1c@t61p> <4C730A2A.5030100@dcrocker.net> <4C730FB1.9060509@kenweb.org> Message-ID: <20100823203957.7663db32@t61p> On Mon, 23 Aug 2010 20:17:53 -0400 ML wrote: > I'm just as surprised as you are. They left out AppleTalk. A few classes ago I had a student tell me they had an instructor spend two full classes (out of 10) on Token Ring. I think Token Ring is interesting and I feel a little bit sad about all the token ring experience I have that is slowly rotting to history with no one to pass it on to, but was a wow for me at the time. John From cb.list6 at gmail.com Mon Aug 23 21:59:09 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Mon, 23 Aug 2010 19:59:09 -0700 Subject: Real ops talking to future ops In-Reply-To: <20100823173813.5b1b7c1c@t61p> References: <20100823173813.5b1b7c1c@t61p> Message-ID: > > ? > John, I could not help but take a peak at the class topics. I nearly jumped out of my seat with joy in seeing the e2e principle http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf But, then went sad and jaded again when poking around revealed no signs of IPv6.... Cameron ========= http://groups.google.com/group/tmoipv6beta ========= From bitkraft at gmail.com Tue Aug 24 02:51:50 2010 From: bitkraft at gmail.com (Brian Spade) Date: Tue, 24 Aug 2010 00:51:50 -0700 Subject: (cisco, or any) acl *reducers* out there? In-Reply-To: <5F0D0E5F-2BB3-43EB-B56A-F622763D78C3@apnic.net> References: <5F0D0E5F-2BB3-43EB-B56A-F622763D78C3@apnic.net> Message-ID: Maybe FLINT? http://www.matasano.com/playbook/flint Never tried it so feedback is welcome... :-) /bs On Wed, Aug 18, 2010 at 5:38 PM, George Michaelson wrote: > I have been looking at acl management s/w in the freecode space and I can > find lots of tools which manage/distribute and test ACLs in routers. > > I'm wondering if anyone has written a parser which can construct rule-trees > and get rid of the cruft, unusable, order-misorder and other issues in a > large ACL pool? > > Its possible this is NP in the wider sense, but even a partial improvement > would be useful > > something which can take a couple of hundred basic and extended ACLs and > tell you > > these don't work > these conflict > the remaining have a sequence and can reduce to this basic > set > > (we've got the usual "acquisition of rule by accretion" problem across 4 > edge/core routers with a mix of public facing, internal, WiFi, guest rules, > and I hate to think this is either start from scratch, or intractable. The > evidence is that its FRAGILE) > > -G > From jethro.binks at strath.ac.uk Tue Aug 24 04:33:28 2010 From: jethro.binks at strath.ac.uk (Jethro R Binks) Date: Tue, 24 Aug 2010 10:33:28 +0100 (BST) Subject: Real ops talking to future ops In-Reply-To: <20100823203957.7663db32@t61p> References: <20100823173813.5b1b7c1c@t61p> <4C730A2A.5030100@dcrocker.net> <4C730FB1.9060509@kenweb.org> <20100823203957.7663db32@t61p> Message-ID: On Mon, 23 Aug 2010, John Kristoff wrote: > On Mon, 23 Aug 2010 20:17:53 -0400 > ML wrote: > > > I'm just as surprised as you are. They left out AppleTalk. > > A few classes ago I had a student tell me they had an instructor spend > two full classes (out of 10) on Token Ring. I think Token Ring is > interesting and I feel a little bit sad about all the token ring > experience I have that is slowly rotting to history with no one to pass > it on to, but was a wow for me at the time. Maybe there's hope for you yet: http://fcotr.org/ Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Computing Officer Information Services, The University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263. From jtk at cymru.com Tue Aug 24 08:31:56 2010 From: jtk at cymru.com (John Kristoff) Date: Tue, 24 Aug 2010 08:31:56 -0500 Subject: Real ops talking to future ops In-Reply-To: References: <20100823173813.5b1b7c1c@t61p> <4C730A2A.5030100@dcrocker.net> <4C730FB1.9060509@kenweb.org> <20100823203957.7663db32@t61p> Message-ID: <20100824083156.2dc78376@t61p> On Tue, 24 Aug 2010 10:33:28 +0100 (BST) Jethro R Binks wrote: > Maybe there's hope for you yet: > > http://fcotr.org/ Hah, I am not available! :-) Someone else sent me that too. Everything old is new again. I'll see their FCoTR and raise them one EtherRing spec: Ob humor, I actually got a phone call from someone at the Tolly Group asking where/how I got permission and the quote from Kevin Tolly since they didn't remember authorizing such an endorsement of EtherRing. John From david.freedman at uk.clara.net Tue Aug 24 09:11:03 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 24 Aug 2010 15:11:03 +0100 Subject: Tagged vlan inside isolated pvlan In-Reply-To: References: <4C72A693.2080304@gmail.com> Message-ID: >sfouant at shortestpathfirst.net wrote: >> Hello, >> >> I have a catalyst 6503 with sup32 and was trying to set a tagged vlan >> inside a pvlan. Basically I wanna have the behavior of: >> >> switchport mode access >> switchport access vlan 101 >> switchport protected. >> >> So that other machines connected to the 6503 won't be able to >> communicate with this port (apart from the uplink) and in the same time >> I want to have vlan 101 tagged in the isolated port. > > Check out > http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sga/configuration/guide/pvlans.html#wp1130380 > for more information on configuring PVLANs for trunking. Not on 6500 I'm afraid, the featureset on everything else compared to cat4k/nexxus is quite crippled, you'll find lots of important things missing on 6500 in PVLAN that are down to I believe hardware limitations. Dave From david.freedman at uk.clara.net Tue Aug 24 09:13:39 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 24 Aug 2010 15:13:39 +0100 Subject: Real ops talking to future ops In-Reply-To: <20100823173813.5b1b7c1c@t61p> References: <20100823173813.5b1b7c1c@t61p> Message-ID: > It is just me that found the location "Loop Campus" amusing in this context? > > Thanks, > > John > > -- David Freedman Group Network Engineering Claranet Group From alan at gtekcommunications.com Tue Aug 24 09:44:37 2010 From: alan at gtekcommunications.com (Alan Bryant) Date: Tue, 24 Aug 2010 09:44:37 -0500 Subject: Motorola Canopy & Prizm Message-ID: I'm looking for some help with Motorola's Prizm software which is used for provisioning of subscriber modules with their Canopy wireless products. We are having some issues with authentication of some customer's and I believe it to be related to the management software (Prizm). Is there anyone on this list with experience with this software? -- Alan Bryant | Systems Administrator Gtek Computers & Wireless, LLC. alan at gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405 From chris at uplogon.com Tue Aug 24 09:59:37 2010 From: chris at uplogon.com (Chris Gotstein) Date: Tue, 24 Aug 2010 09:59:37 -0500 Subject: Motorola Canopy & Prizm In-Reply-To: References: Message-ID: <4C73DE59.1020004@uplogon.com> May want to join the animal farm list which is a group of WISPs that run canopy systems. http://www.afmug.com/the-group On 8/24/2010 9:44 AM, Alan Bryant wrote: > I'm looking for some help with Motorola's Prizm software which is used > for provisioning of subscriber modules with their Canopy wireless > products. > > We are having some issues with authentication of some customer's and I > believe it to be related to the management software (Prizm). > > Is there anyone on this list with experience with this software? -- ---- ---- ---- ---- Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P. http://uplogon.com | +1 906 774 4847 | chris at uplogon.com From dhc2 at dcrocker.net Tue Aug 24 10:11:21 2010 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Tue, 24 Aug 2010 08:11:21 -0700 Subject: Real ops talking to future ops In-Reply-To: <20100823203957.7663db32@t61p> References: <20100823173813.5b1b7c1c@t61p> <4C730A2A.5030100@dcrocker.net> <4C730FB1.9060509@kenweb.org> <20100823203957.7663db32@t61p> Message-ID: <4C73E119.7080901@dcrocker.net> On 8/23/2010 6:39 PM, John Kristoff wrote: > A few classes ago I had a student tell me they had an instructor spend > two full classes (out of 10) on Token Ring. There's a serious need to cover such a construct, but also to introduce it in the context of modern systems: Probably none of what is sold today as ethernet is actually the original ethernet protocol or even close to it. What is sold today is a the ethernet *interface* and some other protocol under it. This difference between the interface and the infrastructure under it that provides service to it is a fundamental construct that is often missed. Standardized interfaces let technology adapt underneath it. So, for example, IBM published the API for netbios, without publishing the protocol. That let some of us build alternative protocols that satisfied the API but ran over TCP. (See RFC 1001, 1002 for the standardized version.) Much of what is sold today as ethernet has a protocol under it that is contention-free. The different Token Ring schemes provide that in a distributed manner.[1] d/ [1] Though my own focus was on email, my CS prof was Dave Farber, so I had to absorb more about TR than I would have wanted. One of the interesting metricts for TR is delay-time per node. The Irvine Ring introduced one bit-time delay. Scaled great. The IBM TR introduced one full packet-time. Didn't scale well. -- Dave Crocker Brandenburg InternetWorking bbiw.net From mwelch at tallshorts.com Tue Aug 24 11:15:32 2010 From: mwelch at tallshorts.com (Matthew Welch) Date: Tue, 24 Aug 2010 11:15:32 -0500 Subject: Motorola Canopy & Prizm In-Reply-To: <4C73DE59.1020004@uplogon.com> References: <4C73DE59.1020004@uplogon.com> Message-ID: We use canopy and prizm at our office. Are you having AP auth issues? On Tue, Aug 24, 2010 at 9:59 AM, Chris Gotstein wrote: > May want to join the animal farm list which is a group of WISPs that run > canopy systems. > > http://www.afmug.com/the-group > > > On 8/24/2010 9:44 AM, Alan Bryant wrote: > >> I'm looking for some help with Motorola's Prizm software which is used >> for provisioning of subscriber modules with their Canopy wireless >> products. >> >> We are having some issues with authentication of some customer's and I >> believe it to be related to the management software (Prizm). >> >> Is there anyone on this list with experience with this software? >> > > -- > ---- ---- ---- ---- > Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P. > http://uplogon.com | +1 906 774 4847 | chris at uplogon.com > > From alan at gtekcommunications.com Tue Aug 24 11:27:38 2010 From: alan at gtekcommunications.com (Alan Bryant) Date: Tue, 24 Aug 2010 11:27:38 -0500 Subject: Motorola Canopy & Prizm In-Reply-To: References: <4C73DE59.1020004@uplogon.com> Message-ID: On Tue, Aug 24, 2010 at 11:15 AM, Matthew Welch wrote: > We use canopy and prizm at our office. Are you having AP auth issues? Over the past few days, a lot of our Subscriber Modules are no longer authenticating with Prizm. If we turn authentication off on the AP, they all immediately register. It is not a signal issue, and it does not appear to be a license issue as these customers have been connecting fine for months. We are possibly using an older version of Prizm. We may attempt to upgrade tonight. It is not limited to one AP, one frequency, or even one geographic area. It is very random and intermittent. Prizm's logs are not helpful at all, and neither is Motorola's support. Any suggestions or direction would be greatly appreciated. -- Alan Bryant | Systems Administrator Gtek Computers & Wireless, LLC. alan at gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405 From mksmith at adhost.com Tue Aug 24 12:20:12 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 24 Aug 2010 10:20:12 -0700 Subject: on network monitoring and security - req for monitoring tools In-Reply-To: <20100821215742.GF10007@subspacefield.org> References: <20100821215742.GF10007@subspacefield.org> Message-ID: <17838240D9A5544AAA5FF95F8D52031608C901ED@ad-exh01.adhost.lan> > -----Original Message----- > From: travis+ml-nanog at subspacefield.org [mailto:travis+ml- > nanog at subspacefield.org] > Sent: Saturday, August 21, 2010 2:58 PM > To: nanog at nanog.org > Subject: on network monitoring and security - req for monitoring tools > > Hi, I'm putting together a book on security*, and wanted some expert > input onto network monitoring solutions... > > http://www.subspacefield.org/security/security_concepts.html > > Nagios, Net-SNMP, ifgraph, cacti, OpenNMS... any others? > I would add OSSIM (http://www.alienvault.com/community.php?section=Home) Mike From vyto at fnal.gov Tue Aug 24 13:15:46 2010 From: vyto at fnal.gov (Vyto Grigaliunas) Date: Tue, 24 Aug 2010 13:15:46 -0500 Subject: IPv6 PMTUD and OS-X Message-ID: <003f01cb43b8$5f5858e0$1e090aa0$@gov> >> 1220? I am pretty sure the minimal IPv6 MTU is 1280 and that below it fragmentation should be handled by the medium that transports packets smaller than that.... Can you enlighten me >> Bill? :) Please correct me if I'm wrong, but last I heard IPv6 routers do not do fragmentation...it's up to the IPv6 end hosts to properly determine the path MTU. Thanks... Vyto Date: Sat, 21 Aug 2010 11:42:04 +0200 From: Jeroen Massar Subject: Re: IPv6 PMTUD and OS-X To: bmanning at vacation.karoshi.com Cc: nanog at nanog.org Message-ID: <4C6F9F6C.80609 at unfix.org> Content-Type: text/plain; charset=UTF-8 On 2010-08-21 09:18, bmanning at vacation.karoshi.com wrote: > On Fri, Aug 20, 2010 at 11:34:23PM +0200, Jeroen Massar wrote: >> On 2010-08-20 23:27, Franck Martin wrote: >>> I'm trying to debug a pesky PMTUD issue with IPv6 on Mac OS-X 10.6. >>> >>> It happens only from home, on wireless, when connected to a mac >>> aiport that does an automatic tunnel (teredo) to IPv6 backbone. >> >> Welcome to the great world of Teredo/6to4 where the endpoints/relays >> of the tunnel are anycasted in both IPv4 and IPv6 and thus can be >> quite difficult to debug, it can be done but requires quite a lot of >> vision in the network on both IPv4 and which will be generally near impossible. >> >>> There are IPv6 web site that I cannot browse until I lower the MTU >>> to >> 1400. >> >> Why don't you just do 1280 which is the default? >> >> Do also note that you have two levels of PMTU, the IPv6 one and the >> IPv4 one. If you configure your MTU of the tunnel incorrectly >> compared to the relay that you are using you will not see the PMTU's >> coming through either or they might not accept your large packets. >> >> Both MTUs can be broken due to folks filtering ICMP which is >> generally a bad thing to do. >> >> Greets, >> Jeroen > > > or - if you are tunneled more than once, you might be ultra conservative > and drop your MTU to 1220 - that should weed out the edge cases where even 1280 > is too large. 1220? I am pretty sure the minimal IPv6 MTU is 1280 and that below it fragmentation should be handled by the medium that transports packets smaller than that.... Can you enlighten me Bill? :) Greets, Jeroen From kyle.bader at gmail.com Tue Aug 24 13:42:51 2010 From: kyle.bader at gmail.com (Kyle Bader) Date: Tue, 24 Aug 2010 11:42:51 -0700 Subject: on network monitoring and security - req for monitoring tools In-Reply-To: <20100821215742.GF10007@subspacefield.org> References: <20100821215742.GF10007@subspacefield.org> Message-ID: > Hi, I'm putting together a book on security*, and wanted some expert > input onto network monitoring solutions... > > http://www.subspacefield.org/security/security_concepts.html > > Nagios, Net-SNMP, ifgraph, cacti, OpenNMS... any others? prelude, barnyard -- Kyle From David_Hankins at isc.org Tue Aug 24 15:02:49 2010 From: David_Hankins at isc.org (David W. Hankins) Date: Tue, 24 Aug 2010 13:02:49 -0700 Subject: Should routers send redirects by default? In-Reply-To: References: Message-ID: <20100824200249.GC4460@isc.org> On Fri, Aug 20, 2010 at 07:49:43PM -0400, Ricky Beam wrote: > I think it's almost universally disabled (by default) everywhere in IPv4 > purely for security (traffic interception.) In a perfectly run network, > redirects should never be necessary, so I'd think IPv6 should avoid going > down that road again. (support OPTIONAL, never enabled by default.) [It's > another insecure mistake IPv6 doesn't need to repeat.] I am not sure that is so much of an issue in IPv6. I know that in IPv4 3rd party ICMP redirects were quite common among the kiddies to knock each other off IRC, but ICMPv6 redirect reception in hosts has a number of saves and limitations that mean it should be far less, perhaps not an issue, provided your local network is secure and BCP 38 is in use. For example, an ICMPv6 implementation will not process a redirect from a router that is not the host's current next-hop for the target destination. Because this is a Link-Local Address, an off-link attacker has quite a problem guessing (and on-link attackers are a problem anyway). But I have a different memory of why we first started disabling redirects, back in the day. My memory is that hosts typically implement redirects with /32 routes, with no aggregation, installed upon receiving a redirect message. The ICMP message does not contain any TTL, and none was specified in RFC, so consequently over the lifetime of a device receiving redirects the routing table grows until every redirected destination is enumerated, or the system restarts. The ultimate size of the table reached can be quite large, beyond the scale typically engineered for in a host. Of course, that was back in the day when hosts were typically slower than the LANs they were connected to. So every additional host route installed increased per-packet forwarding overhead and decreased throughput considerably. Although ICMPv6 Redirect messages also lack a (router-advertised) TTL, an examination of [1] leads me to believe they will time out because they are implemented as part of the ND llinfo cache. A stale cache entry (the equivalent of a /128 route with link layer information) will ultimately be cleaned. If the destination is reused later, So it may be that the same conclusion does not hold, except in the unusual condition where a large number of redirects are required over a relatively short period of time (such as devices that have a large number of active sessions with hosts that its routers redirect; web servers, smtp systems...). [1] Li, Q., Jinmei, T., Shima, K., "IPv6 Core Protocols Implementation", October 2006. ISBN 13: 978-0-12-447751-3 ISBN 10: 0-12-447751-8 -- David W. Hankins BIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From David_Hankins at isc.org Tue Aug 24 15:25:01 2010 From: David_Hankins at isc.org (David W. Hankins) Date: Tue, 24 Aug 2010 13:25:01 -0700 Subject: Should routers send redirects by default? In-Reply-To: <20100822101201.37215017@opy.nosense.org> References: <3887672486120547ACEB7B3ACA6E46EC1B40E46E@exchange> <4C6FDEDF.2060400@brightok.net> <20100822101201.37215017@opy.nosense.org> Message-ID: <20100824202501.GD4460@isc.org> On Sun, Aug 22, 2010 at 10:12:01AM +0930, Mark Smith wrote: > o allow an IPv6 router to indicate to an end-node that the destination > it is attempting to send to is onlink. This situation occurs when the > router is more informed than the origin end-node about what prefixes > are onlink. > > This shouldn't happen very often either, as multiple onlink IPv6 routers > should be announcing the same Prefix Information Options in their RAs, > and therefore end-nodes should be fully informed as to all the onlink > prefixes. ICMPv6 redirects in this scenario would only occur during the > introduction of that new prefix information i.e. the time gap between > when the first and second onlink routers are configured with new prefix > information. It may be true the situations where redirects are required for this are few in number, but I think it is not true that the use of redirects is limited solely to the configuration gap between introducing a new prefix. In NBMA networks, it is said that the nodes will have IPv6 addresses with no covering advertised prefixes ("IPv6 Core Protocols Implementation", page 393, just spotted while reading today). Additionally, the typical use of /128 "role addresses" for services aliased onto lo0 mean the router has a /128 route for the role address to an on-link device, but a covering prefix advertisement would be both futile and inappropriate. I don't necessarily want to say that your conclusion is false, but rather that it seems to me there are more enumerations in the set. -- David W. Hankins BIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From David_Hankins at isc.org Tue Aug 24 15:31:48 2010 From: David_Hankins at isc.org (David W. Hankins) Date: Tue, 24 Aug 2010 13:31:48 -0700 Subject: Should routers send redirects by default? In-Reply-To: <20100824200249.GC4460@isc.org> References: <20100824200249.GC4460@isc.org> Message-ID: <20100824203147.GE4460@isc.org> On Tue, Aug 24, 2010 at 01:02:49PM -0700, David W. Hankins wrote: > will ultimately be cleaned. If the destination is reused later, > Ah, I forgot to complete this thought in editing. If packets are sent to the destination later (after a cache entry is expired) the host obviously starts over as if there was no redirection. In this way, changes in topology are ultimately discovered, whether the redirection changes or is no longer needed. -- David W. Hankins BIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From bill at herrin.us Tue Aug 24 15:32:17 2010 From: bill at herrin.us (William Herrin) Date: Tue, 24 Aug 2010 16:32:17 -0400 Subject: Should routers send redirects by default? In-Reply-To: References: Message-ID: On Fri, Aug 20, 2010 at 1:20 PM, Christopher Morrow wrote: > Polling a little bit here, there's an active discussion going on > 6man at ietf about whether or not v6 routers should: > ?o be required to implement ip redirect functions (icmpv6 redirect) > ?o be sending these by default Hi Chris, If you don't mind, I'd like to ask a similar question whose answers might be instructive for the question you asked: Forgetting all of the theoretical constructs for a moment, has anyone here personally encountered an operational scenario in which ICMP redirects solved a problem for you that you would otherwise have found difficult or intransigent? Without naming names, would you describe the scenario's details, explain the problem that would have existed absent redirects and explain how redirects solved it for you? Thanks, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From David_Hankins at isc.org Tue Aug 24 15:42:39 2010 From: David_Hankins at isc.org (David W. Hankins) Date: Tue, 24 Aug 2010 13:42:39 -0700 Subject: end-user ipv6 deployment and concerns about privacy In-Reply-To: <4C6C53A4.7060005@brightok.net> References: <4C6C53A4.7060005@brightok.net> Message-ID: <20100824204239.GG4460@isc.org> On Wed, Aug 18, 2010 at 04:41:56PM -0500, Jack Bates wrote: > prefixes to the unnumbered interface. If you use dslam level controls, > you'll most likely being using DHCPv6 TA addressing with PD on top of it, > which works well. Most of which can support quick static/dynamic > capabilities as it does with v4. This is surprising to me, can you comment on why DHCPv6 TA is being used in this scenario? -- David W. Hankins BIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Aug 24 17:11:32 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 25 Aug 2010 07:41:32 +0930 Subject: Should routers send redirects by default? In-Reply-To: <20100824202501.GD4460@isc.org> References: <3887672486120547ACEB7B3ACA6E46EC1B40E46E@exchange> <4C6FDEDF.2060400@brightok.net> <20100822101201.37215017@opy.nosense.org> <20100824202501.GD4460@isc.org> Message-ID: <20100825074132.739f3738@opy.nosense.org> On Tue, 24 Aug 2010 13:25:01 -0700 "David W. Hankins" wrote: > On Sun, Aug 22, 2010 at 10:12:01AM +0930, Mark Smith wrote: > > o allow an IPv6 router to indicate to an end-node that the destination > > it is attempting to send to is onlink. This situation occurs when the > > router is more informed than the origin end-node about what prefixes > > are onlink. > > > > This shouldn't happen very often either, as multiple onlink IPv6 routers > > should be announcing the same Prefix Information Options in their RAs, > > and therefore end-nodes should be fully informed as to all the onlink > > prefixes. ICMPv6 redirects in this scenario would only occur during the > > introduction of that new prefix information i.e. the time gap between > > when the first and second onlink routers are configured with new prefix > > information. > > It may be true the situations where redirects are required for this > are few in number, but I think it is not true that the use of > redirects is limited solely to the configuration gap between > introducing a new prefix. > > In NBMA networks, it is said that the nodes will have IPv6 addresses > with no covering advertised prefixes ("IPv6 Core Protocols > Implementation", page 393, just spotted while reading today). > > Additionally, the typical use of /128 "role addresses" for services > aliased onto lo0 mean the router has a /128 route for the role address > to an on-link device, but a covering prefix advertisement would be > both futile and inappropriate. > > I don't necessarily want to say that your conclusion is false, but > rather that it seems to me there are more enumerations in the set. > Before coming to any conclusions, we'd need to more strictly define what the NBMA topology is. Is it fully transitive i.e. all nodes can see all other nodes, and that the only property that makes it different from a conventional LAN is the absence of a broadcast/multicast capability? Or is there only partial visibility, such that end-nodes only have permanent visibility to a router i.e hub-and-spoke? In the latter case, another property is whether or not direct communcations paths can be set up between the spoke nodes on demand, such as in the case of Dynamic Multi-point VPNs. Whether ICMPv6 redirects are necessary or useful, or whether other somewhat similar mechanisms, such as Next Hop Resolution Protocol, are used in an NBMA subnet very much depends on the sort of connectivity it provides or can provide between the nodes on the subnet. Regards, Mark. From mjkelly at gmail.com Tue Aug 24 20:43:48 2010 From: mjkelly at gmail.com (Matt Kelly) Date: Tue, 24 Aug 2010 21:43:48 -0400 Subject: aol postmaster? Message-ID: <6A8216E7-2D61-4F75-A702-DC22AEBED253@gmail.com> If there is an AOL postmaster contact available, can you please contact me off list? Thanks. -- Matt From butche at butchevans.com Tue Aug 24 22:08:57 2010 From: butche at butchevans.com (Butch Evans) Date: Tue, 24 Aug 2010 22:08:57 -0500 Subject: Should routers send redirects by default? In-Reply-To: References: Message-ID: <1282705737.4812.44.camel@localhost.localdomain> On Fri, 2010-08-20 at 21:34 -0400, Brandon Ross wrote: > So far I have not heard a single compelling argument for how the > _transmittal_ of ICMP redirects can cause any signficicant harm to a > network other than what the other typical protocols that are enabled by > defualt (ping, can't fragement, etc) cause. I will make the statement: I agree with you here, Brandon. I asked the question: "What is the real security hole?" because I cannot see any real risk here for MOST of the networks that I am involved in. I can see the possibility of MITM attacks with ICMP redirects, but that is not the case for (as you point out) a router that issues an ICMP redirect. Also, it is not my experience that most host OS have this disabled either. That being the case, it seems to me that eliminating the behavior of transmitting these redirects in a router are of little value in protecting against MITM attacks. > The transmittal of ICMP redirects by a router _cannot_ be exploited to > create a man in the middle attack. I'd have to agree with this. More because my limited research (which includes responses I've seen on this thread) seems to indicate that this is the case. > Before anyone responds to that statement, please read it very carefully. > This statement does not comment on whether a host or router should be > configured to _receive_ an ICMP redirect and act on it, that clearly can > be used to create a MITM attack. If a network has a single router, then wouldn't this also create a DOS situation under the right circumstances? I mean, if it can create MITM, it would HAVE to also create DOS possibilities. What is the distance of a route learned from an ICMP redirect? If it is greater than 0 (connected route) or 1 (static route) but less than the cost of other dynamically learned routes, then I can see the why this may be a problem for a router to respond to an ICMP redirect packet. -- ******************************************************************** * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/ * Network Engineering * * http://store.wispgear.net/ * Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * ******************************************************************** From lists at xodus.org Tue Aug 24 22:53:51 2010 From: lists at xodus.org (Marc Powell) Date: Tue, 24 Aug 2010 22:53:51 -0500 Subject: aol postmaster? In-Reply-To: <6A8216E7-2D61-4F75-A702-DC22AEBED253@gmail.com> References: <6A8216E7-2D61-4F75-A702-DC22AEBED253@gmail.com> Message-ID: <1E19A309-96D9-466C-AE0E-E40B8A749334@xodus.org> On Aug 24, 2010, at 8:43 PM, Matt Kelly wrote: > If there is an AOL postmaster contact available, can you please contact me off list? Have you tried http://postmaster.aol.com? The vast majority of the AOL Postmaster team was laid off back in January (and will be missed), so YMMV these days. -- Marc From christopher.morrow at gmail.com Wed Aug 25 00:18:15 2010 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 25 Aug 2010 01:18:15 -0400 Subject: Should routers send redirects by default? In-Reply-To: References: Message-ID: On Tue, Aug 24, 2010 at 4:32 PM, William Herrin wrote: > On Fri, Aug 20, 2010 at 1:20 PM, Christopher Morrow > wrote: >> Polling a little bit here, there's an active discussion going on >> 6man at ietf about whether or not v6 routers should: >> ?o be required to implement ip redirect functions (icmpv6 redirect) >> ?o be sending these by default > > Hi Chris, > > If you don't mind, I'd like to ask a similar question whose answers > might be instructive for the question you asked: sure :) (other folks should also chime in, or I thought that was the spirit of your question...) > > Forgetting all of the theoretical constructs for a moment, has anyone > here personally encountered an operational scenario in which ICMP > redirects solved a problem for you that you would otherwise have found > difficult or intransigent? Without naming names, would you describe > the scenario's details, explain the problem that would have existed > absent redirects and explain how redirects solved it for you? I've never had redirects solve a problem for me. From stuart at tech.org Wed Aug 25 01:03:31 2010 From: stuart at tech.org (Stephen Stuart) Date: Wed, 25 Aug 2010 06:03:31 +0000 Subject: Should routers send redirects by default? In-Reply-To: Your message of "Wed, 25 Aug 2010 01:18:15 -0400." Message-ID: <201008250603.o7P63Wt8074184@nb.tech.org> > > Forgetting all of the theoretical constructs for a moment, has anyone > > here personally encountered an operational scenario in which ICMP > > redirects solved a problem for you that you would otherwise have found > > difficult or intransigent? Without naming names, would you describe > > the scenario's details, explain the problem that would have existed > > absent redirects and explain how redirects solved it for you? > > I've never had redirects solve a problem for me. Once upon a time, gatekeeper.dec.com was a MIPS Ultrix box connected to a LAN segment (the IP prefix for that LAN segment was 16.1.0.0/24, and gatekeeper used to be 16.1.0.2). Also connected to the LAN segment were routers belonging to AlterNet (or maybe it was UUnet by then) and BARRnet. gatekeeper's static default route was pointed at the BARRnet router. The BARRnet and AlterNet routers exchanged routes out of sight of the LAN segment in question. When BARRnet knew that the destination of a packet would be the AlterNet router, it would issue an ICMP redirect to gatekeeper (or any of the other hosts that pointed default at the BARRnet router). The redirects let us make pretty efficient use of the interfaces toward both from the collection of gatekeeper and uucp-gw{1,2} and the NNTP relays and such. Had we shovelled all the traffic at BARRnet, all the time, we wouldn't have stretched our DELNIs as far as we did. That was 1994 - and in fairly short order (within two years) we went from DELNIs to DECswitch 900s, MIPS Ultrix to Digital UNIX (or whatever it was called) on AlphaStations (so many AlphaStations), and ICMP redirects to the private IX that became PAIX. Stephen From swmike at swm.pp.se Wed Aug 25 01:12:57 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 25 Aug 2010 08:12:57 +0200 (CEST) Subject: Should routers send redirects by default? In-Reply-To: <201008250603.o7P63Wt8074184@nb.tech.org> References: <201008250603.o7P63Wt8074184@nb.tech.org> Message-ID: On Wed, 25 Aug 2010, Stephen Stuart wrote: > Once upon a time I think the question is what sensible defaults should be. In my environment we turn off proxy-arp and redirects, and it is my firm belief that this is actually what should be the default. In my opinion: A host SHOULD support listening to redirects and MUST have a knob to turn off this listening if implemented. A router MUST have redirects off as default but MUST support a knob turning them on and when sending a redirect it MUST forward the packet that generated the redirect. I know most of the above is completely against current standards, but for me these are more in tune with todays reality in networking as I see them. -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Wed Aug 25 05:01:50 2010 From: randy at psg.com (Randy Bush) Date: Wed, 25 Aug 2010 19:01:50 +0900 Subject: Should routers send redirects by default? In-Reply-To: References: <201008250603.o7P63Wt8074184@nb.tech.org> Message-ID: > A host SHOULD support listening to redirects and MUST have a knob to > turn off this listening if implemented. A router MUST have redirects > off as default but MUST support a knob turning them on and when > sending a redirect it MUST forward the packet that generated the > redirect. wfm randy From warren at kumari.net Wed Aug 25 10:01:23 2010 From: warren at kumari.net (Warren Kumari) Date: Wed, 25 Aug 2010 11:01:23 -0400 Subject: Should routers send redirects by default? In-Reply-To: References: Message-ID: On Aug 24, 2010, at 4:32 PM, William Herrin wrote: > On Fri, Aug 20, 2010 at 1:20 PM, Christopher Morrow > wrote: >> Polling a little bit here, there's an active discussion going on >> 6man at ietf about whether or not v6 routers should: >> o be required to implement ip redirect functions (icmpv6 redirect) >> o be sending these by default > > Hi Chris, > > If you don't mind, I'd like to ask a similar question whose answers > might be instructive for the question you asked: > > > Forgetting all of the theoretical constructs for a moment, has anyone > here personally encountered an operational scenario in which ICMP > redirects solved a problem for you that you would otherwise have found > difficult or intransigent? Without naming names, would you describe > the scenario's details, explain the problem that would have existed > absent redirects and explain how redirects solved it for you? I have, but it was a long long time ago (~1997), and it was a stupid problem.... We had a bunch of hosts on a LAN - their default GW was an AGS+ connected to provider X. Also on the same network was a Bay Networks BCN (AFAIR) connected to provider Y. In general most flows were relatively long lived (some NNTP, some FTP.. oh, and Quake!). There was no reasonable way to inform the hosts if provider X went away. The AGS+ would also run a bit too hot if it had to accept all of the traffic and then punt the relevant parts over to the BCN.... Unrelated, but this network also did static IPs for dial customers (who could dial into one of ~lots of RAS boxes) -- this meant that the RAS boxen has to inject /32s into OSPF for each customer -- this meant that if certain routers (like the AGS+) bounced there was enough churn that other routers would fall over (the BCN would hit some watchdog and fall over, and if you tried to bring it up into a network that was already converged it would run out of RAM and happily drop into some debugger console). Fun times... W > > Thanks, > Bill Herrin > > > > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -- She'd even given herself a middle initial - X - which stood for "someone who has a cool and exciting middle name". -- (Terry Pratchett, Maskerade) From randy at psg.com Wed Aug 25 11:47:29 2010 From: randy at psg.com (Randy Bush) Date: Thu, 26 Aug 2010 01:47:29 +0900 Subject: how damp are your routes Message-ID: a little contest here. what is the largest or most complex (measured in the number of parms) route flap damping confuration in actual use? send yours to me privately, and i will announce the winner in a few days (with their consent), and maybe show the config (with their consent). thanks for playing. and please, let's not get into the [de]merits of using rfd, how you should configure it, etc. this is research, and it is really about rfd parameter config complexity. randy From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Aug 25 17:05:53 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 26 Aug 2010 07:35:53 +0930 Subject: Should routers send redirects by default? In-Reply-To: References: Message-ID: <20100826073553.79838e3b@opy.nosense.org> On Wed, 25 Aug 2010 01:18:15 -0400 Christopher Morrow wrote: > On Tue, Aug 24, 2010 at 4:32 PM, William Herrin wrote: > > On Fri, Aug 20, 2010 at 1:20 PM, Christopher Morrow > > wrote: > >> Polling a little bit here, there's an active discussion going on > >> 6man at ietf about whether or not v6 routers should: > >> ?o be required to implement ip redirect functions (icmpv6 redirect) > >> ?o be sending these by default > > > > Hi Chris, > > > > If you don't mind, I'd like to ask a similar question whose answers > > might be instructive for the question you asked: > > sure :) (other folks should also chime in, or I thought that was the > spirit of your question...) > > > > > Forgetting all of the theoretical constructs for a moment, has anyone > > here personally encountered an operational scenario in which ICMP > > redirects solved a problem for you that you would otherwise have found > > difficult or intransigent? Without naming names, would you describe > > the scenario's details, explain the problem that would have existed > > absent redirects and explain how redirects solved it for you? > > I've never had redirects solve a problem for me. > So how do you know? If redirects are enabled by default, then they may have fixed a problem for you that you didn't know existed and never realised existed. When your packets get there successfully you don't go and investigate why. You only troubleshoot failure, not success. I think the only way to know an absolute answer would be to have witnessed this sequence of events - have an environment where redirects are switched off - suffer from a problem that redirects are designed to solve - switch redirects on and have the problem not disappear Of course, the problem not disappearing when redirects are enabled might also mean a misdiagnosis of what the problem really is. Regards, Mark. From mysidia at gmail.com Wed Aug 25 20:08:32 2010 From: mysidia at gmail.com (James Hess) Date: Wed, 25 Aug 2010 20:08:32 -0500 Subject: Should routers send redirects by default? In-Reply-To: <1282338499.29483.297.camel@localhost.localdomain> References: <1282334166.29483.291.camel@localhost.localdomain> <1282338499.29483.297.camel@localhost.localdomain> Message-ID: On Fri, Aug 20, 2010 at 4:08 PM, Butch Evans wrote: I would suggest the recommendation be that ICMP Redirects, proxy ARP, directed broadcast, source routing, and acceptance/usage of all fancy/surprising features should be off by default. Where "surprising" is defined as the sort of thing that is nonessential, has questionable benefits, can cause problems, and that people will forget to turn off. Redirects seem to fall into the non-essential with questionable benefits (in most cases) category. > For most of the networks that I manage (or help to manage), I can see no reason why this would be an issue. If none of your hosts accept redirects, then it is not really apparent that redirects are harmful. If some of your hosts accept redirects, then redirects may be capable of causing headaches. You might have a gateway using a protocol such as VRRP, with redundancy for the default gateway address of subnet $X. And you have other routers for other subnets which just happen to have an extra ip on subnet $X. But the other subnets' routers' IPs on subnet $X are not redundant, and the packets are supposed take a secondary route if that "second hop" router goes down, since the $X default gateway will dynamically figure this out in a couple of seconds. Then the ICMP redirect becomes a redirect to /dev/null. And almost random sets of hosts will lose communications with each other for the redirect timeout duration, if they are not smart enough to implement methods of detecting the redirect is now bad. Sending ICMP redirects is not a huge security risk. ACCEPTING redirects is a larger risk. The redirects can be used by an adversary that acts as a "router", to extend the lifetime of or increase the effectiveness of an ARP hijacking or switch CAM flooding tactic, to continue to steal traffic from a host, and ensure they get every packet. The adversary with an IP on the same subnet as target hosts can use forged ICMP redirects, in order to cause hosts to misdirect packets sent to certain IPs, so that the attacker's local subnet IP address is the first hop in the path, instead of the hosts' default gateway. -- -J From butche at butchevans.com Wed Aug 25 21:14:37 2010 From: butche at butchevans.com (Butch Evans) Date: Wed, 25 Aug 2010 21:14:37 -0500 Subject: Should routers send redirects by default? In-Reply-To: References: <1282334166.29483.291.camel@localhost.localdomain> <1282338499.29483.297.camel@localhost.localdomain> Message-ID: <1282788877.4812.105.camel@localhost.localdomain> On Wed, 2010-08-25 at 20:08 -0500, James Hess wrote: > On Fri, Aug 20, 2010 at 4:08 PM, Butch Evans wrote: > I would suggest the recommendation be that ICMP Redirects, proxy ARP, > directed broadcast, source routing, and acceptance/usage > of all fancy/surprising features should be off by default. Off by default, but be supported is my recommendation. I am assuming that the function in IPv6 is the same (or similar) to that of IPv4. There was another post in this thread (I can't recall who it was that posted it) that indicated there was more to the redirect in v6 than for v4, but I am not yet very familiar with v6. > "surprising" is defined as the sort of thing that is nonessential, > has questionable benefits, Perhaps "questionable" to you, but I have had specific need to have ICMP redirect for two specific networks. In those networks it WAS essential and had a very specific, measurable benefit. > Redirects seem to fall into the non-essential with questionable > benefits (in most cases) category. You are being a little presumptuous here. Perhaps for "most cases", I'd agree that they are non-essential, but there are cases where it is desirable and lack of support (as in the PIX) makes things very difficult at times. > If none of your hosts accept redirects, then it is not really > apparent that redirects are harmful. If some of your hosts accept > redirects, then redirects may be > capable of causing headaches. In one case where I needed ICMP redirect to work, I had 2 routers on the network (one was a Linux device and the other was a PIX). Each of these were terminating VPNs from various sources. There were several (about 90) hosts on the LAN segment. Each of these hosts had the PIX as their default route. It would have been a very simple matter to add routes to the PIX and have it redirect the traffic destined for the remote networks behind the Linux device. The PIX, however, does not support ICMP redirects AT ALL. I'm all for securing a network segment, but failure to support a valid function of ICMP is one reason I have never purchased a PIX...and never will. I can see your point that it should be off by default. But to be off and not even supported is just wrong, IMHO. -- ******************************************************************** * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/ * Network Engineering * * http://store.wispgear.net/ * Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * ******************************************************************** From mglt.biz at gmail.com Thu Aug 26 05:26:25 2010 From: mglt.biz at gmail.com (Daniel Migault) Date: Thu, 26 Aug 2010 12:26:25 +0200 Subject: IP characteristics for 3G and WiFi links Message-ID: Hi, We are testing protocols on our lab platform and we would like to simulate communication 2 types of communication : - From terminals to service platform using a 3G (HSPA / HSPA+) Access connection - From terminal to service platform using a WiFi Access connection We are using dummyNet to simulate the links so we are interested in IP characteristics layers for Packet loss Rate, bandwidth and latency. Values depends on multiple factors, but we would like to know what mean values are considered when services are deployed. Currently we are considering the following values. Packet Lost Rate for L2 seems 7% for Wifi and 5% for 3G. We are wondering how L3 is affected? Parameter | Wifi (802.11a/g) | 3G (HSDPA) Latency 100 ms 60 ms Bandwidth 5 Mbps 3 Mbps Packet Lost Rate XXX XXX Any comment links will be appreciated. Regards, Daniel -- Daniel Migault Orange Labs / Security Lab +33 (0) 1 45 29 60 52 +33 (0) 6 70 72 69 58 From lasse at sdu.dk Thu Aug 26 07:55:06 2010 From: lasse at sdu.dk (Lasse Birnbaum Jensen) Date: Thu, 26 Aug 2010 14:55:06 +0200 Subject: Enterprise Edge firewalls Message-ID: <3BC2E98A-0FC0-4340-8355-A8B2C14F1CFC@sdu.dk> Hi all We currently run Juniper NetScreen 5200 firewall and are looking for replacements, since these are doomed by Juniper and they are ready to be replaced. Their replacement is the SRX series, but since we need buy some replacements we feel that the rest of the market is worth looking at. Could any of you out there share experiences with other brand, specific models. Our setup will be implemented as described in the Cisco SAFE reference guide, with dedicated border routers and firewall behind those. The functional requirements we have is filtering and nat, ids/ips is a nice-to-have built-in feature. Stability and performance are off course also a demand. We currently have 10G ethernet both as peerings and core network. Contact me off the list if you want to remain anonymous. Thanks in advance Best regards Lasse Birnbaum Jensen Network Administrator University of Southern Denmark Denmark Email: lasse at sdu.dk Phone: +45 6550 2873 From sethm at rollernet.us Thu Aug 26 11:20:53 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 26 Aug 2010 09:20:53 -0700 Subject: IP characteristics for 3G and WiFi links In-Reply-To: References: Message-ID: <4C769465.6060808@rollernet.us> On 8/26/10 3:26 AM, Daniel Migault wrote: > > Currently we are considering the following values. Packet Lost Rate for L2 > seems 7% for Wifi and 5% for 3G. We are wondering how L3 is affected? > TCP retransmits. UDP does not. ~Seth From richard.barnes at gmail.com Thu Aug 26 11:32:47 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Thu, 26 Aug 2010 12:32:47 -0400 Subject: IP characteristics for 3G and WiFi links In-Reply-To: References: Message-ID: On Thu, Aug 26, 2010 at 6:26 AM, Daniel Migault wrote: > Hi, > > We are testing protocols on our lab platform and we would like to simulate > communication 2 types of communication : > ? - From terminals to service platform using a 3G (HSPA / HSPA+) Access > connection > ? - From terminal to service platform using a WiFi Access connection > > We are using dummyNet to simulate the links so we are interested ?in IP > characteristics layers for Packet loss Rate, bandwidth and latency. Values > depends on multiple factors, but we would like to know what mean values are > considered when services are deployed. > > Currently we are considering the following values. Packet Lost Rate for L2 > seems 7% for Wifi and 5% for 3G. We are wondering how L3 is affected? > > > Parameter ? ? ? ? ? | Wifi (802.11a/g) | 3G (HSDPA) > Latency ? ? ? ? ? ? ? ?100 ms ? ? ? ? ? ? ? 60 ms > Bandwidth ? ? ? ? ? ? 5 Mbps ? ? ? ? ? ? ? 3 Mbps > Packet Lost Rate ? XXX ? ? ? ? ? ? ? ? ? XXX > > > Any comment links will be appreciated. > > Regards, > Daniel > -- > Daniel Migault > Orange Labs / Security Lab > +33 (0) 1 45 29 60 52 > +33 (0) 6 70 72 69 58 > From dmm at 1-4-5.net Wed Aug 25 09:22:31 2010 From: dmm at 1-4-5.net (David Meyer) Date: Wed, 25 Aug 2010 07:22:31 -0700 Subject: [NANOG-announce] PC Nominations are open! Message-ID: Folks, Its time to nominate those folks who you think will help the NANOG program committee continue to deliver great content to the NANOG community. Eligibility is outlined at http://nanog.org/governance/elections/2010elections. Please nominate those folks who you think can add perspective and energy to the PC, and remember that you can self-nominate. Thanks, Dave -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From matthew at matthew.at Thu Aug 26 12:54:50 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 26 Aug 2010 10:54:50 -0700 Subject: IP characteristics for 3G and WiFi links In-Reply-To: References: Message-ID: <4C76AA6A.6010207@matthew.at> On 8/26/2010 3:26 AM, Daniel Migault wrote: > Currently we are considering the following values. Packet Lost Rate for L2 > seems 7% for Wifi and 5% for 3G. We are wondering how L3 is affected? WiFi (802.11) uses ARQ to emulate a layer 2 network that has much much lower loss than this (otherwise TCP really wouldn't work over it). I suspect 3G is similar. So both these numbers are highly suspect. Matthew Kaufman From swmike at swm.pp.se Thu Aug 26 14:37:27 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 26 Aug 2010 21:37:27 +0200 (CEST) Subject: IP characteristics for 3G and WiFi links In-Reply-To: References: Message-ID: On Thu, 26 Aug 2010, Daniel Migault wrote: > Parameter | Wifi (802.11a/g) | 3G (HSDPA) > Latency 100 ms 60 ms > Bandwidth 5 Mbps 3 Mbps > Packet Lost Rate XXX XXX So, if you want to emulate HSPA you need to understand how it works. If you go from "idle" (30 seconds of not sending data) you will see 1-2 seconds of jitter as radio resources are allocated and brought "online", until you can send packets. There are multiple states, either you have HS resources, or you have regular 384k channel, or you basically have "none". All of these have different characteristics. Packet loss on 3G is really low as it does re-sends itself, normally you'd see muc less than 1% of packet loss, usually a lot lower than that. There is quite a lot of resending and assuring packets are not lost on multiple layers beneath IP in those networks. -- Mikael Abrahamsson email: swmike at swm.pp.se From owen at delong.com Thu Aug 26 15:25:50 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 26 Aug 2010 13:25:50 -0700 Subject: IP characteristics for 3G and WiFi links In-Reply-To: References: Message-ID: <69B97D53-6973-4304-9D0B-4222412FC4CF@delong.com> I think you have your latency numbers backwards. In my experience, HSDPA has higher RTT than WiFi. Why would you limit your Wifi to A/G? If you're using 5Ghz (A), much better to go to N than A. N has slight advantages over G in the 2.4Ghz realm. Your stated packet loss rates are obscenely high and loss at those rates would severely degrade user experience. Loss over 1% is enough to cause significant slow-down in TCP short-lived or interactive flows and 2% is more than enough to effect even longer continuous data flows. I have not done comparisons of average loss rates between WiFi and 3G services where the loss rates were so high because either one would be basically unusable until the packet loss was reduced. Owen On Aug 26, 2010, at 9:32 AM, Richard Barnes wrote: > On Thu, Aug 26, 2010 at 6:26 AM, Daniel Migault wrote: >> Hi, >> >> We are testing protocols on our lab platform and we would like to simulate >> communication 2 types of communication : >> - From terminals to service platform using a 3G (HSPA / HSPA+) Access >> connection >> - From terminal to service platform using a WiFi Access connection >> >> We are using dummyNet to simulate the links so we are interested in IP >> characteristics layers for Packet loss Rate, bandwidth and latency. Values >> depends on multiple factors, but we would like to know what mean values are >> considered when services are deployed. >> >> Currently we are considering the following values. Packet Lost Rate for L2 >> seems 7% for Wifi and 5% for 3G. We are wondering how L3 is affected? >> >> >> Parameter | Wifi (802.11a/g) | 3G (HSDPA) >> Latency 100 ms 60 ms >> Bandwidth 5 Mbps 3 Mbps >> Packet Lost Rate XXX XXX >> >> >> Any comment links will be appreciated. >> >> Regards, >> Daniel >> -- >> Daniel Migault >> Orange Labs / Security Lab >> +33 (0) 1 45 29 60 52 >> +33 (0) 6 70 72 69 58 >> From sethm at rollernet.us Thu Aug 26 15:33:22 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 26 Aug 2010 13:33:22 -0700 Subject: IP characteristics for 3G and WiFi links In-Reply-To: <4C769465.6060808@rollernet.us> References: <4C769465.6060808@rollernet.us> Message-ID: <4C76CF92.2020404@rollernet.us> On 8/26/2010 09:20, Seth Mattinen wrote: > On 8/26/10 3:26 AM, Daniel Migault wrote: >> >> Currently we are considering the following values. Packet Lost Rate for L2 >> seems 7% for Wifi and 5% for 3G. We are wondering how L3 is affected? >> > > TCP retransmits. UDP does not. > Nevermind my response; I've been outside in the sun too much pulling cables through vaults. =P ~Seth From bmanning at vacation.karoshi.com Thu Aug 26 17:36:26 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 26 Aug 2010 22:36:26 +0000 Subject: sort by agony Message-ID: <20100826223626.GA7557@vacation.karoshi.com.> sorry for the off topic post - but since a few of us travel about some... http://www.hipmunk.com/ --bill From bill at herrin.us Thu Aug 26 18:04:48 2010 From: bill at herrin.us (William Herrin) Date: Thu, 26 Aug 2010 19:04:48 -0400 Subject: sort by agony In-Reply-To: <20100826223626.GA7557@vacation.karoshi.com.> References: <20100826223626.GA7557@vacation.karoshi.com.> Message-ID: On Thu, Aug 26, 2010 at 6:36 PM, wrote: > sorry for the off topic post - but since a few of us travel about some... > http://www.hipmunk.com/ How do they quantify agony? Also it's not clear if the sort is ascending or descending... -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From wschultz at bsdboy.com Thu Aug 26 18:05:33 2010 From: wschultz at bsdboy.com (Wil Schultz) Date: Thu, 26 Aug 2010 16:05:33 -0700 Subject: Idea's for donating/recycling server hardware [Off-Topic] Message-ID: <8FA45C0E-7798-4D6F-A317-BCA538827803@bsdboy.com> I apologize for being somewhat off topic... I've got a fair amount of SPARC hardware (v210 through v490) and 32bit HP DL360-380 hardware that I'm looking for creative ways to dispose of or to donate. It seems like a waste to send it to metal scrap, if anyone has a more creative way of disposal please contact me off list. Local to San Francisco. *disclaimer, contributions cannot go to religious or political organizations per corp policy* Thanks! -wil From ailiop at lsu.edu Thu Aug 26 20:24:43 2010 From: ailiop at lsu.edu (Anthony Iliopoulos) Date: Thu, 26 Aug 2010 20:24:43 -0500 Subject: Idea's for donating/recycling server hardware [Off-Topic] In-Reply-To: <8FA45C0E-7798-4D6F-A317-BCA538827803@bsdboy.com> References: <8FA45C0E-7798-4D6F-A317-BCA538827803@bsdboy.com> Message-ID: <20100827012443.GC10164@lsu.edu> On Thu, Aug 26, 2010 at 04:05:33PM -0700, Wil Schultz wrote: > I apologize for being somewhat off topic... > > I've got a fair amount of SPARC hardware (v210 through v490) and 32bit HP DL360-380 hardware that I'm looking for creative ways to dispose of or to donate. > > It seems like a waste to send it to metal scrap, if anyone has a more creative way of disposal please contact me off list. Local to San Francisco. Wil, It's certainly a shame to trash these. This is very appealing platform for some linux/bsd internals devel and testing. I'm not local to SF, but if you're willing to package & ship a couple of them, I'll cover the expenses. This will be for non-profit/educational development. Let me know! Regards, Anthony From ops.lists at gmail.com Thu Aug 26 21:03:11 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 27 Aug 2010 07:33:11 +0530 Subject: Idea's for donating/recycling server hardware [Off-Topic] In-Reply-To: <8FA45C0E-7798-4D6F-A317-BCA538827803@bsdboy.com> References: <8FA45C0E-7798-4D6F-A317-BCA538827803@bsdboy.com> Message-ID: There's also http://www.nsrc.org at UOregon - as good a home as any for any gear you want to trash. On Fri, Aug 27, 2010 at 4:35 AM, Wil Schultz wrote: > I apologize for being somewhat off topic... > > I've got a fair amount of SPARC hardware (v210 through v490) and 32bit HP DL360-380 hardware that I'm looking for creative ways to dispose of or to donate. > > It seems like a waste to send it to metal scrap, if anyone has a more creative way of disposal please contact me off list. Local to San Francisco. > > *disclaimer, contributions cannot go to religious or political organizations per corp policy* > > Thanks! > > -wil > -- Suresh Ramasubramanian (ops.lists at gmail.com) From nanogf at spoofer.com Thu Aug 26 23:18:58 2010 From: nanogf at spoofer.com (nanogf .) Date: Thu, 26 Aug 2010 21:18:58 -0700 Subject: PacketShader Message-ID: <20100826211858.8C23A969@resin13.mta.everyone.net> --- Joel Jaeggli wrote: > What it really comes down to is packets per watt or packets per > dollar, if it's cheaper to do it this way then people will, if not > BFD. http://docs.google.com/viewer?url=http://ic.ese.upenn.edu/pdf/spice_fpl2009.pdf Performance Comparison of Single-Precision SPICE Model-Evaluation on FPGA, GPU, Cell, and multi-core Processors _____________________________________________________________ Get your own *free* email address like this one from www.OwnEmail.com From jcdill.lists at gmail.com Fri Aug 27 00:46:23 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 26 Aug 2010 22:46:23 -0700 Subject: sort by agony In-Reply-To: References: <20100826223626.GA7557@vacation.karoshi.com.> Message-ID: <4C77512F.5070509@gmail.com> William Herrin wrote: > On Thu, Aug 26, 2010 at 6:36 PM, wrote: > >> sorry for the off topic post - but since a few of us travel about some... >> http://www.hipmunk.com/ >> Cool link! I'm actually shopping for a flight tonight, this has already come in quite handy. > > How do they quantify agony? Also it's not clear if the sort is > ascending or descending... http://www.hipmunk.com/faq What is Agony, and why would I want to sort by it? Agony is our way of sorting flights to take into account price, duration, and number of stops. There's more to a flight than its price, so we provide this sort to give you better all-around results. From mike at m5computersecurity.com Fri Aug 27 02:25:43 2010 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Fri, 27 Aug 2010 00:25:43 -0700 Subject: sort by agony In-Reply-To: <4C77512F.5070509@gmail.com> References: <20100826223626.GA7557@vacation.karoshi.com.> <4C77512F.5070509@gmail.com> Message-ID: <1282893943.8746.851.camel@mike-desktop> On Thu, 2010-08-26 at 22:46 -0700, JC Dill wrote: > William Herrin wrote: > > On Thu, Aug 26, 2010 at 6:36 PM, wrote: > > > >> sorry for the off topic post - but since a few of us travel about some... > >> http://www.hipmunk.com/ > >> > > Cool link! I'm actually shopping for a flight tonight, this has already > come in quite handy. > > > > > How do they quantify agony? Also it's not clear if the sort is > > ascending or descending... > > http://www.hipmunk.com/faq > > What is Agony, and why would I want to sort by it? > Agony is our way of sorting flights to take into account price, > duration, and number of stops. There's more to a flight than its price, > so we provide this sort to give you better all-around results. > Very cool indeed. I'd think that to some the travel time would be weighed much more heavily than the price of the ticket. I hate to fly for work (having been injured in a plane crash) and a bit nervous anyway, but if I am flying for work then then a few hundred bucks is trivial compared to what is riding on the deal. It might be neat of you could adjust the weight of the components of "agony". For kicks, I looked at the most agonizing trip options... I chose a trip from San Diego to New York City... the worst were: 1) Tijuana to Mexico City, 16hr hour layover, then to Newark NJ and cost over $1k. 2) Tijuana to Guadalajara for an 8hr layover, then to Atlanta for a 1.5hr layover to New York LGA. Holy crappy flights Batman! -- ************************************************************ Michael J. McCafferty Principal M5 Hosting http://www.m5hosting.com You can have your own custom Dedicated Server up and running today ! RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more ************************************************************ From callum.finlayson at gmail.com Fri Aug 27 03:33:26 2010 From: callum.finlayson at gmail.com (Callum Finlayson) Date: Fri, 27 Aug 2010 09:33:26 +0100 Subject: sort by agony In-Reply-To: <1282893943.8746.851.camel@mike-desktop> References: <20100826223626.GA7557@vacation.karoshi.com.> <4C77512F.5070509@gmail.com> <1282893943.8746.851.camel@mike-desktop> Message-ID: On Fri, Aug 27, 2010 at 8:25 AM, Michael J McCafferty wrote: > For kicks, I looked at the most agonizing trip options... I chose a trip > from San Diego to New York City... the worst were: > > 1) Tijuana to Mexico City, 16hr hour layover, then to Newark NJ and cost > over $1k. > > 2) Tijuana to Guadalajara for an 8hr layover, then to Atlanta for a > 1.5hr layover to New York LGA. Made all the more agonizing when you arrive in NY and customs express interest in your decission to stop over south of the border for a couple of hours. As others have said -- agony's a nice idea, but the real value gets added when you can weight the elements according to your personal preferences (and the site can then capture how people choose to weight various inconveniences in order to (i) improve their own algorithms, and (ii) sell on to other interested parties). C From cian.brennan at redbrick.dcu.ie Fri Aug 27 03:56:59 2010 From: cian.brennan at redbrick.dcu.ie (Cian Brennan) Date: Fri, 27 Aug 2010 09:56:59 +0100 Subject: Idea's for donating/recycling server hardware [Off-Topic] In-Reply-To: <8FA45C0E-7798-4D6F-A317-BCA538827803@bsdboy.com> References: <8FA45C0E-7798-4D6F-A317-BCA538827803@bsdboy.com> Message-ID: <20100827085659.GA3675@minerva.redbrick.dcu.ie> On Thu, Aug 26, 2010 at 04:05:33PM -0700, Wil Schultz wrote: > I apologize for being somewhat off topic... > > I've got a fair amount of SPARC hardware (v210 through v490) and 32bit HP DL360-380 hardware that I'm looking for creative ways to dispose of or to donate. > > It seems like a waste to send it to metal scrap, if anyone has a more creative way of disposal please contact me off list. Local to San Francisco. > > *disclaimer, contributions cannot go to religious or political organizations per corp policy* > > Thanks! > It may not be as widespread in the US, but certainly over here, the average university will have some kind of (computer|networking) society who'd generally bite your arm off for old gear. > -wil > From niko.thome at 1und1.de Fri Aug 27 03:58:52 2010 From: niko.thome at 1und1.de (Niko Thome) Date: Fri, 27 Aug 2010 10:58:52 +0200 Subject: Fwd: Re: [oss-security] CVE Request -- Quagga (bgpd) [two ids] -- 1, Stack buffer overflow by processing crafted Refresh-Route msgs 2, NULL ptr deref by parsing certain AS paths by BGP update request Message-ID: <4C777E4C.1090700@1und1.de> for those who missed it... kind regards, niko -------- Original Message -------- Subject: Re: [oss-security] CVE Request -- Quagga (bgpd) [two ids] -- 1, Stack buffer overflow by processing crafted Refresh-Route msgs 2, NULL ptr deref by parsing certain AS paths by BGP update request Date: Wed, 25 Aug 2010 10:21:59 -0400 From: Josh Bressers Reply-To: oss-security at lists.openwall.com To: oss-security at lists.openwall.com CC: CERT-FI Vulnerability Co-ordination , Chris Hall , Denis Ovsienko , "Steven M. Christey" ----- "Jan Lieskovsky" wrote: > Hi Steve, vendors, > > Quagga upstream has released latest vQuagga 0.99.17 version, > addressing two security flaws: > > A, Stack buffer overflow by processing certain Route-Refresh messages > > A stack buffer overflow flaw was found in the way Quagga's bgpd daemon > processed Route-Refresh messages. A configured Border Gateway Protocol > (BGP) peer could send a Route-Refresh message with specially-crafted > Outbound Route Filtering (ORF) record, which would cause the master > BGP daemon (bgpd) to crash or, possibly, execute arbitrary code with > the privileges of the user running bgpd. > > Upstream changeset: > [1] > http://code.quagga.net/?p=quagga.git;a=commit;h=d64379e8f3c0636df53ed08d5b2f1946cfedd0e3 > > References: > [2] https://bugzilla.redhat.com/show_bug.cgi?id=626783 > [3] http://www.quagga.net/news2.php?y=2010&m=8&d=19#id1282241100 Use CVE-2010-2948 for this one. > > B, DoS (crash) while processing certain BGP update AS path messages > > A NULL pointer dereference flaw was found in the way Quagga's bgpd > daemon parsed paths of autonomous systems (AS). A configured BGP peer > could send a BGP update AS path request with unknown AS type, which > could lead to denial of service (bgpd daemon crash). > > Upstream changeset: > [4] > http://code.quagga.net/?p=quagga.git;a=commit;h=cddb8112b80fa9867156c637d63e6e79eeac67bb > > References: > [5] https://bugzilla.redhat.com/show_bug.cgi?id=626795 > [6] http://www.quagga.net/news2.php?y=2010&m=8&d=19#id1282241100 > Use CVE-2010-2949 for this one. Thanks. -- JB From adrian at changeover.za.net Fri Aug 27 04:09:41 2010 From: adrian at changeover.za.net (Adrian Moisey) Date: Fri, 27 Aug 2010 11:09:41 +0200 Subject: Idea's for donating/recycling server hardware [Off-Topic] In-Reply-To: <8FA45C0E-7798-4D6F-A317-BCA538827803@bsdboy.com> References: <8FA45C0E-7798-4D6F-A317-BCA538827803@bsdboy.com> Message-ID: Hi > It seems like a waste to send it to metal scrap, if anyone has a more creative way of disposal please contact me off list. Local to San Francisco. What about http://www.freecycle.org/ ? From trelane at trelane.net Fri Aug 27 05:30:52 2010 From: trelane at trelane.net (Andrew Kirch) Date: Fri, 27 Aug 2010 06:30:52 -0400 Subject: sort by agony In-Reply-To: References: <20100826223626.GA7557@vacation.karoshi.com.> <4C77512F.5070509@gmail.com> <1282893943.8746.851.camel@mike-desktop> Message-ID: <4C7793DC.4090402@trelane.net> On 8/27/2010 4:33 AM, Callum Finlayson wrote: > On Fri, Aug 27, 2010 at 8:25 AM, Michael J McCafferty > wrote: >> For kicks, I looked at the most agonizing trip options... I chose a trip >> from San Diego to New York City... the worst were: >> >> 1) Tijuana to Mexico City, 16hr hour layover, then to Newark NJ and cost >> over $1k. >> >> 2) Tijuana to Guadalajara for an 8hr layover, then to Atlanta for a >> 1.5hr layover to New York LGA. > Made all the more agonizing when you arrive in NY and customs express > interest in your decission to stop over south of the border for a > couple of hours. > > As others have said -- agony's a nice idea, but the real value gets > added when you can weight the elements according to your personal > preferences (and the site can then capture how people choose to weight > various inconveniences in order to (i) improve their own algorithms, > and (ii) sell on to other interested parties). > > > C > right and be able to crank the agony up based on a given airport (ATL... I am looking at you here) Andrew From owen at delong.com Fri Aug 27 06:09:14 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 27 Aug 2010 04:09:14 -0700 Subject: sort by agony In-Reply-To: References: <20100826223626.GA7557@vacation.karoshi.com.> <4C77512F.5070509@gmail.com> <1282893943.8746.851.camel@mike-desktop> Message-ID: <043AA35A-D4C5-4789-B5BF-8749D9E69E7C@delong.com> On Aug 27, 2010, at 1:33 AM, Callum Finlayson wrote: > On Fri, Aug 27, 2010 at 8:25 AM, Michael J McCafferty > wrote: >> For kicks, I looked at the most agonizing trip options... I chose a trip >> from San Diego to New York City... the worst were: >> >> 1) Tijuana to Mexico City, 16hr hour layover, then to Newark NJ and cost >> over $1k. >> >> 2) Tijuana to Guadalajara for an 8hr layover, then to Atlanta for a >> 1.5hr layover to New York LGA. > > Made all the more agonizing when you arrive in NY and customs express > interest in your decission to stop over south of the border for a > couple of hours. > Except neither flight would involve customs in NY. In the first case, you would clear customs in Newark. In the second, you would clear customs in Atlanta. > As others have said -- agony's a nice idea, but the real value gets > added when you can weight the elements according to your personal > preferences (and the site can then capture how people choose to weight > various inconveniences in order to (i) improve their own algorithms, > and (ii) sell on to other interested parties). > I suspect it might not be that hard for them to add and would be worthy of requesting as a feature. Owen > > C From scott.brim at gmail.com Fri Aug 27 06:35:03 2010 From: scott.brim at gmail.com (Scott Brim) Date: Fri, 27 Aug 2010 07:35:03 -0400 Subject: sort by agony In-Reply-To: <4C77512F.5070509@gmail.com> References: <20100826223626.GA7557@vacation.karoshi.com.> <4C77512F.5070509@gmail.com> Message-ID: <4C77A2E7.2090403@gmail.com> On 08/27/2010 01:46 EDT, JC Dill wrote: > What is Agony, and why would I want to sort by it? > Agony is our way of sorting flights to take into account price, > duration, and number of stops. There's more to a flight than its price, > so we provide this sort to give you better all-around results. I wonder if I could persuade it to take round trip agony into account. For example on CO I can get from here to PEK easily, but on the way back I would have to spend the night in Newark. From tme at americafree.tv Fri Aug 27 07:09:55 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 27 Aug 2010 08:09:55 -0400 Subject: sort by agony In-Reply-To: <4C7793DC.4090402@trelane.net> References: <20100826223626.GA7557@vacation.karoshi.com.> <4C77512F.5070509@gmail.com> <1282893943.8746.851.camel@mike-desktop> <4C7793DC.4090402@trelane.net> Message-ID: <66E8B82D-95F0-441E-80BC-03AD53D33CF8@americafree.tv> On Aug 27, 2010, at 6:30 AM, Andrew Kirch wrote: > On 8/27/2010 4:33 AM, Callum Finlayson wrote: >> On Fri, Aug 27, 2010 at 8:25 AM, Michael J McCafferty >> wrote: >>> For kicks, I looked at the most agonizing trip options... I chose a trip >>> from San Diego to New York City... the worst were: >>> >>> 1) Tijuana to Mexico City, 16hr hour layover, then to Newark NJ and cost >>> over $1k. >>> >>> 2) Tijuana to Guadalajara for an 8hr layover, then to Atlanta for a >>> 1.5hr layover to New York LGA. >> Made all the more agonizing when you arrive in NY and customs express >> interest in your decission to stop over south of the border for a >> couple of hours. >> >> As others have said -- agony's a nice idea, but the real value gets >> added when you can weight the elements according to your personal >> preferences (and the site can then capture how people choose to weight >> various inconveniences in order to (i) improve their own algorithms, >> and (ii) sell on to other interested parties). >> >> >> C >> > right and be able to crank the agony up based on a given airport (ATL... I am looking at you here) Agony can frequently be made more specific. For example, one big problem in ATL at this time of year is thunderstorms, and these are likely to happen in the afternoon. (A late summer afternoon in North Georgia is almost certain to have some thunderstorms moving through.) So, a flight in August with a 10:00 AM change in ATL, I don't worry about. A flight with a 4:00 PM change, I assume I am likely to be late if not bumped to the next day. There are many airports with similar time variability (LHR at 9:00 AM!), and all of this data is out there. It would be a powerful selling point if the agony index included such granularity. Regards Marshall > > Andrew > > From Valdis.Kletnieks at vt.edu Fri Aug 27 09:08:24 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Aug 2010 10:08:24 -0400 Subject: sort by agony In-Reply-To: Your message of "Fri, 27 Aug 2010 00:25:43 PDT." <1282893943.8746.851.camel@mike-desktop> References: <20100826223626.GA7557@vacation.karoshi.com> <4C77512F.5070509@gmail.com> <1282893943.8746.851.camel@mike-desktop> Message-ID: <64109.1282918104@localhost> On Fri, 27 Aug 2010 00:25:43 PDT, Michael J McCafferty said: > 2) Tijuana to Guadalajara for an 8hr layover, then to Atlanta for a > 1.5hr layover to New York LGA. I once got booked Roanoke-Pittsburgh-Chicago-St Louis-Columbia MO. All layovers *short* enough to induce "run through the airport" panic behavior (and stopping for food was out of the question). Oh, and I *hate* takeoffs and landings. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tme at americafree.tv Fri Aug 27 09:32:17 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 27 Aug 2010 10:32:17 -0400 Subject: sort by agony In-Reply-To: <64109.1282918104@localhost> References: <20100826223626.GA7557@vacation.karoshi.com> <4C77512F.5070509@gmail.com> <1282893943.8746.851.camel@mike-desktop> <64109.1282918104@localhost> Message-ID: <05C7DC8A-F16B-49C0-B383-9BD63F8F7631@americafree.tv> On Aug 27, 2010, at 10:08 AM, Valdis.Kletnieks at vt.edu wrote: > On Fri, 27 Aug 2010 00:25:43 PDT, Michael J McCafferty said: > >> 2) Tijuana to Guadalajara for an 8hr layover, then to Atlanta for a >> 1.5hr layover to New York LGA. > > I once got booked Roanoke-Pittsburgh-Chicago-St Louis-Columbia MO. All layovers > *short* enough to induce "run through the airport" panic behavior (and stopping for > food was out of the question). > A _really_ intelligent airline scheduling system would (IMHO) be able to offer you options like "there is a direct flight Pittsburgh -> Kansas City, and from there it is a 2 hour drive to Columbia, so that will save you 5 hours travel time" Regards Marshall > Oh, and I *hate* takeoffs and landings. From bkain1 at ford.com Fri Aug 27 09:38:19 2010 From: bkain1 at ford.com (Kain, Becki (B.)) Date: Fri, 27 Aug 2010 10:38:19 -0400 Subject: sort by agony In-Reply-To: <05C7DC8A-F16B-49C0-B383-9BD63F8F7631@americafree.tv> References: <20100826223626.GA7557@vacation.karoshi.com><4C77512F.5070509@gmail.com><1282893943.8746.851.camel@mike-desktop><64109.1282918104@localhost> <05C7DC8A-F16B-49C0-B383-9BD63F8F7631@americafree.tv> Message-ID: <1370D6F16AD7E843BBBCA5DA3BCB71D50394BEA8@na1fcm32.fmc1.ford.com> My favorite is Detroit to Chicago, via ATL! -----Original Message----- From: Marshall Eubanks [mailto:tme at americafree.tv] Sent: Friday, August 27, 2010 10:32 AM To: Valdis.Kletnieks at vt.edu Cc: NANOG list Subject: Re: sort by agony On Aug 27, 2010, at 10:08 AM, Valdis.Kletnieks at vt.edu wrote: > On Fri, 27 Aug 2010 00:25:43 PDT, Michael J McCafferty said: > >> 2) Tijuana to Guadalajara for an 8hr layover, then to Atlanta for a >> 1.5hr layover to New York LGA. > > I once got booked Roanoke-Pittsburgh-Chicago-St Louis-Columbia MO. All layovers > *short* enough to induce "run through the airport" panic behavior (and stopping for > food was out of the question). > A _really_ intelligent airline scheduling system would (IMHO) be able to offer you options like "there is a direct flight Pittsburgh -> Kansas City, and from there it is a 2 hour drive to Columbia, so that will save you 5 hours travel time" Regards Marshall > Oh, and I *hate* takeoffs and landings. From Valdis.Kletnieks at vt.edu Fri Aug 27 10:03:01 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Aug 2010 11:03:01 -0400 Subject: sort by agony In-Reply-To: Your message of "Fri, 27 Aug 2010 10:32:17 EDT." <05C7DC8A-F16B-49C0-B383-9BD63F8F7631@americafree.tv> References: <20100826223626.GA7557@vacation.karoshi.com> <4C77512F.5070509@gmail.com> <1282893943.8746.851.camel@mike-desktop> <64109.1282918104@localhost> <05C7DC8A-F16B-49C0-B383-9BD63F8F7631@americafree.tv> Message-ID: <5818.1282921381@localhost> On Fri, 27 Aug 2010 10:32:17 EDT, Marshall Eubanks said: > A _really_ intelligent airline scheduling system would (IMHO) be able to offer you options like > > "there is a direct flight Pittsburgh -> Kansas City, and from there it > is a 2 hour drive to Columbia, so that will save you 5 hours travel > time" Yeah, would have been nice, except the policy says "travel at minimum total cost". The paperwork involved for a rental car was even scarier than a DCA takeoff/landing. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jsaxe at briworks.com Fri Aug 27 10:39:34 2010 From: jsaxe at briworks.com (Jeff Saxe) Date: Fri, 27 Aug 2010 11:39:34 -0400 Subject: Looking for Fiber Plant Management software Message-ID: <56C21A0A-6907-4A1D-869D-38EDF9BE7D1F@briworks.com> Good morning, NANOGers. My colleague at work wonders if anyone has suggestions for software to database all our fiber plant that we're constructing. We started out with paper, then Excel spreadsheets in a folder and on paper in a book, but clearly as our plant grows and we do more splicing this is not going to scale. We have started a MySQL database with a few tables, but wonder if someone has already invented this wheel. What do the "big boys" use? Homegrown solutions developed in-house and jealously guarded? Something standard? Expensive or cheap? Free open- source? He'd like to see... outside plan facilities: cables, fibers, splice points, poles; copper and fiber, preferably, but fiber is more important "circuit" or "DLR" that knows what elements are involved in a circuit GIS integration so that cables can be drawn on a map automagically low cost, of course Thanks in advance, everyone. -- Jeff Saxe, Network Engineer Blue Ridge InternetWorks, Charlottesville, VA 434-817-0707 ext. 2024 / JSaxe at briworks.com From jason at lixfeld.ca Fri Aug 27 11:13:35 2010 From: jason at lixfeld.ca (Jason Lixfeld) Date: Fri, 27 Aug 2010 12:13:35 -0400 Subject: Looking for Fiber Plant Management software In-Reply-To: <56C21A0A-6907-4A1D-869D-38EDF9BE7D1F@briworks.com> References: <56C21A0A-6907-4A1D-869D-38EDF9BE7D1F@briworks.com> Message-ID: <2F9F3B3F-B791-4A6F-AA25-AE138546BE45@lixfeld.ca> I've got a client who uses AutoCAD. They use it exclusively and have a pretty big fibre network for someone who's not an ILEC, so I guess it works fairly well. On 2010-08-27, at 11:39 AM, Jeff Saxe wrote: > Good morning, NANOGers. My colleague at work wonders if anyone has suggestions for software to database all our fiber plant that we're constructing. We started out with paper, then Excel spreadsheets in a folder and on paper in a book, but clearly as our plant grows and we do more splicing this is not going to scale. We have started a MySQL database with a few tables, but wonder if someone has already invented this wheel. > > What do the "big boys" use? Homegrown solutions developed in-house and jealously guarded? Something standard? Expensive or cheap? Free open-source? He'd like to see... > > outside plan facilities: cables, fibers, splice points, poles; copper and fiber, preferably, but fiber is more important > "circuit" or "DLR" that knows what elements are involved in a circuit > GIS integration so that cables can be drawn on a map automagically > low cost, of course > > Thanks in advance, everyone. > > -- Jeff Saxe, Network Engineer > Blue Ridge InternetWorks, Charlottesville, VA > 434-817-0707 ext. 2024 / JSaxe at briworks.com > > > > From karim.adel at gmail.com Fri Aug 27 12:27:06 2010 From: karim.adel at gmail.com (Kasper Adel) Date: Fri, 27 Aug 2010 19:27:06 +0200 Subject: Did your BGP crash today? Message-ID: Havent seen a thread on this one so thought i'd start one. Ripe tested a new attribute that crashed the internet, is that true? Kim From jared at puck.nether.net Fri Aug 27 12:29:15 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 27 Aug 2010 13:29:15 -0400 Subject: Did your BGP crash today? In-Reply-To: References: Message-ID: I did see some attribute 99 stuff go around earlier today and have not yet researched it. Unknown BGP attribute 99 (flags: 240) Unknown BGP attribute 99 (flags: 240) Unknown BGP attribute 99 (flags: 240) Unknown BGP attribute 99 (flags: 240) Unknown BGP attribute 99 (flags: 240) - Jared On Aug 27, 2010, at 1:27 PM, Kasper Adel wrote: > Havent seen a thread on this one so thought i'd start one. > > Ripe tested a new attribute that crashed the internet, is that true? > > > Kim From Valdis.Kletnieks at vt.edu Fri Aug 27 12:31:17 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Aug 2010 13:31:17 -0400 Subject: Did your BGP crash today? In-Reply-To: Your message of "Fri, 27 Aug 2010 19:27:06 +0200." References: Message-ID: <10643.1282930277@localhost> On Fri, 27 Aug 2010 19:27:06 +0200, Kasper Adel said: > Havent seen a thread on this one so thought i'd start one. > > Ripe tested a new attribute that crashed the internet, is that true? If it in fact "crashed the internet", as opposed to "gave a few buggy routers here and there indigestion", you wouldn't be posting to NANOG looking for confirmation. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nick at brevardwireless.com Fri Aug 27 12:31:38 2010 From: nick at brevardwireless.com (Nick Olsen) Date: Fri, 27 Aug 2010 13:31:38 -0400 Subject: Did your BGP crash today? Message-ID: <5f5c65e4$14186856$11dc4760$@com> No down time here, Would have been all over the news and everything if it really do "crash" the internet. Nick Olsen Network Operations (321) 205-1100 x106 ---------------------------------------- From: "Kasper Adel" Sent: Friday, August 27, 2010 1:27 PM To: "NANOG list" Subject: Did your BGP crash today? Havent seen a thread on this one so thought i'd start one. Ripe tested a new attribute that crashed the internet, is that true? Kim From nick at brevardwireless.com Fri Aug 27 12:35:16 2010 From: nick at brevardwireless.com (Nick Olsen) Date: Fri, 27 Aug 2010 13:35:16 -0400 Subject: Did your BGP crash today? Message-ID: <3a24bb89$5999ea45$7f8551a3$@com> Well played, Sir. Nick Olsen Network Operations (321) 205-1100 x106 ---------------------------------------- From: Valdis.Kletnieks at vt.edu Sent: Friday, August 27, 2010 1:32 PM To: "Kasper Adel" Subject: Re: Did your BGP crash today? On Fri, 27 Aug 2010 19:27:06 +0200, Kasper Adel said: > Havent seen a thread on this one so thought i'd start one. > > Ripe tested a new attribute that crashed the internet, is that true? If it in fact "crashed the internet", as opposed to "gave a few buggy routers here and there indigestion", you wouldn't be posting to NANOG looking for confirmation. :) From thomas.mangin at exa-networks.co.uk Fri Aug 27 12:44:28 2010 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Fri, 27 Aug 2010 19:44:28 +0200 Subject: Did your BGP crash today? In-Reply-To: <5f5c65e4$14186856$11dc4760$@com> References: <5f5c65e4$14186856$11dc4760$@com> Message-ID: <539F1B8D-35EB-4718-9F83-F61CE2EA00BA@exa-networks.co.uk> Looking at the graph of at least one of the european exchange where RIS connect, it had an impact. Now saying it was nothing is like saying that the YouTube incident was nothing as you were not affected as you do not use YouTube. Some people did feel the pain - lucky it was not you :) Thomas --- from my iPhone On 27 Aug 2010, at 19:31, "Nick Olsen" wrote: > No down time here, Would have been all over the news and everything if it > really do "crash" the internet. > > Nick Olsen > Network Operations > (321) 205-1100 x106 > > ---------------------------------------- > > From: "Kasper Adel" > Sent: Friday, August 27, 2010 1:27 PM > To: "NANOG list" > Subject: Did your BGP crash today? > > Havent seen a thread on this one so thought i'd start one. > > Ripe tested a new attribute that crashed the internet, is that true? > > Kim > From bpfankuch at cpgreeley.com Fri Aug 27 13:11:41 2010 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Fri, 27 Aug 2010 12:11:41 -0600 Subject: Did your BGP crash today? In-Reply-To: <539F1B8D-35EB-4718-9F83-F61CE2EA00BA@exa-networks.co.uk> References: <5f5c65e4$14186856$11dc4760$@com> <539F1B8D-35EB-4718-9F83-F61CE2EA00BA@exa-networks.co.uk> Message-ID: <01759D50DC387C45A018FE1817CE27D77E3DCFDDB2@CPExchange1.cpgreeley.com> Ignoring the fact that the original poster has a thing for the dramatic, of those who did feel minor pain from this what hardware platforms were affected and what software versions just for curiosity sake. -----Original Message----- From: Thomas Mangin [mailto:thomas.mangin at exa-networks.co.uk] Sent: Friday, August 27, 2010 11:44 AM To: nick at brevardwireless.com Cc: Subject: Re: Did your BGP crash today? Looking at the graph of at least one of the european exchange where RIS connect, it had an impact. Now saying it was nothing is like saying that the YouTube incident was nothing as you were not affected as you do not use YouTube. Some people did feel the pain - lucky it was not you :) Thomas --- from my iPhone On 27 Aug 2010, at 19:31, "Nick Olsen" wrote: > No down time here, Would have been all over the news and everything if > it really do "crash" the internet. > > Nick Olsen > Network Operations > (321) 205-1100 x106 > > ---------------------------------------- > > From: "Kasper Adel" > Sent: Friday, August 27, 2010 1:27 PM > To: "NANOG list" > Subject: Did your BGP crash today? > > Havent seen a thread on this one so thought i'd start one. > > Ripe tested a new attribute that crashed the internet, is that true? > > Kim > From Grzegorz at Janoszka.pl Fri Aug 27 13:27:49 2010 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Fri, 27 Aug 2010 20:27:49 +0200 Subject: Did your BGP crash today? In-Reply-To: <10643.1282930277@localhost> References: <10643.1282930277@localhost> Message-ID: <4C7803A5.4080509@Janoszka.pl> On 27-08-10 19:31, Valdis.Kletnieks at vt.edu wrote: > On Fri, 27 Aug 2010 19:27:06 +0200, Kasper Adel said: >> Havent seen a thread on this one so thought i'd start one. >> >> Ripe tested a new attribute that crashed the internet, is that true? > > If it in fact "crashed the internet", as opposed to "gave a few buggy routers > here and there indigestion", you wouldn't be posting to NANOG looking for > confirmation. :) https://www.ams-ix.net/statistics/ Not whole internet, but a part. And the "few buggy routers here and there" were mostly Cisco CRS-1's which didn't understand the new attribute and sent a malformed message to all peers, causing them to close the BGP session. I think most of the impact was limited to Europe, especially Amsterdam area. -- Grzegorz Janoszka From cscora at apnic.net Fri Aug 27 13:32:14 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 28 Aug 2010 04:32:14 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201008271832.o7RIWEvs002346@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 28 Aug, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 329510 Prefixes after maximum aggregation: 151625 Deaggregation factor: 2.17 Unique aggregates announced to Internet: 161906 Total ASes present in the Internet Routing Table: 34686 Prefixes per ASN: 9.50 Origin-only ASes present in the Internet Routing Table: 30086 Origin ASes announcing only one prefix: 14608 Transit ASes present in the Internet Routing Table: 4600 Transit-only ASes present in the Internet Routing Table: 106 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (41664) 21 Prefixes from unregistered ASNs in the Routing Table: 1590 Unregistered ASNs in the Routing Table: 797 Number of 32-bit ASNs allocated by the RIRs: 748 Prefixes from 32-bit ASNs in the Routing Table: 962 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 170 Number of addresses announced to Internet: 2293803456 Equivalent to 136 /8s, 184 /16s and 169 /24s Percentage of available address space announced: 61.9 Percentage of allocated address space announced: 66.1 Percentage of available address space allocated: 93.7 Percentage of address space in use by end-sites: 84.5 Total number of prefixes smaller than registry allocations: 156020 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 80080 Total APNIC prefixes after maximum aggregation: 27494 APNIC Deaggregation factor: 2.91 Prefixes being announced from the APNIC address blocks: 77020 Unique aggregates announced from the APNIC address blocks: 33981 APNIC Region origin ASes present in the Internet Routing Table: 4178 APNIC Prefixes per ASN: 18.43 APNIC Region origin ASes announcing only one prefix: 1167 APNIC Region transit ASes present in the Internet Routing Table: 640 Average APNIC Region AS path length visible: 3.7 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 541736480 Equivalent to 32 /8s, 74 /16s and 62 /24s Percentage of available APNIC address space announced: 76.9 APNIC AS Blocks 4608-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, 14/8, 27/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 135692 Total ARIN prefixes after maximum aggregation: 69900 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 108438 Unique aggregates announced from the ARIN address blocks: 42670 ARIN Region origin ASes present in the Internet Routing Table: 13878 ARIN Prefixes per ASN: 7.81 ARIN Region origin ASes announcing only one prefix: 5319 ARIN Region transit ASes present in the Internet Routing Table: 1380 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 732630688 Equivalent to 43 /8s, 171 /16s and 14 /24s Percentage of available ARIN address space announced: 62.4 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 75384 Total RIPE prefixes after maximum aggregation: 44003 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 68841 Unique aggregates announced from the RIPE address blocks: 45070 RIPE Region origin ASes present in the Internet Routing Table: 14722 RIPE Prefixes per ASN: 4.68 RIPE Region origin ASes announcing only one prefix: 7583 RIPE Region transit ASes present in the Internet Routing Table: 2207 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 24 Number of RIPE addresses announced to Internet: 436405504 Equivalent to 26 /8s, 3 /16s and 5 /24s Percentage of available RIPE address space announced: 76.5 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 29777 Total LACNIC prefixes after maximum aggregation: 7078 LACNIC Deaggregation factor: 4.21 Prefixes being announced from the LACNIC address blocks: 28269 Unique aggregates announced from the LACNIC address blocks: 15311 LACNIC Region origin ASes present in the Internet Routing Table: 1338 LACNIC Prefixes per ASN: 21.13 LACNIC Region origin ASes announcing only one prefix: 414 LACNIC Region transit ASes present in the Internet Routing Table: 237 Average LACNIC Region AS path length visible: 3.9 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 76818560 Equivalent to 4 /8s, 148 /16s and 40 /24s Percentage of available LACNIC address space announced: 57.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7369 Total AfriNIC prefixes after maximum aggregation: 1886 AfriNIC Deaggregation factor: 3.91 Prefixes being announced from the AfriNIC address blocks: 5717 Unique aggregates announced from the AfriNIC address blocks: 1722 AfriNIC Region origin ASes present in the Internet Routing Table: 397 AfriNIC Prefixes per ASN: 14.40 AfriNIC Region origin ASes announcing only one prefix: 125 AfriNIC Region transit ASes present in the Internet Routing Table: 91 Average AfriNIC Region AS path length visible: 3.7 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 20112896 Equivalent to 1 /8s, 50 /16s and 230 /24s Percentage of available AfriNIC address space announced: 59.9 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1866 8412 498 Korea Telecom (KIX) 4755 1482 302 162 TATA Communications formerly 7545 1385 234 86 TPG Internet Pty Ltd 17488 1342 153 130 Hathway IP Over Cable Interne 17974 1168 295 81 PT TELEKOMUNIKASI INDONESIA 9583 1017 76 490 Sify Limited 24560 998 303 179 Bharti Airtel Ltd., Telemedia 4808 917 1692 247 CNCGROUP IP network: China169 9829 818 689 36 BSNL National Internet Backbo 4134 785 22475 418 CHINANET-BACKBONE Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3843 3668 277 bellsouth.net, inc. 4323 2701 1115 393 Time Warner Telecom 19262 1802 4626 276 Verizon Global Networks 1785 1791 698 131 PaeTec Communications, Inc. 20115 1493 1529 653 Charter Communications 7018 1470 5734 953 AT&T WorldNet Services 6478 1308 274 118 AT&T Worldnet Services 2386 1289 554 907 AT&T Data Communications Serv 11492 1239 214 119 Cable One 22773 1180 2858 61 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 449 2026 390 TDC Tele Danmark 30890 443 99 211 Evolva Telecom 702 407 1870 324 UUNET - Commercial IP service 8866 403 117 18 Bulgarian Telecommunication C 8551 401 353 46 Bezeq International 3320 376 7329 325 Deutsche Telekom AG 3301 374 1416 329 TeliaNet Sweden 34984 367 89 185 BILISIM TELEKOM 12479 350 576 5 Uni2 Autonomous System 31148 326 17 80 FreeNet ISP Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1526 3049 246 UniNet S.A. de C.V. 10620 1102 246 148 TVCABLE BOGOTA 28573 1025 833 111 NET Servicos de Comunicao S.A 6503 835 187 257 AVANTEL, S.A. 7303 791 408 101 Telecom Argentina Stet-France 14420 553 35 76 CORPORACION NACIONAL DE TELEC 22047 551 310 15 VTR PUNTO NET S.A. 3816 477 210 100 Empresa Nacional de Telecomun 7738 477 922 30 Telecomunicacoes da Bahia S.A 11172 445 99 76 Servicios Alestra S.A de C.V Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1145 445 10 TEDATA 24863 725 147 39 LINKdotNET AS number 36992 661 279 185 Etisalat MISR 3741 267 907 225 The Internet Solution 33776 209 12 12 Starcomms Nigeria Limited 2018 197 277 64 Tertiary Education Network 6713 195 186 16 Itissalat Al-MAGHRIB 29571 193 19 11 Ci Telecom Autonomous system 24835 190 78 9 RAYA Telecom - Egypt 16637 147 440 96 MTN Network Solutions Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3843 3668 277 bellsouth.net, inc. 4323 2701 1115 393 Time Warner Telecom 4766 1866 8412 498 Korea Telecom (KIX) 19262 1802 4626 276 Verizon Global Networks 1785 1791 698 131 PaeTec Communications, Inc. 8151 1526 3049 246 UniNet S.A. de C.V. 20115 1493 1529 653 Charter Communications 4755 1482 302 162 TATA Communications formerly 7018 1470 5734 953 AT&T WorldNet Services 7545 1385 234 86 TPG Internet Pty Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2701 2308 Time Warner Telecom 1785 1791 1660 PaeTec Communications, Inc. 19262 1802 1526 Verizon Global Networks 4766 1866 1368 Korea Telecom (KIX) 4755 1482 1320 TATA Communications formerly 7545 1385 1299 TPG Internet Pty Ltd 8151 1526 1280 UniNet S.A. de C.V. 17488 1342 1212 Hathway IP Over Cable Interne 6478 1308 1190 AT&T Worldnet Services 8452 1145 1135 TEDATA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 11946 UNALLOCATED 8.12.155.0/24 40913 Quality Technology S 33084 UNALLOCATED 8.15.195.0/24 3356 Level 3 Communicatio 16734 UNALLOCATED 8.18.204.0/24 26914 Global Netoptex, Inc 22015 UNALLOCATED 8.22.137.0/24 14989 Broadview Networks 46856 UNALLOCATED 8.22.184.0/22 3561 Savvis 26169 UNALLOCATED 8.225.177.0/24 20225 TelJet 32249 UNALLOCATED 8.225.178.0/24 3356 Level 3 Communicatio 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 46883 UNALLOCATED 12.4.222.0/24 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.189.0/24 6453 Teleglobe Inc. 41.223.196.0/24 36990 Alkan Telecom Ltd 41.223.197.0/24 36990 Alkan Telecom Ltd 41.223.198.0/24 36990 Alkan Telecom Ltd 41.223.199.0/24 36990 Alkan Telecom Ltd Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:21 /9:10 /10:25 /11:67 /12:198 /13:414 /14:721 /15:1314 /16:11254 /17:5413 /18:9271 /19:18630 /20:23332 /21:23461 /22:30502 /23:29899 /24:171828 /25:1059 /26:1198 /27:718 /28:115 /29:47 /30:6 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2459 3843 bellsouth.net, inc. 4766 1488 1866 Korea Telecom (KIX) 4323 1365 2701 Time Warner Telecom 1785 1254 1791 PaeTec Communications, Inc. 11492 1091 1239 Cable One 17488 1084 1342 Hathway IP Over Cable Interne 18566 1068 1087 Covad Communications 8452 1036 1145 TEDATA 10620 1015 1102 TVCABLE BOGOTA 24560 897 998 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:56 2:2 4:13 8:303 12:2014 13:8 14:1 15:21 16:3 17:9 20:7 24:1436 27:289 31:1 32:61 33:22 38:695 40:97 41:2521 44:3 46:45 47:16 52:12 55:7 56:2 57:28 58:801 59:503 60:460 61:1074 62:1086 63:1975 64:3740 65:2323 66:4032 67:1839 68:1122 69:2788 70:743 71:372 72:1940 73:2 74:2320 75:274 76:327 77:882 78:624 79:437 80:1038 81:804 82:503 83:510 84:691 85:1043 86:481 87:696 88:317 89:1532 90:97 91:2989 92:423 93:985 94:1161 95:679 96:489 97:217 98:621 99:34 108:64 109:651 110:456 111:556 112:279 113:314 114:451 115:573 116:1095 117:658 118:484 119:895 120:141 121:708 122:1540 123:955 124:1119 125:1242 128:226 129:158 130:199 131:540 132:247 133:17 134:195 135:45 136:236 137:136 138:264 139:105 140:476 141:197 142:344 143:351 144:471 145:52 146:427 147:170 148:679 149:305 150:153 151:233 152:299 153:169 154:3 155:361 156:165 157:328 158:118 159:358 160:315 161:183 162:269 163:167 164:416 165:369 166:467 167:423 168:654 169:158 170:722 171:61 172:2 173:1008 174:502 175:155 176:1 177:1 178:435 180:586 181:1 182:234 183:237 184:204 186:565 187:453 188:797 189:757 190:3978 192:5764 193:4754 194:3427 195:2788 196:1172 198:3577 199:3579 200:5430 201:1580 202:8055 203:8300 204:4010 205:2398 206:2534 207:3077 208:3887 209:3469 210:2561 211:1297 212:1754 213:1683 214:658 215:67 216:4775 217:1576 218:478 219:379 220:1140 221:388 222:290 223:7 End of report From thomas.mangin at exa-networks.co.uk Fri Aug 27 13:41:25 2010 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Fri, 27 Aug 2010 19:41:25 +0100 Subject: Did your BGP crash today? In-Reply-To: <4C7803A5.4080509@Janoszka.pl> References: <10643.1282930277@localhost> <4C7803A5.4080509@Janoszka.pl> Message-ID: <11635451-A627-420E-81C0-D3530766B4F7@exa-networks.co.uk> On 27 Aug 2010, at 19:27, Grzegorz Janoszka wrote: > On 27-08-10 19:31, Valdis.Kletnieks at vt.edu wrote: >> On Fri, 27 Aug 2010 19:27:06 +0200, Kasper Adel said: >>> Havent seen a thread on this one so thought i'd start one. >>> >>> Ripe tested a new attribute that crashed the internet, is that true? >> >> If it in fact "crashed the internet", as opposed to "gave a few buggy routers >> here and there indigestion", you wouldn't be posting to NANOG looking for >> confirmation. :) > > https://www.ams-ix.net/statistics/ > > Not whole internet, but a part. And the "few buggy routers here and there" were mostly Cisco CRS-1's which didn't understand the new attribute and sent a malformed message to all peers, causing them to close the BGP session. In a way it remind me of the ASN4 bug .. Until a vendor fix is available I guess that the details are better left off public mailing lists. http://www.uknof.org.uk/uknof12/Davidson-4_byte_asn.pdf > I think most of the impact was limited to Europe, especially Amsterdam area. Yes, It had an effect on ISPs which are connected to RIS. http://www.ripe.net/ris/ AFAIK this mean ASes at LINX and AMS-IX . The LINX graph shows a similar (but smaller) dip of 50-60 GB. Thomas From llynch at civil-tongue.net Fri Aug 27 13:42:17 2010 From: llynch at civil-tongue.net (Lucy Lynch) Date: Fri, 27 Aug 2010 11:42:17 -0700 (PDT) Subject: Did your BGP crash today? In-Reply-To: <4C7803A5.4080509@Janoszka.pl> References: <10643.1282930277@localhost> <4C7803A5.4080509@Janoszka.pl> Message-ID: FYI: ---------------------------------------------------------------------- Dear Colleagues, On Friday 27 August, from 08:41 to 09:08 UTC, the RIPE NCC Routing Information Service (RIS) announced a route with an experimental BGP attribute. During this announcement, some Internet Service Providers reported problems with their networking infrastructure. Investigation -------------- Immediately after discovering this, we stopped the announcement and started investigating the problem. Our investigation has shown that the problem was likely to have been caused by certain router types incorrectly modifying the experimental attribute and then further announcing the malformed route to their peers. The announcements sent out by the RIS were correct and complied to all standards. The experimental attribute was part of an experiment conducted in collaboration with a group from Duke University. This involved announcing a large (3000 bytes) optional transitive attribute, using a modified version of Quagga. The attribute used type code 99. The data consisted of zeros. We used the prefix 93.175.144.0/24 for this and announced from AS 12654 on AMS-IX, NL-IX and GN-IX to all our peers. Reports from affected ISPs showed that the length of the attribute in the attribute header, as seen by their routers, was not correct. The header stated 233 bytes and the actual data in their samples was 237 bytes. This caused some routers to drop the session with the peer that announced the route. We have built a test set-up which is running identical software and configurations to the live set-up. From this set-up, and the BGP packet dumps as made by the RIS, we have determined that the length of the data in the attribute as sent out by the RIS was indeed 3000 bytes and that all lengths recorded in the headers of the BGP updates were correct. Beyond the RIS systems, we can only do limited diagnosis. One possible explanation is that the affected routers did not correctly use the extended length flag on the attribute. This flag is set when the length of the attribute exceeds 255 bytes i.e. when two octets are needed to store the length. It may be that the routers may not add the higher octet of the length to the total length, which would lead, in our test set-up, to a total packet length of 236 bytes. If, in addition, the routers also incorrectly trim the attribute length, the problem could occur as observed. It is worth noting that the difference between the reported 233 and 237 bytes is the size of the flags, type code and length in the attribute. We will be further investigating this problem and will report any findings. We regret any inconvenience caused. Kind regards, Erik Romijn Information Services RIPE NCC _______________________________________________ tech-l mailing list tech-l at ams-ix.net http://melix.ams-ix.net/mailman/listinfo/tech-l - Lucy On Fri, 27 Aug 2010, Grzegorz Janoszka wrote: > On 27-08-10 19:31, Valdis.Kletnieks at vt.edu wrote: >> On Fri, 27 Aug 2010 19:27:06 +0200, Kasper Adel said: >>> Havent seen a thread on this one so thought i'd start one. >>> >>> Ripe tested a new attribute that crashed the internet, is that true? >> >> If it in fact "crashed the internet", as opposed to "gave a few buggy >> routers >> here and there indigestion", you wouldn't be posting to NANOG looking for >> confirmation. :) > > https://www.ams-ix.net/statistics/ > > Not whole internet, but a part. And the "few buggy routers here and there" > were mostly Cisco CRS-1's which didn't understand the new attribute and sent > a malformed message to all peers, causing them to close the BGP session. > > I think most of the impact was limited to Europe, especially Amsterdam area. > > From jlewis at lewis.org Fri Aug 27 13:54:05 2010 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 27 Aug 2010 14:54:05 -0400 (EDT) Subject: sort by agony In-Reply-To: References: <20100826223626.GA7557@vacation.karoshi.com.> <4C77512F.5070509@gmail.com> <1282893943.8746.851.camel@mike-desktop> Message-ID: On Fri, 27 Aug 2010, Callum Finlayson wrote: >> 1) Tijuana to Mexico City, 16hr hour layover, then to Newark NJ and cost >> over $1k. >> >> 2) Tijuana to Guadalajara for an 8hr layover, then to Atlanta for a >> 1.5hr layover to New York LGA. > > Made all the more agonizing when you arrive in NY and customs express > interest in your decission to stop over south of the border for a > couple of hours. You be cool for twenty hours And I'll pay you twenty grand. That song just pop into anyone else's head? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From thomas.mangin at exa-networks.co.uk Fri Aug 27 13:56:35 2010 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Fri, 27 Aug 2010 19:56:35 +0100 Subject: Did your BGP crash today? In-Reply-To: References: <10643.1282930277@localhost> <4C7803A5.4080509@Janoszka.pl> Message-ID: <5A50C157-C761-4E6B-9968-5B99F131395C@exa-networks.co.uk> So much for "better left off public mailing lists" ! sigh ! Thomas On 27 Aug 2010, at 19:42, Lucy Lynch wrote: > FYI: > > ---------------------------------------------------------------------- > Dear Colleagues, > > On Friday 27 August, from 08:41 to 09:08 UTC, the RIPE NCC Routing > Information Service (RIS) announced a route with an experimental BGP > attribute. During this announcement, some Internet Service Providers > reported problems with their networking infrastructure. > > Investigation > -------------- > > Immediately after discovering this, we stopped the announcement and > started investigating the problem. Our investigation has shown that the > problem was likely to have been caused by certain router types > incorrectly modifying the experimental attribute and then further > announcing the malformed route to their peers. The announcements sent > out by the RIS were correct and complied to all standards. > > The experimental attribute was part of an experiment conducted in > collaboration with a group from Duke University. This involved > announcing a large (3000 bytes) optional transitive attribute, using a > modified version of Quagga. The attribute used type code 99. The data > consisted of zeros. We used the prefix 93.175.144.0/24 for this and > announced from AS 12654 on AMS-IX, NL-IX and GN-IX to all our peers. > > Reports from affected ISPs showed that the length of the attribute in > the attribute header, as seen by their routers, was not correct. The > header stated 233 bytes and the actual data in their samples was 237 > bytes. This caused some routers to drop the session with the peer that > announced the route. > > We have built a test set-up which is running identical software and > configurations to the live set-up. From this set-up, and the BGP packet > dumps as made by the RIS, we have determined that the length of the data > in the attribute as sent out by the RIS was indeed 3000 bytes and that > all lengths recorded in the headers of the BGP updates were correct. > > Beyond the RIS systems, we can only do limited diagnosis. One possible > explanation is that the affected routers did not correctly use the > extended length flag on the attribute. This flag is set when the length > of the attribute exceeds 255 bytes i.e. when two octets are needed to > store the length. > > It may be that the routers may not add the higher octet of the length to > the total length, which would lead, in our test set-up, to a total > packet length of 236 bytes. If, in addition, the routers also > incorrectly trim the attribute length, the problem could occur as > observed. It is worth noting that the difference between the reported > 233 and 237 bytes is the size of the flags, type code and length in the > attribute. > > We will be further investigating this problem and will report any > findings. We regret any inconvenience caused. > > Kind regards, > > Erik Romijn > > Information Services > RIPE NCC > _______________________________________________ > tech-l mailing list > tech-l at ams-ix.net > http://melix.ams-ix.net/mailman/listinfo/tech-l > > > > - Lucy > > On Fri, 27 Aug 2010, Grzegorz Janoszka wrote: > >> On 27-08-10 19:31, Valdis.Kletnieks at vt.edu wrote: >>> On Fri, 27 Aug 2010 19:27:06 +0200, Kasper Adel said: >>>> Havent seen a thread on this one so thought i'd start one. >>>> Ripe tested a new attribute that crashed the internet, is that true? >>> If it in fact "crashed the internet", as opposed to "gave a few buggy routers >>> here and there indigestion", you wouldn't be posting to NANOG looking for >>> confirmation. :) >> >> https://www.ams-ix.net/statistics/ >> >> Not whole internet, but a part. And the "few buggy routers here and there" were mostly Cisco CRS-1's which didn't understand the new attribute and sent a malformed message to all peers, causing them to close the BGP session. >> >> I think most of the impact was limited to Europe, especially Amsterdam area. >> >> > From llynch at civil-tongue.net Fri Aug 27 13:59:45 2010 From: llynch at civil-tongue.net (Lucy Lynch) Date: Fri, 27 Aug 2010 11:59:45 -0700 (PDT) Subject: Did your BGP crash today? In-Reply-To: <5A50C157-C761-4E6B-9968-5B99F131395C@exa-networks.co.uk> References: <10643.1282930277@localhost> <4C7803A5.4080509@Janoszka.pl> <5A50C157-C761-4E6B-9968-5B99F131395C@exa-networks.co.uk> Message-ID: sorry - found via google... - Lucy On Fri, 27 Aug 2010, Thomas Mangin wrote: > So much for "better left off public mailing lists" ! sigh ! > > Thomas > > On 27 Aug 2010, at 19:42, Lucy Lynch wrote: > >> FYI: >> >> ---------------------------------------------------------------------- >> Dear Colleagues, >> >> On Friday 27 August, from 08:41 to 09:08 UTC, the RIPE NCC Routing >> Information Service (RIS) announced a route with an experimental BGP >> attribute. During this announcement, some Internet Service Providers >> reported problems with their networking infrastructure. >> >> Investigation >> -------------- >> >> Immediately after discovering this, we stopped the announcement and >> started investigating the problem. Our investigation has shown that the >> problem was likely to have been caused by certain router types >> incorrectly modifying the experimental attribute and then further >> announcing the malformed route to their peers. The announcements sent >> out by the RIS were correct and complied to all standards. >> >> The experimental attribute was part of an experiment conducted in >> collaboration with a group from Duke University. This involved >> announcing a large (3000 bytes) optional transitive attribute, using a >> modified version of Quagga. The attribute used type code 99. The data >> consisted of zeros. We used the prefix 93.175.144.0/24 for this and >> announced from AS 12654 on AMS-IX, NL-IX and GN-IX to all our peers. >> >> Reports from affected ISPs showed that the length of the attribute in >> the attribute header, as seen by their routers, was not correct. The >> header stated 233 bytes and the actual data in their samples was 237 >> bytes. This caused some routers to drop the session with the peer that >> announced the route. >> >> We have built a test set-up which is running identical software and >> configurations to the live set-up. From this set-up, and the BGP packet >> dumps as made by the RIS, we have determined that the length of the data >> in the attribute as sent out by the RIS was indeed 3000 bytes and that >> all lengths recorded in the headers of the BGP updates were correct. >> >> Beyond the RIS systems, we can only do limited diagnosis. One possible >> explanation is that the affected routers did not correctly use the >> extended length flag on the attribute. This flag is set when the length >> of the attribute exceeds 255 bytes i.e. when two octets are needed to >> store the length. >> >> It may be that the routers may not add the higher octet of the length to >> the total length, which would lead, in our test set-up, to a total >> packet length of 236 bytes. If, in addition, the routers also >> incorrectly trim the attribute length, the problem could occur as >> observed. It is worth noting that the difference between the reported >> 233 and 237 bytes is the size of the flags, type code and length in the >> attribute. >> >> We will be further investigating this problem and will report any >> findings. We regret any inconvenience caused. >> >> Kind regards, >> >> Erik Romijn >> >> Information Services >> RIPE NCC >> _______________________________________________ >> tech-l mailing list >> tech-l at ams-ix.net >> http://melix.ams-ix.net/mailman/listinfo/tech-l >> >> >> >> - Lucy >> >> On Fri, 27 Aug 2010, Grzegorz Janoszka wrote: >> >>> On 27-08-10 19:31, Valdis.Kletnieks at vt.edu wrote: >>>> On Fri, 27 Aug 2010 19:27:06 +0200, Kasper Adel said: >>>>> Havent seen a thread on this one so thought i'd start one. >>>>> Ripe tested a new attribute that crashed the internet, is that true? >>>> If it in fact "crashed the internet", as opposed to "gave a few buggy routers >>>> here and there indigestion", you wouldn't be posting to NANOG looking for >>>> confirmation. :) >>> >>> https://www.ams-ix.net/statistics/ >>> >>> Not whole internet, but a part. And the "few buggy routers here and there" were mostly Cisco CRS-1's which didn't understand the new attribute and sent a malformed message to all peers, causing them to close the BGP session. >>> >>> I think most of the impact was limited to Europe, especially Amsterdam area. >>> >>> >> > From Grzegorz at Janoszka.pl Fri Aug 27 14:03:02 2010 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Fri, 27 Aug 2010 21:03:02 +0200 Subject: Did your BGP crash today? In-Reply-To: <11635451-A627-420E-81C0-D3530766B4F7@exa-networks.co.uk> References: <10643.1282930277@localhost> <4C7803A5.4080509@Janoszka.pl> <11635451-A627-420E-81C0-D3530766B4F7@exa-networks.co.uk> Message-ID: <4C780BE6.5050809@Janoszka.pl> On 27-08-10 20:41, Thomas Mangin wrote: >> I think most of the impact was limited to Europe, especially Amsterdam area. > Yes, It had an effect on ISPs which are connected to RIS. http://www.ripe.net/ris/ > AFAIK this mean ASes at LINX and AMS-IX . The LINX graph shows a similar (but smaller) dip of 50-60 GB. Not only. We don't peer with RIS, but about 8-10 our peers announce to us RIS. The nasty update we got from completely different AS, not RIS. You may just check whether you see AS12654 - it is RIS. -- Grzegorz Janoszka From thomas.mangin at exa-networks.co.uk Fri Aug 27 14:10:54 2010 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Fri, 27 Aug 2010 20:10:54 +0100 Subject: Did your BGP crash today? In-Reply-To: <4C780BE6.5050809@Janoszka.pl> References: <10643.1282930277@localhost> <4C7803A5.4080509@Janoszka.pl> <11635451-A627-420E-81C0-D3530766B4F7@exa-networks.co.uk> <4C780BE6.5050809@Janoszka.pl> Message-ID: <5A892B22-E52B-4AF1-9518-F16A54252663@exa-networks.co.uk> On 27 Aug 2010, at 20:03, Grzegorz Janoszka wrote: > On 27-08-10 20:41, Thomas Mangin wrote: >>> I think most of the impact was limited to Europe, especially Amsterdam area. >> Yes, It had an effect on ISPs which are connected to RIS. http://www.ripe.net/ris/ >> AFAIK this mean ASes at LINX and AMS-IX . The LINX graph shows a similar (but smaller) dip of 50-60 GB. > > Not only. We don't peer with RIS, but about 8-10 our peers announce to us RIS. The nasty update we got from completely different AS, not RIS. > You may just check whether you see AS12654 - it is RIS. Yes, the BGP message had a transitive attribute - sorry if I was not clear. That said, you may want to ask why you are getting RIS routes if you are not peering with them directly :p RIS is peering world wide ( http://www.ripe.net/ris/docs/peering.html ) but the mail was only sent to linx-ops and tech-l, so the announcement may have been limited to europe (for all I know). Thomas From ras at e-gerbil.net Fri Aug 27 14:13:24 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 27 Aug 2010 14:13:24 -0500 Subject: Did your BGP crash today? In-Reply-To: References: Message-ID: <20100827191324.GJ1946@gerbil.cluepon.net> On Fri, Aug 27, 2010 at 01:29:15PM -0400, Jared Mauch wrote: > > Unknown BGP attribute 99 (flags: 240) > Unknown BGP attribute 99 (flags: 240) > Unknown BGP attribute 99 (flags: 240) > Unknown BGP attribute 99 (flags: 240) > Unknown BGP attribute 99 (flags: 240) Just out of curiosity, at what point will we as operators rise up against the ivory tower protocol designers at the IETF and demand that they add a mechanism to not bring down the entire BGP session because of a single malformed attribute? Did I miss the memo about the meeting? I'll bring the punch and pie. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From jeroen at unfix.org Fri Aug 27 14:17:40 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 27 Aug 2010 21:17:40 +0200 Subject: Did your BGP crash today? In-Reply-To: <20100827191324.GJ1946@gerbil.cluepon.net> References: <20100827191324.GJ1946@gerbil.cluepon.net> Message-ID: <4C780F54.8070607@unfix.org> On 2010-08-27 21:13, Richard A Steenbergen wrote: > On Fri, Aug 27, 2010 at 01:29:15PM -0400, Jared Mauch wrote: >> >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) > > Just out of curiosity, at what point will we as operators rise up > against the ivory tower protocol designers at the IETF and demand that > they add a mechanism to not bring down the entire BGP session because of > a single malformed attribute? Did I miss the memo about the meeting? > I'll bring the punch and pie. Complain to your vendor, especially C & J are having good enough influence on the IETF to make such a change possible. I can agree with tearing the session down when one encounters an improperly formatted message, but an unknown attribute, while the rest of the format of message is fine, is a silly thing to hang up on indeed. Greets, Jeroen From bygg at cafax.se Fri Aug 27 21:19:26 2010 From: bygg at cafax.se (Johnny Eriksson) Date: Fri, 27 Aug 2010 21:19:26 WET DST Subject: sort by agony In-Reply-To: Your message of Fri, 27 Aug 2010 10:32:17 -0400 Message-ID: Marshall Eubanks wrote: > A _really_ intelligent airline scheduling system would (IMHO) be > able to offer you options like > > "there is a direct flight Pittsburgh -> Kansas City, and from there it > is a 2 hour drive to Columbia, so that will save you 5 hours travel time" That's not an airline scheduling system. That's a travel scheduling system. Different beast. > Regards > Marshall --Johnny From jared at puck.nether.net Fri Aug 27 14:19:28 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 27 Aug 2010 15:19:28 -0400 Subject: Did your BGP crash today? In-Reply-To: <20100827191324.GJ1946@gerbil.cluepon.net> References: <20100827191324.GJ1946@gerbil.cluepon.net> Message-ID: <116F6B00-9ADB-407C-9714-AE68292DDBAC@puck.nether.net> On Aug 27, 2010, at 3:13 PM, Richard A Steenbergen wrote: > On Fri, Aug 27, 2010 at 01:29:15PM -0400, Jared Mauch wrote: >> >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) > > Just out of curiosity, at what point will we as operators rise up > against the ivory tower protocol designers at the IETF and demand that > they add a mechanism to not bring down the entire BGP session because of > a single malformed attribute? Did I miss the memo about the meeting? > I'll bring the punch and pie. I think it's actually an implementation problem where it got out-of-sync. You can't exactly blame the IETF for a vendor having poor code quality. (at least not in this case IMHO). I seem to recall there was something like this in the past that caused some significant problems with people also running XR/CRS-1. They quickly got a fix and cisco issued a PSIRT as a result: http://www.cisco.com/en/US/products/products_security_advisory09186a0080af150f.shtml#summary I would hope these people updated their software for that impact as well. Without knowing what the defect impact was on those devices, and without talking to PSIRT today, I don't know if an advisory is pending. Perhaps it's a new defect and the bug is going to be triggered again soon for those that don't patch their devices. - jared From jared at puck.nether.net Fri Aug 27 14:22:52 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 27 Aug 2010 15:22:52 -0400 Subject: Did your BGP crash today? In-Reply-To: <4C780F54.8070607@unfix.org> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> Message-ID: On Aug 27, 2010, at 3:17 PM, Jeroen Massar wrote: > On 2010-08-27 21:13, Richard A Steenbergen wrote: >> On Fri, Aug 27, 2010 at 01:29:15PM -0400, Jared Mauch wrote: >>> >>> Unknown BGP attribute 99 (flags: 240) >>> Unknown BGP attribute 99 (flags: 240) >>> Unknown BGP attribute 99 (flags: 240) >>> Unknown BGP attribute 99 (flags: 240) >>> Unknown BGP attribute 99 (flags: 240) >> >> Just out of curiosity, at what point will we as operators rise up >> against the ivory tower protocol designers at the IETF and demand that >> they add a mechanism to not bring down the entire BGP session because of >> a single malformed attribute? Did I miss the memo about the meeting? >> I'll bring the punch and pie. > > Complain to your vendor, especially C & J are having good enough > influence on the IETF to make such a change possible. > > > I can agree with tearing the session down when one encounters an > improperly formatted message, but an unknown attribute, while the rest > of the format of message is fine, is a silly thing to hang up on indeed. When you are processing something, it's sometimes hard to tell if something just was mis-parsed (as I think the case is here with the "missing-2-bytes") vs just getting garbage. Perhaps there should be some way to "re-sync" when you are having this problem, or a parallel "keepalive" path similar to MACA/MCAS/MIDCAS/TCAS between the devices to talk when something bad is happening. - Jared From davei at otd.com Fri Aug 27 14:33:38 2010 From: davei at otd.com (Dave Israel) Date: Fri, 27 Aug 2010 15:33:38 -0400 Subject: Did your BGP crash today? In-Reply-To: References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> Message-ID: <4C781312.3010903@otd.com> On 8/27/2010 3:22 PM, Jared Mauch wrote: > When you are processing something, it's sometimes hard to tell if something > just was mis-parsed (as I think the case is here with the "missing-2-bytes") > vs just getting garbage. Perhaps there should be some way to "re-sync" when > you are having this problem, or a parallel "keepalive" path similar to > MACA/MCAS/MIDCAS/TCAS between the devices to talk when something bad is > happening. I know it wasn't there originally, and isn't mandatory now, but there is an MD5 hash that can be added to the packet. If the TCP hash checks out, then you know the packet wasn't garbled, and just contained information you didn't grok. That seems like enough evidence to be able to shrug and toss the packet without dropping the session. -Dave From warren at kumari.net Fri Aug 27 14:43:45 2010 From: warren at kumari.net (Warren Kumari) Date: Fri, 27 Aug 2010 15:43:45 -0400 Subject: Idea's for donating/recycling server hardware [Off-Topic] In-Reply-To: References: <8FA45C0E-7798-4D6F-A317-BCA538827803@bsdboy.com> Message-ID: <021C3C05-F992-47E0-8170-D0BA411563DF@kumari.net> On Aug 26, 2010, at 10:03 PM, Suresh Ramasubramanian wrote: > There's also http://www.nsrc.org at UOregon - as good a home as any , and better than most, > for any gear you want to trash. > > On Fri, Aug 27, 2010 at 4:35 AM, Wil Schultz > wrote: >> I apologize for being somewhat off topic... >> >> I've got a fair amount of SPARC hardware (v210 through v490) and >> 32bit HP DL360-380 hardware that I'm looking for creative ways to >> dispose of or to donate. >> >> It seems like a waste to send it to metal scrap, if anyone has a >> more creative way of disposal please contact me off list. Local to >> San Francisco. >> >> *disclaimer, contributions cannot go to religious or political >> organizations per corp policy* >> >> Thanks! >> >> -wil >> > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > -- "I try to be good hard-worker-man, but refrigemater so messy, so so messy." -- NewsRadio. From ekim.ittag at gmail.com Fri Aug 27 15:07:36 2010 From: ekim.ittag at gmail.com (Mike Gatti) Date: Fri, 27 Aug 2010 16:07:36 -0400 Subject: Did your BGP crash today? In-Reply-To: <4C781312.3010903@otd.com> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> Message-ID: <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> where's the change management process in all of this. basically now we are going to starting changing things that can potentially have an adverse affect on users without letting anyone know before hand .... Interesting concept. On Aug 27, 2010, at 3:33 PM, Dave Israel wrote: > > On 8/27/2010 3:22 PM, Jared Mauch wrote: >> When you are processing something, it's sometimes hard to tell if something >> just was mis-parsed (as I think the case is here with the "missing-2-bytes") >> vs just getting garbage. Perhaps there should be some way to "re-sync" when >> you are having this problem, or a parallel "keepalive" path similar to >> MACA/MCAS/MIDCAS/TCAS between the devices to talk when something bad is >> happening. > > I know it wasn't there originally, and isn't mandatory now, but there is > an MD5 hash that can be added to the packet. If the TCP hash checks > out, then you know the packet wasn't garbled, and just contained > information you didn't grok. That seems like enough evidence to be able > to shrug and toss the packet without dropping the session. > > -Dave > > > =+=+=+=+=+=+=+=+=+=+=+=+= Mike Gatti ekim.ittag at gmail.com =+=+=+=+=+=+=+=+=+=+=+=+= From morrowc.lists at gmail.com Fri Aug 27 15:11:32 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 27 Aug 2010 16:11:32 -0400 Subject: Did your BGP crash today? In-Reply-To: <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> Message-ID: On Fri, Aug 27, 2010 at 4:07 PM, Mike Gatti wrote: > where's the change management process in all of this. > basically now we are going to starting changing things that can > potentially have an adverse affect on users without letting anyone know > before hand .... Interesting concept. you are running bgp, you are connected to the 'internet'... congrats you are part of the experiment. I suppose one view is that "at least it wasn't someone with ill intent, or a misconfigured mikrotek!" (you are asking your vendors to run full bit sweeps of each protocol in a regimented manner checking for all possible edge cases and properly handling them, right?) -chris > On Aug 27, 2010, at 3:33 PM, Dave Israel wrote: > >> >> On 8/27/2010 3:22 PM, Jared Mauch wrote: >>> When you are processing something, it's sometimes hard to tell if something >>> just was mis-parsed (as I think the case is here with the "missing-2-bytes") >>> vs just getting garbage. ?Perhaps there should be some way to "re-sync" when >>> you are having this problem, or a parallel "keepalive" path similar to >>> MACA/MCAS/MIDCAS/TCAS between the devices to talk when something bad is >>> happening. >> >> I know it wasn't there originally, and isn't mandatory now, but there is >> an MD5 hash that can be added to the packet. ?If the TCP hash checks >> out, then you know the packet wasn't garbled, and just contained >> information you didn't grok. ?That seems like enough evidence to be able >> to shrug and toss the packet without dropping the session. >> >> -Dave >> >> >> > > =+=+=+=+=+=+=+=+=+=+=+=+= > Mike Gatti > ekim.ittag at gmail.com > =+=+=+=+=+=+=+=+=+=+=+=+= > > > > > From wschultz at bsdboy.com Fri Aug 27 15:24:30 2010 From: wschultz at bsdboy.com (Wil Schultz) Date: Fri, 27 Aug 2010 13:24:30 -0700 Subject: Fwd: Idea's for donating/recycling server hardware [Off-Topic] References: <8FA45C0E-7798-4D6F-A317-BCA538827803@bsdboy.com> Message-ID: Thank you for all of the replies, the response has been overwhelming. :-) I think we're going to be able to do some good stuff with this "junk", i'm going to start contacting some folks and get things going here shortly. Thank you! -wil Begin forwarded message: > From: Wil Schultz > Date: August 26, 2010 4:05:33 PM PDT > To: nanog at nanog.org > Subject: Idea's for donating/recycling server hardware [Off-Topic] > > I apologize for being somewhat off topic... > > I've got a fair amount of SPARC hardware (v210 through v490) and 32bit HP DL360-380 hardware that I'm looking for creative ways to dispose of or to donate. > > It seems like a waste to send it to metal scrap, if anyone has a more creative way of disposal please contact me off list. Local to San Francisco. > > *disclaimer, contributions cannot go to religious or political organizations per corp policy* > > Thanks! > > -wil From clay at bloomcounty.org Fri Aug 27 15:43:39 2010 From: clay at bloomcounty.org (Clay Fiske) Date: Fri, 27 Aug 2010 13:43:39 -0700 Subject: Did your BGP crash today? In-Reply-To: <20100827191324.GJ1946@gerbil.cluepon.net> References: <20100827191324.GJ1946@gerbil.cluepon.net> Message-ID: On Aug 27, 2010, at 12:13 PM, Richard A Steenbergen wrote: > > Just out of curiosity, at what point will we as operators rise up > against the ivory tower protocol designers at the IETF and demand that > they add a mechanism to not bring down the entire BGP session because of > a single malformed attribute? Did I miss the memo about the meeting? > I'll bring the punch and pie. About the same time vendors' BGP implementations start to work correctly? I agree such a knob would be useful, but seems to me that actually following the current standard would largely curb the issue by itself. I recall one of the previous times something like this happened (and with a much wider impact), I believe it was $C that was accepting a bad attribute and passing it along. The effect was that other vendors ($F in particular, I think) would drop the session (per RFC), which made it look like they were the broken ones. Instead of saying "why was this accepted from its source?" the community reaction seemed more to me to be "hey, BGP is breaking the internet!" If -everyone- dropped the session on a bad attribute, it likely wouldn't make it far enough into the wild to cause these problems in the first place. -c From Valdis.Kletnieks at vt.edu Fri Aug 27 15:57:17 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Aug 2010 16:57:17 -0400 Subject: Did your BGP crash today? In-Reply-To: Your message of "Fri, 27 Aug 2010 13:43:39 PDT." References: <20100827191324.GJ1946@gerbil.cluepon.net> Message-ID: <6994.1282942637@localhost> On Fri, 27 Aug 2010 13:43:39 PDT, Clay Fiske said: > If -everyone- dropped the session on a bad attribute, it likely wouldn't > make it far enough into the wild to cause these problems in the first > place. That works fine for malformed attributes. It blows chunks for legally formed but unknown attributes - how would you ever deploy a new attribute? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From young at jsyoung.net Fri Aug 27 16:22:17 2010 From: young at jsyoung.net (Jeffrey S. Young) Date: Sat, 28 Aug 2010 07:22:17 +1000 Subject: Did your BGP crash today? In-Reply-To: <20100827191324.GJ1946@gerbil.cluepon.net> References: <20100827191324.GJ1946@gerbil.cluepon.net> Message-ID: <9CB29984-4158-4FAF-A17E-2342F8861A30@jsyoung.net> About the same time the operators get back into the IETF and become involved again. There was a time when operators played a large role in the development of things BGP (e.g. Tony Bates, Enke Chen, both at iMCI). No one is stopping us, the 'ivory tower' has no gate. jy On 28/08/2010, at 5:13 AM, Richard A Steenbergen wrote: > On Fri, Aug 27, 2010 at 01:29:15PM -0400, Jared Mauch wrote: >> >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) > > Just out of curiosity, at what point will we as operators rise up > against the ivory tower protocol designers at the IETF and demand that > they add a mechanism to not bring down the entire BGP session because of > a single malformed attribute? Did I miss the memo about the meeting? > I'll bring the punch and pie. > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > > From ras at e-gerbil.net Fri Aug 27 16:23:09 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 27 Aug 2010 16:23:09 -0500 Subject: Did your BGP crash today? In-Reply-To: References: <20100827191324.GJ1946@gerbil.cluepon.net> Message-ID: <20100827212309.GO1946@gerbil.cluepon.net> On Fri, Aug 27, 2010 at 01:43:39PM -0700, Clay Fiske wrote: > > If -everyone- dropped the session on a bad attribute, it likely > wouldn't make it far enough into the wild to cause these problems in > the first place. And if everyone filtered their BGP customers there would be no routing leaks, but we've seen how well that works. :) The "if anything bad happens, drop the session" method of protection is only effective if EVERY BGP implementation catches EVERY malformed update EVERY time, which just doesn't match up with reality. Not only that, but a healthy number of the bgp update issues over the years have actually been the result of implementations detecting perfectly valid things as invalid, which means by definition the implementations which get it right and don't drop the session act as carriers and spread the problem route globally. How long as we going to continue to act like this method of protection is actually working? Lets be reasonable, if your basic bgp message format is malformed you're going to need to drop the session. If the packet is corrupted or the size of the message doesn't match whats in the tlv, you're not going to be able to continue and you'll have to drop the session. But there are still a huge number of potential issues where it would be perfectly safe to drop the update you didn't like, and support for this could easily be negotiated and the sending side informed of the issue by a soft notification extension. I have yet to see a single argument against this which isn't political or philosophical in nature. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From khatfield at socllc.net Fri Aug 27 16:23:31 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Fri, 27 Aug 2010 21:23:31 +0000 Subject: Looking for Fiber Plant Management software In-Reply-To: <2F9F3B3F-B791-4A6F-AA25-AE138546BE45@lixfeld.ca> References: <56C21A0A-6907-4A1D-869D-38EDF9BE7D1F@briworks.com><2F9F3B3F-B791-4A6F-AA25-AE138546BE45@lixfeld.ca> Message-ID: <952980972-1282944212-cardhu_decombobulator_blackberry.rim.net-696758767-@bda903.bisx.prod.on.blackberry> Most of the ones I have seen (2 out of 3) were inhouse/home-grown solutions. I believe the other was provided by SA (Scientific Atlanta). I tried to do a quick search on it and it appears that product may now be provided by Cisco in partnership with SA. Best of luck -----Original Message----- From: Jason Lixfeld Date: Fri, 27 Aug 2010 12:13:35 To: Jeff Saxe Cc: Subject: Re: Looking for Fiber Plant Management software I've got a client who uses AutoCAD. They use it exclusively and have a pretty big fibre network for someone who's not an ILEC, so I guess it works fairly well. On 2010-08-27, at 11:39 AM, Jeff Saxe wrote: > Good morning, NANOGers. My colleague at work wonders if anyone has suggestions for software to database all our fiber plant that we're constructing. We started out with paper, then Excel spreadsheets in a folder and on paper in a book, but clearly as our plant grows and we do more splicing this is not going to scale. We have started a MySQL database with a few tables, but wonder if someone has already invented this wheel. > > What do the "big boys" use? Homegrown solutions developed in-house and jealously guarded? Something standard? Expensive or cheap? Free open-source? He'd like to see... > > outside plan facilities: cables, fibers, splice points, poles; copper and fiber, preferably, but fiber is more important > "circuit" or "DLR" that knows what elements are involved in a circuit > GIS integration so that cables can be drawn on a map automagically > low cost, of course > > Thanks in advance, everyone. > > -- Jeff Saxe, Network Engineer > Blue Ridge InternetWorks, Charlottesville, VA > 434-817-0707 ext. 2024 / JSaxe at briworks.com > > > > From jdevane at switchnap.com Fri Aug 27 16:31:57 2010 From: jdevane at switchnap.com (Jim Devane) Date: Fri, 27 Aug 2010 14:31:57 -0700 Subject: Looking for Fiber Plant Management software In-Reply-To: <952980972-1282944212-cardhu_decombobulator_blackberry.rim.net-696758767-@bda903.bisx.prod.on.blackberry> References: <56C21A0A-6907-4A1D-869D-38EDF9BE7D1F@briworks.com><2F9F3B3F-B791-4A6F-AA25-AE138546BE45@lixfeld.ca> <952980972-1282944212-cardhu_decombobulator_blackberry.rim.net-696758767-@bda903.bisx.prod.on.blackberry> Message-ID: <9B5D0FD163918D4A8913D243722B8F500296367FB7@WolfCreek.switchnet.nv> OSP Insight. Pricey but an excellent tool for OSP documentation. -----Original Message----- From: khatfield at socllc.net [mailto:khatfield at socllc.net] Sent: Friday, August 27, 2010 2:24 PM To: Jason Lixfeld; Jeff Saxe Cc: nanog at nanog.org Subject: Re: Looking for Fiber Plant Management software Most of the ones I have seen (2 out of 3) were inhouse/home-grown solutions. I believe the other was provided by SA (Scientific Atlanta). I tried to do a quick search on it and it appears that product may now be provided by Cisco in partnership with SA. Best of luck -----Original Message----- From: Jason Lixfeld Date: Fri, 27 Aug 2010 12:13:35 To: Jeff Saxe Cc: Subject: Re: Looking for Fiber Plant Management software I've got a client who uses AutoCAD. They use it exclusively and have a pretty big fibre network for someone who's not an ILEC, so I guess it works fairly well. On 2010-08-27, at 11:39 AM, Jeff Saxe wrote: > Good morning, NANOGers. My colleague at work wonders if anyone has suggestions for software to database all our fiber plant that we're constructing. We started out with paper, then Excel spreadsheets in a folder and on paper in a book, but clearly as our plant grows and we do more splicing this is not going to scale. We have started a MySQL database with a few tables, but wonder if someone has already invented this wheel. > > What do the "big boys" use? Homegrown solutions developed in-house and jealously guarded? Something standard? Expensive or cheap? Free open-source? He'd like to see... > > outside plan facilities: cables, fibers, splice points, poles; copper and fiber, preferably, but fiber is more important > "circuit" or "DLR" that knows what elements are involved in a circuit > GIS integration so that cables can be drawn on a map automagically > low cost, of course > > Thanks in advance, everyone. > > -- Jeff Saxe, Network Engineer > Blue Ridge InternetWorks, Charlottesville, VA > 434-817-0707 ext. 2024 / JSaxe at briworks.com > > > > From bmanning at vacation.karoshi.com Fri Aug 27 16:37:14 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 27 Aug 2010 21:37:14 +0000 Subject: Did your BGP crash today? In-Reply-To: References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> Message-ID: <20100827213714.GA13356@vacation.karoshi.com.> come on Chris, is the Internet an experiment or not? :) one would think that a responsible party would have made efforts to let others in the "playground" know they were going to try something different that could have ramifications on an unkown distribution of some code bases. I'm not asking my vendor or (in the case of OSS) me to run "full bit sweeps"... but a heads up to some of the known ops lists would have been not only welcome but expected. as usual, YMMV --bill On Fri, Aug 27, 2010 at 04:11:32PM -0400, Christopher Morrow wrote: > On Fri, Aug 27, 2010 at 4:07 PM, Mike Gatti wrote: > > where's the change management process in all of this. > > basically now we are going to starting changing things that can > > potentially have an adverse affect on users without letting anyone know > > before hand .... Interesting concept. > > you are running bgp, you are connected to the 'internet'... congrats > you are part of the experiment. > > I suppose one view is that "at least it wasn't someone with ill > intent, or a misconfigured mikrotek!" > > (you are asking your vendors to run full bit sweeps of each protocol > in a regimented manner checking for all possible edge cases and > properly handling them, right?) > > -chris > > > On Aug 27, 2010, at 3:33 PM, Dave Israel wrote: > > > >> > >> On 8/27/2010 3:22 PM, Jared Mauch wrote: > >>> When you are processing something, it's sometimes hard to tell if something > >>> just was mis-parsed (as I think the case is here with the "missing-2-bytes") > >>> vs just getting garbage. Perhaps there should be some way to "re-sync" when > >>> you are having this problem, or a parallel "keepalive" path similar to > >>> MACA/MCAS/MIDCAS/TCAS between the devices to talk when something bad is > >>> happening. > >> > >> I know it wasn't there originally, and isn't mandatory now, but there is > >> an MD5 hash that can be added to the packet. If the TCP hash checks > >> out, then you know the packet wasn't garbled, and just contained > >> information you didn't grok. That seems like enough evidence to be able > >> to shrug and toss the packet without dropping the session. > >> > >> -Dave > >> > >> > >> > > > > =+=+=+=+=+=+=+=+=+=+=+=+= > > Mike Gatti > > ekim.ittag at gmail.com > > =+=+=+=+=+=+=+=+=+=+=+=+= > > > > > > > > > > > From cjeker at diehard.n-r-g.com Fri Aug 27 16:43:56 2010 From: cjeker at diehard.n-r-g.com (Claudio Jeker) Date: Fri, 27 Aug 2010 23:43:56 +0200 Subject: Did your BGP crash today? In-Reply-To: <6994.1282942637@localhost> References: <20100827191324.GJ1946@gerbil.cluepon.net> <6994.1282942637@localhost> Message-ID: <20100827214356.GA3618@diehard.n-r-g.com> On Fri, Aug 27, 2010 at 04:57:17PM -0400, Valdis.Kletnieks at vt.edu wrote: > On Fri, 27 Aug 2010 13:43:39 PDT, Clay Fiske said: > > > If -everyone- dropped the session on a bad attribute, it likely wouldn't > > make it far enough into the wild to cause these problems in the first > > place. > > That works fine for malformed attributes. It blows chunks for legally formed > but unknown attributes - how would you ever deploy a new attribute? > This is covered by the RFC. Unknown attributes are either dropped or passed on depending on the attribute flags. The problem as in AS4 was that there where illegally formed unknown attributes that got passed around and made RFC compliant routers, which already handled AS4, further down the chain fail. This problem was addressed in "Error Handling for Optional Transitive BGP Attributes" but for some reasons people think it is necessary to make something simple more and more complex so this draft is still pending. -- :wq Claudio From cidr-report at potaroo.net Fri Aug 27 17:00:02 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Aug 2010 22:00:02 GMT Subject: BGP Update Report Message-ID: <201008272200.o7RM02Oq085939@wattle.apnic.net> BGP Update Report Interval: 19-Aug-10 -to- 26-Aug-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS5416 63690 4.3% 513.6 -- BATELCO-BH 2 - AS3464 25712 1.7% 1836.6 -- ASC-NET - Alabama Supercomputer Network 3 - AS32528 18622 1.3% 4655.5 -- ABBOTT Abbot Labs 4 - AS28573 17201 1.2% 16.8 -- NET Servicos de Comunicao S.A. 5 - AS35931 14837 1.0% 2472.8 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - AS5536 14735 1.0% 136.4 -- Internet-Egypt 7 - AS16814 14708 1.0% 21.6 -- NSS S.A. 8 - AS9829 12047 0.8% 51.7 -- BSNL-NIB National Internet Backbone 9 - AS7552 11561 0.8% 13.3 -- VIETEL-AS-AP Vietel Corporation 10 - AS11351 11536 0.8% 36.0 -- RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 11 - AS13880 11319 0.8% 1617.0 -- ACI-AS - american century investments 12 - AS5800 11102 0.8% 59.1 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 13 - AS8151 10794 0.7% 15.2 -- Uninet S.A. de C.V. 14 - AS35567 10169 0.7% 95.9 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 15 - AS10474 9991 0.7% 525.8 -- NETACTIVE 16 - AS14420 9788 0.7% 17.7 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 17 - AS45464 8824 0.6% 245.1 -- NEXTWEB-AS-AP Room 201, TGU Bldg 18 - AS21017 7692 0.5% 769.2 -- VSI-AS VSI AS 19 - AS34984 7533 0.5% 26.3 -- TELLCOM-AS Tellcom Iletisim Hizmetleri 20 - AS3816 7497 0.5% 28.4 -- COLOMBIA TELECOMUNICACIONES S.A. ESP TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 18622 1.3% 4655.5 -- ABBOTT Abbot Labs 2 - AS35931 14837 1.0% 2472.8 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 3 - AS3464 25712 1.7% 1836.6 -- ASC-NET - Alabama Supercomputer Network 4 - AS13880 11319 0.8% 1617.0 -- ACI-AS - american century investments 5 - AS53532 1270 0.1% 1270.0 -- KINGMETALS - King Architectural Metals 6 - AS48565 926 0.1% 926.0 -- POCZTAPOLSKA-AS Poczta Polska Spolka Akcyjna 7 - AS27027 882 0.1% 882.0 -- ANBELL ASN-ANBELL 8 - AS21017 7692 0.5% 769.2 -- VSI-AS VSI AS 9 - AS11613 710 0.1% 710.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 10 - AS45542 1401 0.1% 700.5 -- VNU-AS-VN VietNam National University Ha Noi 11 - AS50010 1980 0.1% 660.0 -- NAWRAS-AS Omani Qatari Telecommunications Company SAOC 12 - AS10474 9991 0.7% 525.8 -- NETACTIVE 13 - AS5416 63690 4.3% 513.6 -- BATELCO-BH 14 - AS16861 460 0.0% 460.0 -- REVELEX - Revelex.com 15 - AS16718 4511 0.3% 451.1 -- EMBARQ-HMBL - Embarq Corporation 16 - AS15984 439 0.0% 439.0 -- The Joint-Stock Commercial Bank CentroCredit. 17 - AS49493 423 0.0% 423.0 -- SVT-AS SVT-Proveedor de Servicios de Internet 18 - AS20817 423 0.0% 423.0 -- DELTANET-AS Deltanet Autonomous System 19 - AS22580 370 0.0% 370.0 -- GUARD - GUARD INSURANCE GROUP 20 - AS43055 1793 0.1% 358.6 -- KATRINA-AS CJSC Katrina TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 129.66.128.0/17 12834 0.8% AS3464 -- ASC-NET - Alabama Supercomputer Network 2 - 129.66.0.0/17 12825 0.8% AS3464 -- ASC-NET - Alabama Supercomputer Network 3 - 196.2.16.0/24 9859 0.6% AS10474 -- NETACTIVE 4 - 130.36.34.0/24 9262 0.6% AS32528 -- ABBOTT Abbot Labs 5 - 130.36.35.0/24 9262 0.6% AS32528 -- ABBOTT Abbot Labs 6 - 63.211.68.0/22 8599 0.6% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 7 - 148.204.141.0/24 6213 0.4% AS8151 -- Uninet S.A. de C.V. 8 - 198.140.43.0/24 6188 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 9 - 190.65.228.0/22 5779 0.4% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 10 - 216.126.136.0/22 4947 0.3% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 11 - 84.255.152.0/24 4090 0.3% AS5416 -- BATELCO-BH 12 - 84.255.146.0/24 4082 0.3% AS5416 -- BATELCO-BH 13 - 84.255.145.0/24 4082 0.3% AS5416 -- BATELCO-BH 14 - 84.255.147.0/24 4082 0.3% AS5416 -- BATELCO-BH 15 - 95.32.128.0/18 3851 0.2% AS21017 -- VSI-AS VSI AS 16 - 95.32.192.0/18 3659 0.2% AS21017 -- VSI-AS VSI AS 17 - 206.184.16.0/24 3066 0.2% AS174 -- COGENT Cogent/PSI 18 - 77.69.143.0/24 2932 0.2% AS5416 -- BATELCO-BH 19 - 77.69.190.0/24 2932 0.2% AS5416 -- BATELCO-BH 20 - 77.69.142.0/24 2932 0.2% AS5416 -- BATELCO-BH Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Aug 27 17:00:01 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Aug 2010 22:00:01 GMT Subject: The Cidr Report Message-ID: <201008272200.o7RM01Cm085930@wattle.apnic.net> This report has been generated at Fri Aug 27 21:12:04 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 Prefixes CIDR Agg 20-08-10 333340 205848 21-08-10 332999 206105 22-08-10 333406 206219 23-08-10 333522 206203 24-08-10 333578 206571 25-08-10 333874 206667 26-08-10 333708 206713 27-08-10 333965 206728 AS Summary 35248 Number of ASes in routing system 14995 Number of ASes announcing only one prefix 4451 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 97263040 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'). --- 27Aug10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 334389 206722 127667 38.2% All ASes AS6389 3843 282 3561 92.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4451 1872 2579 57.9% TWTC - tw telecom holdings, inc. AS19262 1802 276 1526 84.7% VZGNI-TRANSIT - Verizon Online LLC AS4766 1866 512 1354 72.6% KIXS-AS-KR Korea Telecom AS22773 1180 66 1114 94.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1482 431 1051 70.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS5668 1131 89 1042 92.1% AS-5668 - CenturyTel Internet Holdings, Inc. AS17488 1342 302 1040 77.5% HATHWAY-NET-AP Hathway IP Over Cable Internet AS18566 1087 63 1024 94.2% COVAD - Covad Communications Co. AS6478 1308 372 936 71.6% ATT-INTERNET3 - AT&T WorldNet Services AS8151 1526 635 891 58.4% Uninet S.A. de C.V. AS1785 1791 960 831 46.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS10620 1102 290 812 73.7% Telmex Colombia S.A. AS8452 1147 425 722 62.9% TEDATA TEDATA AS7545 1407 721 686 48.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS7303 791 115 676 85.5% Telecom Argentina S.A. AS4808 917 290 627 68.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS13343 977 357 620 63.5% SCRR-13343 - Road Runner HoldCo LLC AS4804 678 73 605 89.2% MPX-AS Microplex PTY LTD AS7552 654 114 540 82.6% VIETEL-AS-AP Vietel Corporation AS17676 605 77 528 87.3% GIGAINFRA Softbank BB Corp. AS4780 685 161 524 76.5% SEEDNET Digital United Inc. AS7018 1470 953 517 35.2% ATT-INTERNET4 - AT&T WorldNet Services AS7011 1136 659 477 42.0% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS24560 1002 525 477 47.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS14420 553 78 475 85.9% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS22047 551 78 473 85.8% VTR BANDA ANCHA S.A. AS3356 1145 675 470 41.0% LEVEL3 Level 3 Communications AS28573 1025 566 459 44.8% NET Servicos de Comunicao S.A. AS36992 661 211 450 68.1% ETISALAT-MISR Total 39315 12228 27087 68.9% Top 30 total Possible Bogus Routes 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.189.0/24 AS6453 GLOBEINTERNET TATA Communications 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 46.44.128.0/18 AS28685 ASN-ROUTIT Routit BV EDE The Netherlands 49.0.0.0/8 AS38639 HANABI NTT Communications Corporation 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 101.0.0.0/8 AS38639 HANABI NTT Communications Corporation 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 116.68.136.0/21 AS28045 Pantel Communications 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.51.100.0/24 AS16953 ASCENT-MEDIA-GROUP-LLC - Ascent Media Group, LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS WIS S.A. : WIND International Services 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 204.238.70.0/24 AS36826 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.196.24.0/22 AS33724 BIZNESSHOSTING - VOLICO 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.72.192.0/23 AS27375 IDS-TELECOM - IDS Telecom 206.72.194.0/23 AS27375 IDS-TELECOM - IDS Telecom 206.72.196.0/23 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 206.72.208.0/24 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.209.0/24 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 208.84.76.0/22 AS18561 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From warren at kumari.net Fri Aug 27 17:20:01 2010 From: warren at kumari.net (Warren Kumari) Date: Fri, 27 Aug 2010 18:20:01 -0400 Subject: Did your BGP crash today? In-Reply-To: <20100827213714.GA13356@vacation.karoshi.com.> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100827213714.GA13356@vacation.karoshi.com.> Message-ID: <70B436DB-9705-454F-907D-854D2C20B706@kumari.net> On Aug 27, 2010, at 5:37 PM, bmanning at vacation.karoshi.com wrote: > > come on Chris, is the Internet an experiment or not? :) > one would think that a responsible party would have made > efforts to let others in the "playground" know they were > going to try something different that could have ramifications > on an unkown distribution of some code bases. I'm assuming that they weren't really expecting this to cause issues... Where does one draw the line? I'm planning on announcing x.y.z.0/20 later in the week -- x, y and z are all prime and the sum of all 3 is also a prime. There is a non-zero chance that something somewhere will go flooie, shall I send mail now or later? Also, I would prefer that this gets discovered and dealt with (in this case by stopping the announcement :-)) than having folk not willing to try things and ending up with a weaponized version... W > > I'm not asking my vendor or (in the case of OSS) me to run > "full bit sweeps"... but a heads up to some of the known > ops lists would have been not only welcome but expected. > > as usual, YMMV > > --bill > > > On Fri, Aug 27, 2010 at 04:11:32PM -0400, Christopher Morrow wrote: >> On Fri, Aug 27, 2010 at 4:07 PM, Mike Gatti >> wrote: >>> where's the change management process in all of this. >>> basically now we are going to starting changing things that can >>> potentially have an adverse affect on users without letting anyone >>> know >>> before hand .... Interesting concept. >> >> you are running bgp, you are connected to the 'internet'... congrats >> you are part of the experiment. >> >> I suppose one view is that "at least it wasn't someone with ill >> intent, or a misconfigured mikrotek!" >> >> (you are asking your vendors to run full bit sweeps of each protocol >> in a regimented manner checking for all possible edge cases and >> properly handling them, right?) >> >> -chris >> >>> On Aug 27, 2010, at 3:33 PM, Dave Israel wrote: >>> >>>> >>>> On 8/27/2010 3:22 PM, Jared Mauch wrote: >>>>> When you are processing something, it's sometimes hard to tell >>>>> if something >>>>> just was mis-parsed (as I think the case is here with the >>>>> "missing-2-bytes") >>>>> vs just getting garbage. Perhaps there should be some way to >>>>> "re-sync" when >>>>> you are having this problem, or a parallel "keepalive" path >>>>> similar to >>>>> MACA/MCAS/MIDCAS/TCAS between the devices to talk when something >>>>> bad is >>>>> happening. >>>> >>>> I know it wasn't there originally, and isn't mandatory now, but >>>> there is >>>> an MD5 hash that can be added to the packet. If the TCP hash >>>> checks >>>> out, then you know the packet wasn't garbled, and just contained >>>> information you didn't grok. That seems like enough evidence to >>>> be able >>>> to shrug and toss the packet without dropping the session. >>>> >>>> -Dave >>>> >>>> >>>> >>> >>> =+=+=+=+=+=+=+=+=+=+=+=+= >>> Mike Gatti >>> ekim.ittag at gmail.com >>> =+=+=+=+=+=+=+=+=+=+=+=+= >>> >>> >>> >>> >>> >> > -- What our ancestors would really be thinking, if they were alive today, is: "Why is it so dark in here?" -- (Terry Pratchett, Pyramids) From psirt at cisco.com Fri Aug 27 19:00:00 2010 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Fri, 27 Aug 2010 20:00:00 -0400 Subject: Cisco Security Advisory: Cisco IOS XR Software Border Gateway Protocol Vulnerability Message-ID: <201008272000.bgp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS XR Software Border Gateway Protocol Vulnerability Advisory ID: cisco-sa-20100827-bgp Revision 1.0 For Public Release 2010 August 27 2200 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Cisco IOS XR Software contains a vulnerability in the Border Gateway Protocol (BGP) feature. The vulnerability manifests itself when a BGP peer announces a prefix with a specific, valid but unrecognized transitive attribute. On receipt of this prefix, the Cisco IOS XR device will corrupt the attribute before sending it to the neighboring devices. Neighboring devices that receive this corrupted update may reset the BGP peering session. Affected devices running Cisco IOS XR Software corrupt the unrecognized attribute before sending to neighboring devices, but neighboring devices may be running operating systems other than Cisco IOS XR Software and may still reset the BGP peering session after receiving the corrupted update. This is per standards defining the operation of BGP. Cisco developed a fix that addresses this vulnerability and will be releasing free software maintenance upgrades (SMU) progressively starting 28 August 2010. This advisory will be updated accordingly as fixes become available. This advisory is posted at: http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml Affected Products ================= This vulnerability affects all Cisco IOS XR Software devices configured with BGP routing. Vulnerable Products +------------------ To determine the Cisco IOS XR Software release that is running on a Cisco product, administrators can log in to the device and issue the "show version" command to display the system banner. The system banner confirms that the device is running Cisco IOS XR Software by displaying text similar to "Cisco IOS XR Software". The software version is displayed after the text "Cisco IOS XR Software". The following example identifies a Cisco CRS-1 that is running Cisco IOS XR Software Release 3.6.2: RP/0/RP0/CPU0:CRS#show version Tue Aug 18 14:25:17.407 AEST Cisco IOS XR Software, Version 3.6.2[00] Copyright (c) 2008 by Cisco Systems, Inc. ROM: System Bootstrap, Version 1.49(20080319:195807) [CRS-1 ROMMON], CRS uptime is 4 weeks, 4 days, 1 minute System image file is "disk0:hfr-os-mbi-3.6.2/mbihfr-rp.vm" cisco CRS-8/S (7457) processor with 4194304K bytes of memory. 7457 processor at 1197Mhz, Revision 1.2 17 Packet over SONET/SDH network interface(s) 1 DWDM controller(s) 17 SONET/SDH Port controller(s) 8 TenGigabitEthernet/IEEE 802.3 interface(s) 2 Ethernet/IEEE 802.3 interface(s) 1019k bytes of non-volatile configuration memory. 38079M bytes of hard disk. 981440k bytes of ATA PCMCIA card at disk 0 (Sector size 512 bytes). Configuration register on node 0/0/CPU0 is 0x102 Boot device on node 0/0/CPU0 is mem: !--- output truncated The following example identifies a Cisco 12404 router that is running Cisco IOS XR Software Release 3.7.1: RP/0/0/CPU0:GSR#show version Cisco IOS XR Software, Version 3.7.1[00] Copyright (c) 2008 by Cisco Systems, Inc. ROM: System Bootstrap, Version 12.0(20051020:160303) SOFTWARE Copyright (c) 1994-2005 by cisco Systems, Inc. GSR uptime is 3 weeks, 6 days, 3 hours, 20 minutes System image file is "disk0:c12k-os-mbi-3.7.1/mbiprp-rp.vm" cisco 12404/PRP (7457) processor with 2097152K bytes of memory. 7457 processor at 1266Mhz, Revision 1.2 1 Cisco 12000 Series Performance Route Processor 1 Cisco 12000 Series - Multi-Service Blade Controller 1 1 Port ISE Packet Over SONET OC-48c/STM-16 Controller (1 POS) 1 Cisco 12000 Series SPA Interface Processor-601/501/401 3 Ethernet/IEEE 802.3 interface(s) 1 SONET/SDH Port controller(s) 1 Packet over SONET/SDH network interface(s) 4 PLIM QoS controller(s) 8 FastEthernet/IEEE 802.3 interface(s) 1016k bytes of non-volatile configuration memory. 1000496k bytes of disk0: (Sector size 512 bytes). 65536k bytes of Flash internal SIMM (Sector size 256k). Configuration register on node 0/0/CPU0 is 0x2102 Boot device on node 0/0/CPU0 is disk0: !--- output truncated Additional information about Cisco IOS XR Software release naming conventions is available in the "White Paper: Cisco IOS Reference Guide" at the following link: http://www.cisco.com/web/about/security/intelligence/ios-ref.html#9 Additional information about Cisco IOS XR Software time-based release model is available in the "White Paper: Guidelines for Cisco IOS XR Software" at the following link: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8803/ps5845/product_bulletin_c25-478699.html BGP is configured in Cisco IOS XR Software with the configuration command "router bgp [AS Number]" or "router bgp [X.Y]". The device is vulnerable if it is running an affected Cisco IOS XR Software version and has BGP configured. The following example shows a Cisco IOS XR Software device configured with BGP: RP/0/0/CPU0:GSR#show running-config | begin router bgp Building configuration... router bgp 65535 bgp router-id 192.168.0.1 address-family ipv4 unicast network 192.168.1.1/32 ! address-family vpnv4 unicast ! neighbor 192.168.2.1 remote-as 65534 update-source Loopback0 address-family ipv4 unicast ! !--- output truncated Products Confirmed Not Vulnerable +-------------------------------- The following Cisco products are confirmed not vulnerable: * Cisco IOS Software * Cisco IOS XR Software not configured for BGP routing No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= This vulnerability affects Cisco IOS XR devices running affected software versions and configured with the BGP routing feature. The vulnerability manifests itself when a BGP peer announces a prefix with a specific, valid but unrecognized transitive attribute. On receipt of this prefix, the Cisco IOS XR device will corrupt the attribute before sending it to the neighboring devices. Neighboring devices that receive this corrupted update may reset the BGP peering session. Affected devices running Cisco IOS XR Software corrupt the unrecognized attribute before sending to neighboring devices, but neighboring devices may be running operating systems other than Cisco IOS XR Software and may still reset the BGP peering session after receiving the corrupted update. This is per RFC 4271 that defines the operation of BGP. After an affected device running Cisco IOS XR Software sends a corrupted update, it will receive a notification from the neighboring router and will create a log message like the following example: bgp[122]: %ROUTING-BGP-5-ADJCHANGE : neighbor 172.16.1.251 Down - BGP Notification received: update malformed This vulnerability is documented in Cisco Bug ID CSCti62211 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2010-3035. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at: http://intellishield.cisco.com/security/alertmanager/cvss CSCti62211 - BGP flaps due to unknown attribute CVSS Base Score - 5 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Partial CVSS Temporal Score - 4.8 Exploitability - Functional Remediation Level - Unavailable Report Confidence - Confirmed Impact ====== Successful exploitation of these vulnerabilities may result in the continuous resetting of BGP peering sessions. This may lead to routing inconsistencies and a denial of service for those affected networks. Software Versions and Fixes =========================== When considering software upgrades, also consult: http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. +-------------------------------------------------------------------+ | Cisco IOS XR | SMU ID | SMU | Requires | | Version | | Name | Reload | |---------------+------------------------------+-------+------------| | 3.4.0 | Vulnerable; Migrate to 3.4.3 | | | | | and apply a SMU | | | |---------------+------------------------------+-------+------------| | 3.4.1 | SMU will be available on | | | | | 2010-Sep-9 | | | |---------------+------------------------------+-------+------------| | 3.4.2 | SMU will be available on | | | | | 2010-Sep-9 | | | |---------------+------------------------------+-------+------------| | 3.4.3 | SMU will be available on | | | | | 2010-Sep-5 | | | |---------------+------------------------------+-------+------------| | 3.5.2 | SMU will be available on | | | | | 2010-Sep-5 | | | |---------------+------------------------------+-------+------------| | 3.5.3 | SMU will be available on | | | | | 2010-Sep-9 | | | |---------------+------------------------------+-------+------------| | 3.5.4 | SMU will be available on | | | | | 2010-Sep-5 | | | |---------------+------------------------------+-------+------------| | 3.6.0 | SMU will be available on | | | | | 2010-Sep-9 | | | |---------------+------------------------------+-------+------------| | 3.6.1 | SMU will be available on | | | | | 2010-Sep-3 | | | |---------------+------------------------------+-------+------------| | 3.6.2 | SMU will be available on | | | | | 2010-Aug-30 | | | |---------------+------------------------------+-------+------------| | 3.6.3 | SMU will be available on | | | | | 2010-Sep-3 | | | |---------------+------------------------------+-------+------------| | 3.7.0 | SMU will be available on | | | | | 2010-Sep-9 | | | |---------------+------------------------------+-------+------------| | 3.7.1 | SMU will be available on | | | | | 2010-Sep-1 | | | |---------------+------------------------------+-------+------------| | 3.7.2 | SMU will be available on | | | | | 2010-Sep-3 | | | |---------------+------------------------------+-------+------------| | 3.7.3 | SMU will be available on | | | | | 2010-Sep-3 | | | |---------------+------------------------------+-------+------------| | 3.8.0 | SMU will be available on | | | | | 2010-Sep-3 | | | |---------------+------------------------------+-------+------------| | 3.8.1 | SMU will be available on | | | | | 2010-Sep-3 | | | |---------------+------------------------------+-------+------------| | 3.8.2 | SMU will be available on | | | | | 2010-Aug-30 | | | |---------------+------------------------------+-------+------------| | 3.8.3 | SMU will be available on | | | | | 2010-Sep-1 | | | |---------------+------------------------------+-------+------------| | 3.8.4 | SMU will be available on | | | | | 2010-Aug-28 | | | |---------------+------------------------------+-------+------------| | 3.9.0 | SMU will be available on | | | | | 2010-Sep-1 | | | |---------------+------------------------------+-------+------------| | 3.9.1 | SMU will be available on | | | | | 2010-Aug-28 | | | +-------------------------------------------------------------------+ Workarounds =========== There are no workarounds to proactively mitigate this vulnerability. If a route flap is observed, the prefix with the unrecognized attribute can be filtered. For further information on filtering on Cisco IOS XR Software, please consult the document "Implementing Routing Policy on Cisco IOS XR Software" at the following link: http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.0/routing/configuration/guide/rc3rpl.html#wp1118699 Obtaining Fixed Software ======================== Cisco is releasing free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at: http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html or as otherwise set forth at Cisco.com Downloads at: http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at: http://www.cisco.com Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to: http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== An advertisement of an unrecognized but valid BGP attribute resulted in resetting of several BGP neighbors on 27 August 2010. This advertisement was not malicious but inadvertently triggered this vulnerability. The Cisco PSIRT is not aware of malicious use of the vulnerability described in this advisory. Status of this Notice: INTERIM ============================== THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. CISCO EXPECTS TO UPDATE THIS DOCUMENT AS NEW INFORMATION BECOMES AVAILABLE. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at: http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +---------------------------------------+ | Revision | | Initial | | 1.0 | 2010-August-27 | public | | | | release | +---------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at: http://www.cisco.com/go/psirt -----BEGIN PGP SIGNATURE----- iD8DBQFMeEy786n/Gc8U/uARAqyeAJ9HEbSnJ9yCTiKU6HxbWnuEL1wicQCfRKdZ kv4pt8GHYDABNcIjbvGHYso= =mbwY -----END PGP SIGNATURE----- From clay at bloomcounty.org Fri Aug 27 19:02:51 2010 From: clay at bloomcounty.org (Clay Fiske) Date: Fri, 27 Aug 2010 17:02:51 -0700 Subject: Did your BGP crash today? In-Reply-To: <6994.1282942637@localhost> References: <20100827191324.GJ1946@gerbil.cluepon.net> <6994.1282942637@localhost> Message-ID: <7B046C10-9C88-454C-8CC7-608A814C7E64@bloomcounty.org> On Aug 27, 2010, at 1:57 PM, Valdis.Kletnieks at vt.edu wrote: > On Fri, 27 Aug 2010 13:43:39 PDT, Clay Fiske said: > >> If -everyone- dropped the session on a bad attribute, it likely wouldn't >> make it far enough into the wild to cause these problems in the first >> place. > > That works fine for malformed attributes. It blows chunks for legally formed > but unknown attributes - how would you ever deploy a new attribute? By making it optional. Seems to me that's pretty well covered by the Path Attributes section of the RFC. A bad attribute isn't simply unknown, it's malformed. My apologies for not wording that more precisely. I do see the wisdom of fine-grained control of this behavior. I'm just saying, it'd be nice if we could have correct behavior on the basics in the first place. :) -c From fergdawgster at gmail.com Fri Aug 27 19:08:01 2010 From: fergdawgster at gmail.com (Paul Ferguson) Date: Fri, 27 Aug 2010 17:08:01 -0700 Subject: Did your BGP crash today? In-Reply-To: <7B046C10-9C88-454C-8CC7-608A814C7E64@bloomcounty.org> References: <20100827191324.GJ1946@gerbil.cluepon.net> <6994.1282942637@localhost> <7B046C10-9C88-454C-8CC7-608A814C7E64@bloomcounty.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Aug 27, 2010 at 5:02 PM, Clay Fiske wrote: > > On Aug 27, 2010, at 1:57 PM, Valdis.Kletnieks at vt.edu wrote: > >> >> That works fine for malformed attributes. It blows chunks for legally >> formed but unknown attributes - how would you ever deploy a new >> attribute? > > By making it optional. Seems to me that's pretty well covered by the Path > Attributes section of the RFC. > > A bad attribute isn't simply unknown, it's malformed. My apologies for > not wording that more precisely. > > I do see the wisdom of fine-grained control of this behavior. I'm just > saying, it'd be nice if we could have correct behavior on the basics in > the first place. :) > As an aside, I see that Cisco has released a late Friday afternoon security advisory on this issue: http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml FYI, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMeFNZq1pz9mNUZTMRAkR9AJ9cTz71N5/RMaQFD6LsumKLhpfASACdHrBR 4uQ0+oes21gvTS5IVJZXMds= =5wqD -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From cmadams at hiwaay.net Fri Aug 27 22:05:02 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 27 Aug 2010 22:05:02 -0500 Subject: Did your BGP crash today? In-Reply-To: References: <20100827191324.GJ1946@gerbil.cluepon.net> <6994.1282942637@localhost> <7B046C10-9C88-454C-8CC7-608A814C7E64@bloomcounty.org> Message-ID: <20100828030502.GC879856@hiwaay.net> Once upon a time, Paul Ferguson said: > As an aside, I see that Cisco has released a late Friday afternoon security > advisory on this issue: Huh, I had an upstream (with Cisco gear on their end) do "URGENT maintenance" last night with less than 12 hours notice. I wonder if this is why... -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From randy at psg.com Fri Aug 27 22:16:59 2010 From: randy at psg.com (Randy Bush) Date: Sat, 28 Aug 2010 12:16:59 +0900 Subject: Did your BGP crash today? In-Reply-To: <20100827191324.GJ1946@gerbil.cluepon.net> References: <20100827191324.GJ1946@gerbil.cluepon.net> Message-ID: > Just out of curiosity, at what point will we as operators rise up > against the ivory tower protocol designers at the IETF and demand that > they add a mechanism to not bring down the entire BGP session because > of a single malformed attribute? there is a problem underlying this. bgp is not tlv. so once a parser detects an error, it can not *rigorously* know where to take up again. randy From grobe0ba at gmail.com Fri Aug 27 22:17:26 2010 From: grobe0ba at gmail.com (Atticus) Date: Fri, 27 Aug 2010 23:17:26 -0400 Subject: Did your BGP crash today? Message-ID: One of the affected platforms. I think it has info on IOS patches for it. I didn't read all of it as I don't have any Cisco products. ---------- Forwarded message ---------- From: Cisco Systems Product Security Incident Response Team Date: Fri, Aug 27, 2010 at 8:00 PM Subject: Cisco Security Advisory: Cisco IOS XR Software Border Gateway Protocol Vulnerability To: nanog at merit.edu Cc: psirt at cisco.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS XR Software Border Gateway Protocol Vulnerability Advisory ID: cisco-sa-20100827-bgp Revision 1.0 For Public Release 2010 August 27 2200 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Cisco IOS XR Software contains a vulnerability in the Border Gateway Protocol (BGP) feature. The vulnerability manifests itself when a BGP peer announces a prefix with a specific, valid but unrecognized transitive attribute. On receipt of this prefix, the Cisco IOS XR device will corrupt the attribute before sending it to the neighboring devices. Neighboring devices that receive this corrupted update may reset the BGP peering session. Affected devices running Cisco IOS XR Software corrupt the unrecognized attribute before sending to neighboring devices, but neighboring devices may be running operating systems other than Cisco IOS XR Software and may still reset the BGP peering session after receiving the corrupted update. This is per standards defining the operation of BGP. Cisco developed a fix that addresses this vulnerability and will be releasing free software maintenance upgrades (SMU) progressively starting 28 August 2010. This advisory will be updated accordingly as fixes become available. This advisory is posted at: http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml Affected Products ================= This vulnerability affects all Cisco IOS XR Software devices configured with BGP routing. Vulnerable Products +------------------ To determine the Cisco IOS XR Software release that is running on a Cisco product, administrators can log in to the device and issue the "show version" command to display the system banner. The system banner confirms that the device is running Cisco IOS XR Software by displaying text similar to "Cisco IOS XR Software". The software version is displayed after the text "Cisco IOS XR Software". The following example identifies a Cisco CRS-1 that is running Cisco IOS XR Software Release 3.6.2: RP/0/RP0/CPU0:CRS#show version Tue Aug 18 14:25:17.407 AEST Cisco IOS XR Software, Version 3.6.2[00] Copyright (c) 2008 by Cisco Systems, Inc. ROM: System Bootstrap, Version 1.49(20080319:195807) [CRS-1 ROMMON], CRS uptime is 4 weeks, 4 days, 1 minute System image file is "disk0:hfr-os-mbi-3.6.2/mbihfr-rp.vm" cisco CRS-8/S (7457) processor with 4194304K bytes of memory. 7457 processor at 1197Mhz, Revision 1.2 17 Packet over SONET/SDH network interface(s) 1 DWDM controller(s) 17 SONET/SDH Port controller(s) 8 TenGigabitEthernet/IEEE 802.3 interface(s) 2 Ethernet/IEEE 802.3 interface(s) 1019k bytes of non-volatile configuration memory. 38079M bytes of hard disk. 981440k bytes of ATA PCMCIA card at disk 0 (Sector size 512 bytes). Configuration register on node 0/0/CPU0 is 0x102 Boot device on node 0/0/CPU0 is mem: !--- output truncated The following example identifies a Cisco 12404 router that is running Cisco IOS XR Software Release 3.7.1: RP/0/0/CPU0:GSR#show version Cisco IOS XR Software, Version 3.7.1[00] Copyright (c) 2008 by Cisco Systems, Inc. ROM: System Bootstrap, Version 12.0(20051020:160303) SOFTWARE Copyright (c) 1994-2005 by cisco Systems, Inc. GSR uptime is 3 weeks, 6 days, 3 hours, 20 minutes System image file is "disk0:c12k-os-mbi-3.7.1/mbiprp-rp.vm" cisco 12404/PRP (7457) processor with 2097152K bytes of memory. 7457 processor at 1266Mhz, Revision 1.2 1 Cisco 12000 Series Performance Route Processor 1 Cisco 12000 Series - Multi-Service Blade Controller 1 1 Port ISE Packet Over SONET OC-48c/STM-16 Controller (1 POS) 1 Cisco 12000 Series SPA Interface Processor-601/501/401 3 Ethernet/IEEE 802.3 interface(s) 1 SONET/SDH Port controller(s) 1 Packet over SONET/SDH network interface(s) 4 PLIM QoS controller(s) 8 FastEthernet/IEEE 802.3 interface(s) 1016k bytes of non-volatile configuration memory. 1000496k bytes of disk0: (Sector size 512 bytes). 65536k bytes of Flash internal SIMM (Sector size 256k). Configuration register on node 0/0/CPU0 is 0x2102 Boot device on node 0/0/CPU0 is disk0: !--- output truncated Additional information about Cisco IOS XR Software release naming conventions is available in the "White Paper: Cisco IOS Reference Guide" at the following link: http://www.cisco.com/web/about/security/intelligence/ios-ref.html#9 Additional information about Cisco IOS XR Software time-based release model is available in the "White Paper: Guidelines for Cisco IOS XR Software" at the following link: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8803/ps5845/product_bulletin_c25-478699.html BGP is configured in Cisco IOS XR Software with the configuration command "router bgp [AS Number]" or "router bgp [X.Y]". The device is vulnerable if it is running an affected Cisco IOS XR Software version and has BGP configured. The following example shows a Cisco IOS XR Software device configured with BGP: RP/0/0/CPU0:GSR#show running-config | begin router bgp Building configuration... router bgp 65535 bgp router-id 192.168.0.1 address-family ipv4 unicast network 192.168.1.1/32 ! address-family vpnv4 unicast ! neighbor 192.168.2.1 remote-as 65534 update-source Loopback0 address-family ipv4 unicast ! !--- output truncated Products Confirmed Not Vulnerable +-------------------------------- The following Cisco products are confirmed not vulnerable: * Cisco IOS Software * Cisco IOS XR Software not configured for BGP routing No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= This vulnerability affects Cisco IOS XR devices running affected software versions and configured with the BGP routing feature. The vulnerability manifests itself when a BGP peer announces a prefix with a specific, valid but unrecognized transitive attribute. On receipt of this prefix, the Cisco IOS XR device will corrupt the attribute before sending it to the neighboring devices. Neighboring devices that receive this corrupted update may reset the BGP peering session. Affected devices running Cisco IOS XR Software corrupt the unrecognized attribute before sending to neighboring devices, but neighboring devices may be running operating systems other than Cisco IOS XR Software and may still reset the BGP peering session after receiving the corrupted update. This is per RFC 4271 that defines the operation of BGP. After an affected device running Cisco IOS XR Software sends a corrupted update, it will receive a notification from the neighboring router and will create a log message like the following example: bgp[122]: %ROUTING-BGP-5-ADJCHANGE : neighbor 172.16.1.251 Down - BGP Notification received: update malformed This vulnerability is documented in Cisco Bug ID CSCti62211 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2010-3035. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at: http://intellishield.cisco.com/security/alertmanager/cvss CSCti62211 - BGP flaps due to unknown attribute CVSS Base Score - 5 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Partial CVSS Temporal Score - 4.8 Exploitability - Functional Remediation Level - Unavailable Report Confidence - Confirmed Impact ====== Successful exploitation of these vulnerabilities may result in the continuous resetting of BGP peering sessions. This may lead to routing inconsistencies and a denial of service for those affected networks. Software Versions and Fixes =========================== When considering software upgrades, also consult: http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. +-------------------------------------------------------------------+ | Cisco IOS XR | SMU ID | SMU | Requires | | Version | | Name | Reload | |---------------+------------------------------+-------+------------| | 3.4.0 | Vulnerable; Migrate to 3.4.3 | | | | | and apply a SMU | | | |---------------+------------------------------+-------+------------| | 3.4.1 | SMU will be available on | | | | | 2010-Sep-9 | | | |---------------+------------------------------+-------+------------| | 3.4.2 | SMU will be available on | | | | | 2010-Sep-9 | | | |---------------+------------------------------+-------+------------| | 3.4.3 | SMU will be available on | | | | | 2010-Sep-5 | | | |---------------+------------------------------+-------+------------| | 3.5.2 | SMU will be available on | | | | | 2010-Sep-5 | | | |---------------+------------------------------+-------+------------| | 3.5.3 | SMU will be available on | | | | | 2010-Sep-9 | | | |---------------+------------------------------+-------+------------| | 3.5.4 | SMU will be available on | | | | | 2010-Sep-5 | | | |---------------+------------------------------+-------+------------| | 3.6.0 | SMU will be available on | | | | | 2010-Sep-9 | | | |---------------+------------------------------+-------+------------| | 3.6.1 | SMU will be available on | | | | | 2010-Sep-3 | | | |---------------+------------------------------+-------+------------| | 3.6.2 | SMU will be available on | | | | | 2010-Aug-30 | | | |---------------+------------------------------+-------+------------| | 3.6.3 | SMU will be available on | | | | | 2010-Sep-3 | | | |---------------+------------------------------+-------+------------| | 3.7.0 | SMU will be available on | | | | | 2010-Sep-9 | | | |---------------+------------------------------+-------+------------| | 3.7.1 | SMU will be available on | | | | | 2010-Sep-1 | | | |---------------+------------------------------+-------+------------| | 3.7.2 | SMU will be available on | | | | | 2010-Sep-3 | | | |---------------+------------------------------+-------+------------| | 3.7.3 | SMU will be available on | | | | | 2010-Sep-3 | | | |---------------+------------------------------+-------+------------| | 3.8.0 | SMU will be available on | | | | | 2010-Sep-3 | | | |---------------+------------------------------+-------+------------| | 3.8.1 | SMU will be available on | | | | | 2010-Sep-3 | | | |---------------+------------------------------+-------+------------| | 3.8.2 | SMU will be available on | | | | | 2010-Aug-30 | | | |---------------+------------------------------+-------+------------| | 3.8.3 | SMU will be available on | | | | | 2010-Sep-1 | | | |---------------+------------------------------+-------+------------| | 3.8.4 | SMU will be available on | | | | | 2010-Aug-28 | | | |---------------+------------------------------+-------+------------| | 3.9.0 | SMU will be available on | | | | | 2010-Sep-1 | | | |---------------+------------------------------+-------+------------| | 3.9.1 | SMU will be available on | | | | | 2010-Aug-28 | | | +-------------------------------------------------------------------+ Workarounds =========== There are no workarounds to proactively mitigate this vulnerability. If a route flap is observed, the prefix with the unrecognized attribute can be filtered. For further information on filtering on Cisco IOS XR Software, please consult the document "Implementing Routing Policy on Cisco IOS XR Software" at the following link: http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.0/routing/configuration/guide/rc3rpl.html#wp1118699 Obtaining Fixed Software ======================== Cisco is releasing free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at: http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html or as otherwise set forth at Cisco.com Downloads at: http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at: http://www.cisco.com Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to: http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== An advertisement of an unrecognized but valid BGP attribute resulted in resetting of several BGP neighbors on 27 August 2010. This advertisement was not malicious but inadvertently triggered this vulnerability. The Cisco PSIRT is not aware of malicious use of the vulnerability described in this advisory. Status of this Notice: INTERIM ============================== THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. CISCO EXPECTS TO UPDATE THIS DOCUMENT AS NEW INFORMATION BECOMES AVAILABLE. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at: http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +---------------------------------------+ | Revision | | Initial | | 1.0 | 2010-August-27 | public | | | | release | +---------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at: http://www.cisco.com/go/psirt -----BEGIN PGP SIGNATURE----- iD8DBQFMeEy786n/Gc8U/uARAqyeAJ9HEbSnJ9yCTiKU6HxbWnuEL1wicQCfRKdZ kv4pt8GHYDABNcIjbvGHYso= =mbwY -----END PGP SIGNATURE----- -- Byron Grobe From randy at psg.com Fri Aug 27 22:23:25 2010 From: randy at psg.com (Randy Bush) Date: Sat, 28 Aug 2010 12:23:25 +0900 Subject: Did your BGP crash today? In-Reply-To: <5A50C157-C761-4E6B-9968-5B99F131395C@exa-networks.co.uk> References: <10643.1282930277@localhost> <4C7803A5.4080509@Janoszka.pl> <5A50C157-C761-4E6B-9968-5B99F131395C@exa-networks.co.uk> Message-ID: > So much for "better left off public mailing lists" ! sigh ! damn! security through obscurity busted again. will people never learn? References: <8FA45C0E-7798-4D6F-A317-BCA538827803@bsdboy.com> Message-ID: http://nsrc.org/ will clean up and ship to the academics and ngos in the significantly less spoiled and privileged countries. randy From francois at menards.ca Fri Aug 27 23:53:04 2010 From: francois at menards.ca (Francois Menard) Date: Sat, 28 Aug 2010 00:53:04 -0400 Subject: Looking for Fiber Plant Management software In-Reply-To: <9B5D0FD163918D4A8913D243722B8F500296367FB7@WolfCreek.switchnet.nv> References: <56C21A0A-6907-4A1D-869D-38EDF9BE7D1F@briworks.com><2F9F3B3F-B791-4A6F-AA25-AE138546BE45@lixfeld.ca> <952980972-1282944212-cardhu_decombobulator_blackberry.rim.net-696758767-@bda903.bisx.prod.on.blackberry> <9B5D0FD163918D4A8913D243722B8F500296367FB7@WolfCreek.switchnet.nv> Message-ID: <181968BF-0C51-4EA4-B5EA-7AAEEAA35E4E@menards.ca> We use Fiberworks from Enghouse. Its built atop ArcObjects and all data is stored in an ARCGIS geodatabase, providing good flexibility to get the data brought up on ArcGIS Server (Web) for web-based editing. The good thing about this system is that it can also be used for design of FTTH as well, and makes it possible to produce for-construction as well as as-built drawings (with cut sheets & etc.) http://www.enghouse.com/amd/products/fiberworks.html Our sister company (Xit telecom) which does OSP engineering/consulting/GIS can help implement this system. Regards, -=Francois=- -- Francois D. Menard Director of technology Xittel telecommunications inc. 1350 Royale #800 Trois-Rivieres, QC, G9A 4J4 Canada Tel: +1 819 601-6633 Fax: +1 819 374-0395 fmenard at xittel.net On 2010-08-27, at 5:31 PM, Jim Devane wrote: > OSP Insight. Pricey but an excellent tool for OSP documentation. > > > -----Original Message----- > From: khatfield at socllc.net [mailto:khatfield at socllc.net] > Sent: Friday, August 27, 2010 2:24 PM > To: Jason Lixfeld; Jeff Saxe > Cc: nanog at nanog.org > Subject: Re: Looking for Fiber Plant Management software > > Most of the ones I have seen (2 out of 3) were inhouse/home-grown solutions. > > I believe the other was provided by SA (Scientific Atlanta). I tried to do a quick search on it and it appears that product may now be provided by Cisco in partnership with SA. > > Best of luck > -----Original Message----- > From: Jason Lixfeld > Date: Fri, 27 Aug 2010 12:13:35 > To: Jeff Saxe > Cc: > Subject: Re: Looking for Fiber Plant Management software > > I've got a client who uses AutoCAD. They use it exclusively and have a pretty big fibre network for someone who's not an ILEC, so I guess it works fairly well. > > On 2010-08-27, at 11:39 AM, Jeff Saxe wrote: > >> Good morning, NANOGers. My colleague at work wonders if anyone has suggestions for software to database all our fiber plant that we're constructing. We started out with paper, then Excel spreadsheets in a folder and on paper in a book, but clearly as our plant grows and we do more splicing this is not going to scale. We have started a MySQL database with a few tables, but wonder if someone has already invented this wheel. >> >> What do the "big boys" use? Homegrown solutions developed in-house and jealously guarded? Something standard? Expensive or cheap? Free open-source? He'd like to see... >> >> outside plan facilities: cables, fibers, splice points, poles; copper and fiber, preferably, but fiber is more important >> "circuit" or "DLR" that knows what elements are involved in a circuit >> GIS integration so that cables can be drawn on a map automagically >> low cost, of course >> >> Thanks in advance, everyone. >> >> -- Jeff Saxe, Network Engineer >> Blue Ridge InternetWorks, Charlottesville, VA >> 434-817-0707 ext. 2024 / JSaxe at briworks.com >> >> >> >> > > > From frank at fttx.org Sat Aug 28 01:06:46 2010 From: frank at fttx.org (Frank A. Coluccio) Date: Fri, 27 Aug 2010 23:06:46 -0700 Subject: Looking for Fiber Plant Management software Message-ID: <20100827230646.8C1BAB8C@resin12.mta.everyone.net> CableProject USA offers a free trial and a YT demo video. I can't vouch for it, never having witnessed it in operation personally, but it looks interesting. [1]http://www.cableprojectusa.com/ Cable Management Software runs the full gamut, from simplistic to near-ERP in scope, while others (e.g., VPI) also perform autoconfiguration and coordinated, parametric link designs for specific types of hardware (WDM, Switches/Routers, ROADMs, etc.). One can spend anywhere from free to $29.99 to tens of thousands of dollars, so decide carefully what you need, know specifically what you're looking for, and most of all, caveat emptor. --- francois at menards.ca wrote: From: Francois Menard To: Jim Devane Cc: Jason Lixfeld , "nanog at nanog.org" Subject: Re: Looking for Fiber Plant Management software Date: Sat, 28 Aug 2010 00:53:04 -0400 We use Fiberworks from Enghouse. Its built atop ArcObjects and all data is stored in an ARCGIS geodatabase, providing good flexibility to get the data brought up on ArcGIS Server (Web) for web-based editing. The good thing about this system is that it can also be used for design of FTTH as well, and makes it possible to produce for-construction as well as as-built drawings (with cut sheets & etc.) http://www.enghouse.com/amd/products/fiberworks.html Our sister company (Xit telecom) which does OSP engineering/consulting/GIS can help implement this system. Regards, -=Francois=- -- Francois D. Menard Director of technology Xittel telecommunications inc. 1350 Royale #800 Trois-Rivieres, QC, G9A 4J4 Canada Tel: +1 819 601-6633 Fax: +1 819 374-0395 fmenard at xittel.net On 2010-08-27, at 5:31 PM, Jim Devane wrote: > OSP Insight. Pricey but an excellent tool for OSP documentation. > > > -----Original Message----- > From: khatfield at socllc.net [mailto:khatfield at socllc.net] > Sent: Friday, August 27, 2010 2:24 PM > To: Jason Lixfeld; Jeff Saxe > Cc: nanog at nanog.org > Subject: Re: Looking for Fiber Plant Management software > > Most of the ones I have seen (2 out of 3) were inhouse/home-grown solutions. > > I believe the other was provided by SA (Scientific Atlanta). I tried to do a quick search on it and it appears that product may now be provided by Cisco in partnership with SA. > > Best of luck > -----Original Message----- > From: Jason Lixfeld > Date: Fri, 27 Aug 2010 12:13:35 > To: Jeff Saxe > Cc: > Subject: Re: Looking for Fiber Plant Management software > > I've got a client who uses AutoCAD. They use it exclusively and have a pretty big fibre network for someone who's not an ILEC, so I guess it works fairly well. > > On 2010-08-27, at 11:39 AM, Jeff Saxe wrote: > >> Good morning, NANOGers. My colleague at work wonders if anyone has suggestions for software to database all our fiber plant that we're constructing. We started out with paper, then Excel spreadsheets in a folder and on paper in a book, but clearly as our plant grows and we do more splicing this is not going to scale. We have started a MySQL database with a few tables, but wonder if someone has already invented this wheel. >> >> What do the "big boys" use? Homegrown solutions developed in-house and jealously guarded? Something standard? Expensive or cheap? Free open-source? He'd like to see... >> >> outside plan facilities: cables, fibers, splice points, poles; copper and fiber, preferably, but fiber is more important >> "circuit" or "DLR" that knows what elements are involved in a circuit >> GIS integration so that cables can be drawn on a map automagically >> low cost, of course >> >> Thanks in advance, everyone. >> >> -- Jeff Saxe, Network Engineer >> Blue Ridge InternetWorks, Charlottesville, VA >> 434-817-0707 ext. 2024 / JSaxe at briworks.com >> >> >> >> > > > References 1. http://www.cableprojectusa.com/ From thomas.mangin at exa-networks.co.uk Sat Aug 28 02:49:56 2010 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Sat, 28 Aug 2010 08:49:56 +0100 Subject: Did your BGP crash today? In-Reply-To: <70B436DB-9705-454F-907D-854D2C20B706@kumari.net> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100827213714.GA13356@vacation.karoshi.com.> <70B436DB-9705-454F-907D-854D2C20B706@kumari.net> Message-ID: <1E8FB9B8-30F9-4B40-A819-3BED15EB4834@exa-networks.co.uk> > I'm assuming that they weren't really expecting this to cause issues... Where does one draw the line? I'm planning on announcing x.y.z.0/20 later in the week -- x, y and z are all prime and the sum of all 3 is also a prime. There is a non-zero chance that something somewhere will go flooie, shall I send mail now or later? In this case the researchers sent an new packet that would never have been generated by any operational router ever before to their peer. They knew their packet would cause the router to run less/un tested and code path in BGP. To their defence, the risk was low. That said when I wrote my own BGP injector I accidentally sent badly formed known messages (like UPDATE,etc.) with bad attributes (like transitive when the RFC it MUST not be, and vice versa) to my routers. Juniper would kill the session at the validation stage and be quite verbose in the log but Cisco - at least on the 7301 I tested last year with a then recent IOS - would accept the packet as it. Yep, IOS do accept INVALID packets. I have no idea what happens after but if a Cisco router is passing the packet to a Juniper router it could have the same effect that what we saw, again, and tear down a session which is not the one which initiated the badly formed packet. That said I suspect that the message may not have been fully parsed, for performance reasons, with the outgoing packet partially generated following the RFC. Quagga is even worse that Cisco when it comes to packet validation but it should not surprise anyone :p Now, Should I research the described BGP behaviour (for a white hat conference for example) and send my possibly risking packets to my peer without telling them ? Hell no ! I am pretty sure that if I did I would loose quite a few session afterwards. People trust me not to absuse my BGP connections but for sending safe known message about my network and not some research stuff. That said vendor SHOULD research (and hopefully did) this kind of behaviour, but as yesterday shown, causing packet corruption through a router is bad for its stability :p > Also, I would prefer that this gets discovered and dealt with (in this case by stopping the announcement :-)) than having folk not willing to try things and ending up with a weaponized version... No argument here. Thomas From randy at psg.com Sat Aug 28 02:56:05 2010 From: randy at psg.com (Randy Bush) Date: Sat, 28 Aug 2010 16:56:05 +0900 Subject: Did your BGP crash today? In-Reply-To: <1E8FB9B8-30F9-4B40-A819-3BED15EB4834@exa-networks.co.uk> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> Message-ID: imiho, researchers injecting data into the control plane are responsible to have tested it at least against major bgp speakers. and, considering its placement in the net (big core), i consider ios xr to be a major speaker. i suspect that these folk will test better next time. i sure hope so. randy From thomas.mangin at exa-networks.co.uk Sat Aug 28 03:22:34 2010 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Sat, 28 Aug 2010 09:22:34 +0100 Subject: Did your BGP crash today? In-Reply-To: References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> Message-ID: <6AD583EF-98EA-4B95-8245-D2BF0F183EC0@exa-networks.co.uk> On 28 Aug 2010, at 08:56, Randy Bush wrote: > imiho, researchers injecting data into the control plane are responsible > to have tested it at least against major bgp speakers. and, considering > its placement in the net (big core), i consider ios xr to be a major > speaker. > > i suspect that these folk will test better next time. i sure hope so. Not sure the researcher can afford to buy a ios xr and may not have access to one ! Thomas From randy at psg.com Sat Aug 28 03:41:02 2010 From: randy at psg.com (Randy Bush) Date: Sat, 28 Aug 2010 17:41:02 +0900 Subject: Did your BGP crash today? In-Reply-To: <6AD583EF-98EA-4B95-8245-D2BF0F183EC0@exa-networks.co.uk> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <6AD583EF-98EA-4B95-8245-D2BF0F183EC0@exa-networks.co.uk> Message-ID: >> i suspect that these folk will test better next time. i sure hope so. > Not sure the researcher can afford to buy a ios xr and may not have > access to one ! then ask on *nog for someone against whom they can test. randy From saku at ytti.fi Sat Aug 28 03:41:22 2010 From: saku at ytti.fi (Saku Ytti) Date: Sat, 28 Aug 2010 11:41:22 +0300 Subject: Did your BGP crash today? In-Reply-To: <6AD583EF-98EA-4B95-8245-D2BF0F183EC0@exa-networks.co.uk> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <6AD583EF-98EA-4B95-8245-D2BF0F183EC0@exa-networks.co.uk> Message-ID: <20100828084122.GA29588@mx.ytti.net> On (2010-08-28 09:22 +0100), Thomas Mangin wrote: > > i suspect that these folk will test better next time. i sure hope so. > > Not sure the researcher can afford to buy a ios xr and may not have access to one ! Indeed. Also testing is hard, especially so, when you essentially need to reinvent the wheel every time, which might not even fit your time schedule. Maybe we as community could build 'BGPSpec' testing suite, simply python (or ruby yay!) script which has been thought at least to puke out UPDATEs that have known to break implementations before. Test cases being unique files for easy contribution. This BGPSpec could then be ran by vendors, researchers and operators, and we could be sure that at least same mistake is not done twice. With this suite in place, it would be easier for researcher to write new test case for the suite and then ask people to run it against their gear. >From global network security/reliability point-of-view BGP is pretty much only important protocol and as such maybe should enjoy special status in collaborative quality assurance. Considering this issue, late junos 32b ASN, mikrotik long AS path this http://www.cisco.com/en/US/products/products_security_advisory09186a0080094a58.shtml and probably many others, it seems we've been exceptionally lucky, that someone hasn't been fuzzing Internet BGP with target of breaking as much of it as possible, as it wouldn't really been that hard. -- ++ytti From bmanning at vacation.karoshi.com Sat Aug 28 04:12:53 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 28 Aug 2010 09:12:53 +0000 Subject: Did your BGP crash today? In-Reply-To: <6AD583EF-98EA-4B95-8245-D2BF0F183EC0@exa-networks.co.uk> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <6AD583EF-98EA-4B95-8245-D2BF0F183EC0@exa-networks.co.uk> Message-ID: <20100828091253.GA14731@vacation.karoshi.com.> On Sat, Aug 28, 2010 at 09:22:34AM +0100, Thomas Mangin wrote: > On 28 Aug 2010, at 08:56, Randy Bush wrote: > > > imiho, researchers injecting data into the control plane are responsible > > to have tested it at least against major bgp speakers. and, considering > > its placement in the net (big core), i consider ios xr to be a major > > speaker. > > > > i suspect that these folk will test better next time. i sure hope so. > > Not sure the researcher can afford to buy a ios xr and may not have access to one ! > > Thomas while this is undoubtedly true for hobbiest researchers, there are pretty good relationships between vendors and some research facilities with a strong interst in ensuring there is external review of the code base(es). (I am personally aware of at least five such facilities...:) hence I am going to have to echo Randys sentiments. This was just sloppy. --bill From randy at psg.com Sat Aug 28 04:20:19 2010 From: randy at psg.com (Randy Bush) Date: Sat, 28 Aug 2010 18:20:19 +0900 Subject: Did your BGP crash today? In-Reply-To: <20100828084122.GA29588@mx.ytti.net> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <6AD583EF-98EA-4B95-8245-D2BF0F183EC0@exa-networks.co.uk> <20100828084122.GA29588@mx.ytti.net> Message-ID: >>> i suspect that these folk will test better next time. i sure hope >>> so. >> Not sure the researcher can afford to buy a ios xr and may not have >> access to one ! > Also testing is hard so is cleaning up the mess when you screw up enough of the internet to make the international press. > Maybe we as community could build 'BGPSpec' testing suite, simply > python (or ruby yay!) script which has been thought at least to puke > out UPDATEs that have known to break implementations before. Test > cases being unique files for easy contribution. a bgp regression suite would not have caught this as it was not a repeat. but it sure would be useful to implementors. randy From mike-nanog at tiedyenetworks.com Sat Aug 28 04:32:11 2010 From: mike-nanog at tiedyenetworks.com (Mike) Date: Sat, 28 Aug 2010 02:32:11 -0700 Subject: Did your BGP crash today? In-Reply-To: <20100828091253.GA14731@vacation.karoshi.com.> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <6AD583EF-98EA-4B95-8245-D2BF0F183EC0@exa-networks.co.uk> <20100828091253.GA14731@vacation.karoshi.com.> Message-ID: <4C78D79B.1000307@tiedyenetworks.com> > > while this is undoubtedly true for hobbiest researchers, there are > pretty good relationships between vendors and some research facilities > with a strong interst in ensuring there is external review of the > code base(es). > > (I am personally aware of at least five such facilities...:) > > hence I am going to have to echo Randys sentiments. This was just > sloppy. > > > I am really surprised by these attitudes. Guys (and gals), these incidents simply go to reinforce that the software we depend on, has not received sufficient testing and that we all have gigantic exposures due to things outside of our direct control (eg: cisco, juniper or other router software quality control). You can't just demand that people don't do things that wind up being destructive to you on your production network, thats asking the world to be responsible for you. There are lots of bugs in this stuff and the sooner that we find out about them, the sooner we can get updates to address them and hopefully, shorten the window in which those issues could be painful to us and cause us grief. From saku at ytti.fi Sat Aug 28 04:39:42 2010 From: saku at ytti.fi (Saku Ytti) Date: Sat, 28 Aug 2010 12:39:42 +0300 Subject: Did your BGP crash today? In-Reply-To: References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <6AD583EF-98EA-4B95-8245-D2BF0F183EC0@exa-networks.co.uk> <20100828084122.GA29588@mx.ytti.net> Message-ID: <20100828093942.GA29779@mx.ytti.net> On (2010-08-28 18:20 +0900), Randy Bush wrote: > a bgp regression suite would not have caught this as it was not a > repeat. but it sure would be useful to implementors. Naturally 'proving' that non-trivial software works is practically impossible. But stating what non-existing test-suite would or would not have covered is not a topic I'm particularly interested to engage. -- ++ytti From randy at psg.com Sat Aug 28 04:46:42 2010 From: randy at psg.com (Randy Bush) Date: Sat, 28 Aug 2010 18:46:42 +0900 Subject: Did your BGP crash today? In-Reply-To: <4C78D79B.1000307@tiedyenetworks.com> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <6AD583EF-98EA-4B95-8245-D2BF0F183EC0@exa-networks.co.uk> Message-ID: > I am really surprised by these attitudes. Guys (and gals), these > incidents simply go to reinforce that the software we depend on, has > not received sufficient testing and that we all have gigantic > exposures due to things outside of our direct control nice anti-vendor rant. but over the last decades we the ops have asked for a jillion features which creates massive code, and there is no hope of testing all the code paths rigorously. the vendors have large test labs, and do what they can. sure, they could do better. so could we all. but it is also coders' responsibility, whether vendors or researchers or hackers, to also test what they send. in this case, clearly that was not done sufficiently. if i am sloppy in my receiving code, the pain is mine. if you are sloppy in your sending code, the pain is not yours. randy From thomas.mangin at exa-networks.co.uk Sat Aug 28 04:47:30 2010 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Sat, 28 Aug 2010 10:47:30 +0100 Subject: Did your BGP crash today? In-Reply-To: <1E8FB9B8-30F9-4B40-A819-3BED15EB4834@exa-networks.co.uk> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100827213714.GA13356@vacation.karoshi.com.> <70B436DB-9705-454F-907D-854D2C20B706@kumari.net> <1E8FB9B8-30F9-4B40-A819-3BED15EB4834@exa-networks.co.uk> Message-ID: > Quagga is even worse that Cisco when it comes to packet validation but it should not surprise anyone :p To substantiate my claim, my mercurial log tells me that for MPRNLRI and MPURNLRI having the flag set as Transitive instead of Optional did not cause Quagga to complain. It just took the IPv4/IPv6 route . Now it may have been fixed. I should really check and if not pass this to the quagga dev list. I am lazy. Thomas From fw at deneb.enyo.de Sat Aug 28 05:14:38 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 28 Aug 2010 12:14:38 +0200 Subject: Did your BGP crash today? In-Reply-To: (Christopher Morrow's message of "Fri, 27 Aug 2010 16:11:32 -0400") References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> Message-ID: <87tymfujqp.fsf@mid.deneb.enyo.de> * Christopher Morrow: > (you are asking your vendors to run full bit sweeps of each protocol > in a regimented manner checking for all possible edge cases and > properly handling them, right?) The real issue is that both spec and current practice say you need to drop the session as soon as you encounter any unexpected data. That's just wrong---you can't really be sure that it's a temporary glitch caused by your peer. If it's not, you are unnecessarily taking yourself off the net. Of course, there is little you can do when the outer framing at the internal BGP layer is wrong (resyncing is way too risky). A tear-down might be in order if you receive an unrecognized message type, too. But a BGP update message which is malformed internally should just be ignored. From a theoretical point of view, it's no worse than the operator configuring a prefix-list that filters out all the NLRI entries. From leen at consolejunkie.net Sat Aug 28 06:09:47 2010 From: leen at consolejunkie.net (Leen Besselink) Date: Sat, 28 Aug 2010 13:09:47 +0200 Subject: Did your BGP crash today? In-Reply-To: <20100828093942.GA29779@mx.ytti.net> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <6AD583EF-98EA-4B95-8245-D2BF0F183EC0@exa-networks.co.uk> <20100828084122.GA29588@mx.ytti.net> <20100828093942.GA29779@mx.ytti.net> Message-ID: <4C78EE7B.6090309@consolejunkie.net> On 08/28/2010 11:39 AM, Saku Ytti wrote: > On (2010-08-28 18:20 +0900), Randy Bush wrote: > > >> a bgp regression suite would not have caught this as it was not a >> repeat. but it sure would be useful to implementors. >> > Naturally 'proving' that non-trivial software works is practically > impossible. But stating what non-existing test-suite would or would not > have covered is not a topic I'm particularly interested to engage. > > > I suggest the test-tool has 2 bgp-sessions and tests if what it put in did or did not come out on the otherside and in what shape or form. There are already atleast 2 projects which have BGP-code which could probably be adapted: http://code.google.com/p/exabgp/ http://code.google.com/p/bgpsimple/ Can I suggest a fuzzer as wel ? From thomas.mangin at exa-networks.co.uk Sat Aug 28 06:23:50 2010 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Sat, 28 Aug 2010 13:23:50 +0200 Subject: Did your BGP crash today? In-Reply-To: <4C78EE7B.6090309@consolejunkie.net> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <6AD583EF-98EA-4B95-8245-D2BF0F183EC0@exa-networks.co.uk> <20100828084122.GA29588@mx.ytti.net> <20100828093942.GA29779@mx.ytti.net> <4C78EE7B.6090309@consolejunkie.net> Message-ID: Those tools are not suitable for regression testing ( I know I wrote exabgp ) not saying they could not be adapted though. Fizzing may return crashes or issues with the daemon but it is unlikely. You need predictable input for regression testing and in our particular case how do you detect a corruption without knowing what the behaviour of the router should be on that particular input. If it was that simple vendors would have done it --- from my iPhone On 28 Aug 2010, at 13:09, Leen Besselink wrote: > On 08/28/2010 11:39 AM, Saku Ytti wrote: >> On (2010-08-28 18:20 +0900), Randy Bush wrote: >> >> >>> a bgp regression suite would not have caught this as it was not a >>> repeat. but it sure would be useful to implementors. >>> >> Naturally 'proving' that non-trivial software works is practically >> impossible. But stating what non-existing test-suite would or would not >> have covered is not a topic I'm particularly interested to engage. >> >> >> > I suggest the test-tool has 2 bgp-sessions and tests if what it put in > did or did not come out on the otherside and in what shape or form. > > There are already atleast 2 projects which have BGP-code which could > probably be adapted: > http://code.google.com/p/exabgp/ > http://code.google.com/p/bgpsimple/ > > Can I suggest a fuzzer as wel ? > > From fw at deneb.enyo.de Sat Aug 28 06:31:03 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 28 Aug 2010 13:31:03 +0200 Subject: Did your BGP crash today? In-Reply-To: (Randy Bush's message of "Sat, 28 Aug 2010 16:56:05 +0900") References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> Message-ID: <87occnt1mw.fsf@mid.deneb.enyo.de> * Randy Bush: > imiho, researchers injecting data into the control plane are > responsible to have tested it at least against major bgp speakers. Practically, this boils down to "don't do that", which is certainly fine by me. To carry out such experiments responsibly, you have to conduct so much testing beforehand that the live test on the actual Internet will not yield new insights (assuming you did your pre-experiment testing properly). From fw at deneb.enyo.de Sat Aug 28 06:34:43 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 28 Aug 2010 13:34:43 +0200 Subject: Did your BGP crash today? In-Reply-To: (Randy Bush's message of "Sat, 28 Aug 2010 18:20:19 +0900") References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <6AD583EF-98EA-4B95-8245-D2BF0F183EC0@exa-networks.co.uk> <20100828084122.GA29588@mx.ytti.net> Message-ID: <87hbift1gs.fsf@mid.deneb.enyo.de> * Randy Bush: > a bgp regression suite would not have caught this as it was not a > repeat. Eh, it was just another corrupt-and-propagate issue combined with the broken (but RFC-required) session reset policy on malformed updates. From saku at ytti.fi Sat Aug 28 06:36:52 2010 From: saku at ytti.fi (Saku Ytti) Date: Sat, 28 Aug 2010 14:36:52 +0300 Subject: Did your BGP crash today? In-Reply-To: References: <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <6AD583EF-98EA-4B95-8245-D2BF0F183EC0@exa-networks.co.uk> <20100828084122.GA29588@mx.ytti.net> <20100828093942.GA29779@mx.ytti.net> <4C78EE7B.6090309@consolejunkie.net> Message-ID: <20100828113652.GA30160@mx.ytti.net> On (2010-08-28 13:23 +0200), Thomas Mangin wrote: > Those tools are not suitable for regression testing ( I know I wrote exabgp ) not saying they could not be adapted though. > > Fizzing may return crashes or issues with the daemon but it is unlikely. You need predictable input for regression testing and in our particular case how do you detect a corruption without knowing what the behaviour of the router should be on that particular input. It doesn't actually matter how likely or unlikely one expect such tool to be finding new issues. There is already value, that researchers like RIPE in this case, could simply write new test case, instead of needing to build whole infrastructure. -- ++ytti From cjeker at diehard.n-r-g.com Sat Aug 28 06:42:22 2010 From: cjeker at diehard.n-r-g.com (Claudio Jeker) Date: Sat, 28 Aug 2010 13:42:22 +0200 Subject: Did your BGP crash today? In-Reply-To: References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> Message-ID: <20100828114222.GB30614@diehard.n-r-g.com> On Sat, Aug 28, 2010 at 04:56:05PM +0900, Randy Bush wrote: > imiho, researchers injecting data into the control plane are responsible > to have tested it at least against major bgp speakers. and, considering > its placement in the net (big core), i consider ios xr to be a major > speaker. > > i suspect that these folk will test better next time. i sure hope so. > I think you blame the wrong people. The vendor should make sure that their implementation does not violate the very basics of the BGP protocol. This bug in the IOS XR BGP implementation was a ticking time bomb and it was just a matter of when it would blow up. I suspect that Cisco will test better next time when they release a new version of their software. I sure hope so. -- :wq Claudio From christian.martin at teliris.com Sat Aug 28 06:48:15 2010 From: christian.martin at teliris.com (Christian Martin) Date: Sat, 28 Aug 2010 07:48:15 -0400 Subject: Did your BGP crash today? In-Reply-To: <87occnt1mw.fsf@mid.deneb.enyo.de> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <87occnt1mw.fsf@mid.deneb.enyo.de> Message-ID: <84BD2622-0816-4F4C-B271-3AD4F3412225@teliris.com> I think that focusing on researchers (who we assume are good-intentioned) misses the point. Any connected BGP speaker can inject any form of ugliness. The routers that mishandled these updates were bounded by routers that were able to 'properly' handle corrupted updates. The question of aggressive teardown of BGP sessions after a speaker receives garbage has been well considered for a long time. Stop the problem at the edges. The only difference here is that the edge moved one hop closer to the core. /c Sent from my iPhone On Aug 28, 2010, at 7:31 AM, Florian Weimer wrote: > * Randy Bush: > >> imiho, researchers injecting data into the control plane are >> responsible to have tested it at least against major bgp speakers. > > Practically, this boils down to "don't do that", which is certainly > fine by me. > > To carry out such experiments responsibly, you have to conduct so much > testing beforehand that the live test on the actual Internet will not > yield new insights (assuming you did your pre-experiment testing > properly). > From thomas.mangin at exa-networks.co.uk Sat Aug 28 06:52:28 2010 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Sat, 28 Aug 2010 13:52:28 +0200 Subject: Did your BGP crash today? In-Reply-To: <20100828113652.GA30160@mx.ytti.net> References: <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <6AD583EF-98EA-4B95-8245-D2BF0F183EC0@exa-networks.co.uk> <20100828084122.GA29588@mx.ytti.net> <20100828093942.GA29779@mx.ytti.net> <4C78EE7B.6090309@consolejunkie.net> <20100828113652.GA30160@mx.ytti.net> Message-ID: My point was not about crafted bgp message to test border cases - this is what one would expect in a regression suite. It is about the use of a fuzzer to corrupt packet when you then do not know if the router is then behaving correctly or not. --- from my iPhone On 28 Aug 2010, at 13:36, Saku Ytti wrote: > On (2010-08-28 13:23 +0200), Thomas Mangin wrote: > >> Those tools are not suitable for regression testing ( I know I wrote exabgp ) not saying they could not be adapted though. >> >> Fizzing may return crashes or issues with the daemon but it is unlikely. You need predictable input for regression testing and in our particular case how do you detect a corruption without knowing what the behaviour of the router should be on that particular input. > > It doesn't actually matter how likely or unlikely one expect such tool to > be finding new issues. There is already value, that researchers like RIPE > in this case, could simply write new test case, instead of needing to build > whole infrastructure. > > -- > ++ytti > From cjeker at diehard.n-r-g.com Sat Aug 28 07:10:30 2010 From: cjeker at diehard.n-r-g.com (Claudio Jeker) Date: Sat, 28 Aug 2010 14:10:30 +0200 Subject: Did your BGP crash today? In-Reply-To: <4C78EE7B.6090309@consolejunkie.net> References: <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <6AD583EF-98EA-4B95-8245-D2BF0F183EC0@exa-networks.co.uk> <20100828084122.GA29588@mx.ytti.net> <20100828093942.GA29779@mx.ytti.net> <4C78EE7B.6090309@consolejunkie.net> Message-ID: <20100828121030.GC30614@diehard.n-r-g.com> On Sat, Aug 28, 2010 at 01:09:47PM +0200, Leen Besselink wrote: > On 08/28/2010 11:39 AM, Saku Ytti wrote: > > On (2010-08-28 18:20 +0900), Randy Bush wrote: > > > > > >> a bgp regression suite would not have caught this as it was not a > >> repeat. but it sure would be useful to implementors. > >> > > Naturally 'proving' that non-trivial software works is practically > > impossible. But stating what non-existing test-suite would or would not > > have covered is not a topic I'm particularly interested to engage. > > > > > > > I suggest the test-tool has 2 bgp-sessions and tests if what it put in > did or did not come out on the otherside and in what shape or form. > > There are already atleast 2 projects which have BGP-code which could > probably be adapted: > http://code.google.com/p/exabgp/ > http://code.google.com/p/bgpsimple/ > > Can I suggest a fuzzer as wel ? > > There was once cert-bgp-testcases-28may03-final.tar.gz which did some testing (including expected responses). I use it from time to time. >From the README: For more information see the NANOG 28 (http://www.nanog.org) presentation ... "BGP Vulnerability Testing: Separating Fact from FUD" by Sean Convery (sean at cisco.com) and Matthew Franz (mfranz at cisco.com) But my quick googeling failed to locate a link to it. -- :wq Claudio From randy at psg.com Sat Aug 28 07:10:30 2010 From: randy at psg.com (Randy Bush) Date: Sat, 28 Aug 2010 21:10:30 +0900 Subject: Did your BGP crash today? In-Reply-To: <87occnt1mw.fsf@mid.deneb.enyo.de> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <87occnt1mw.fsf@mid.deneb.enyo.de> Message-ID: > To carry out such experiments responsibly, you have to conduct so much > testing beforehand that the live test on the actual Internet will not > yield new insights (assuming you did your pre-experiment testing > properly). you seem to assume the purpose of the test was to see if routers crashed. i certainly think mor ehighly of ripe lans folk than that. randy From leen at consolejunkie.net Sat Aug 28 07:16:14 2010 From: leen at consolejunkie.net (Leen Besselink) Date: Sat, 28 Aug 2010 14:16:14 +0200 Subject: Did your BGP crash today? In-Reply-To: References: <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <6AD583EF-98EA-4B95-8245-D2BF0F183EC0@exa-networks.co.uk> <20100828084122.GA29588@mx.ytti.net> <20100828093942.GA29779@mx.ytti.net> <4C78EE7B.6090309@consolejunkie.net> <20100828113652.GA30160@mx.ytti.net> Message-ID: <4C78FE0E.9060200@consolejunkie.net> On 08/28/2010 01:52 PM, Thomas Mangin wrote: > My point was not about crafted bgp message to test border cases - this is what one would expect in a regression suite. > It is about the use of a fuzzer to corrupt packet when you then do not know if the router is then behaving correctly or not. > > I wasn't saying you should use both at the same time, but I thought it might be a good idea to add a fuzzer so that it could be run seperately. Any bugs we can find before it is in production causing problems is useful. Although most code I've seen which deals with the BGP-protocol directly seemed to be pretty simple/smart about it. > --- > from my iPhone > > On 28 Aug 2010, at 13:36, Saku Ytti wrote: > > >> On (2010-08-28 13:23 +0200), Thomas Mangin wrote: >> >> >>> Those tools are not suitable for regression testing ( I know I wrote exabgp ) not saying they could not be adapted though. >>> >>> Fizzing may return crashes or issues with the daemon but it is unlikely. You need predictable input for regression testing and in our particular case how do you detect a corruption without knowing what the behaviour of the router should be on that particular input. >>> >> It doesn't actually matter how likely or unlikely one expect such tool to >> be finding new issues. There is already value, that researchers like RIPE >> in this case, could simply write new test case, instead of needing to build >> whole infrastructure. >> >> -- >> ++ytti >> >> > > From fw at deneb.enyo.de Sat Aug 28 07:19:28 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 28 Aug 2010 14:19:28 +0200 Subject: Did your BGP crash today? In-Reply-To: <20100828114222.GB30614@diehard.n-r-g.com> (Claudio Jeker's message of "Sat, 28 Aug 2010 13:42:22 +0200") References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> Message-ID: <87lj7rrktr.fsf@mid.deneb.enyo.de> * Claudio Jeker: > I think you blame the wrong people. The vendor should make sure that > their implementation does not violate the very basics of the BGP > protocol. The curious thing here is that the peer that resets the session, as required by the spec, causes the actual damage (the session reset), and not the peer producing the wrong update. This whole thread is quite schizophrenic because the consensus appears to be that (a) a *researcher is not to blame* for sending out a BGP message which eventually leads to session resets, and (b) an *implementor is to blame* for sending out a BGP messages which eventually leads to session resets. You really can't have it both ways. I'm fed up with this situation, and we will fix it this time. My take is that if you reset the session, you're part of the problem, and consequently deserve part of the blame. So if you receive a properly-framed BGP update message you cannot parse, you should just log it, but not take down the session. From lorddoskias at gmail.com Sat Aug 28 07:19:57 2010 From: lorddoskias at gmail.com (lorddoskias) Date: Sat, 28 Aug 2010 15:19:57 +0300 Subject: Did your BGP crash today? In-Reply-To: References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <87occnt1mw.fsf@mid.deneb.enyo.de> Message-ID: <4C78FEED.4070203@gmail.com> Am I the only one on the list which saw the sentence in Cisco's Advisory "Before sending the the unknown attribute to peers, the IOS XR corrupted it" which clearly states this was a bug?! From raymond at prolocation.net Sat Aug 28 07:21:31 2010 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Sat, 28 Aug 2010 14:21:31 +0200 (CEST) Subject: Did your BGP crash today? In-Reply-To: <87lj7rrktr.fsf@mid.deneb.enyo.de> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> Message-ID: Hi! >> I think you blame the wrong people. The vendor should make sure that >> their implementation does not violate the very basics of the BGP >> protocol. > The curious thing here is that the peer that resets the session, as > required by the spec, causes the actual damage (the session reset), > and not the peer producing the wrong update. > > This whole thread is quite schizophrenic because the consensus appears > to be that (a) a *researcher is not to blame* for sending out a BGP > message which eventually leads to session resets, and (b) an > *implementor is to blame* for sending out a BGP messages which > eventually leads to session resets. You really can't have it both > ways. > > I'm fed up with this situation, and we will fix it this time. My take > is that if you reset the session, you're part of the problem, and > consequently deserve part of the blame. So if you receive a > properly-framed BGP update message you cannot parse, you should just > log it, but not take down the session. Not sure if the link was posted allready ... http://www.cisco.com/en/US/products/products_security_advisory09186a0080b4411f.shtml 'The vulnerability manifests itself when a BGP peer announces a prefix with a specific, valid but unrecognized transitive attribute. On receipt of this prefix, the Cisco IOS XR device will corrupt the attribute before sending it to the neighboring devices. Neighboring devices that receive this corrupted update may reset the BGP peering session.' Bye, Raymond. From fw at deneb.enyo.de Sat Aug 28 07:27:54 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 28 Aug 2010 14:27:54 +0200 Subject: Did your BGP crash today? In-Reply-To: (Raymond Dijkxhoorn's message of "Sat, 28 Aug 2010 14:21:31 +0200 (CEST)") References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> Message-ID: <87eidisz05.fsf@mid.deneb.enyo.de> * Raymond Dijkxhoorn: > Not sure if the link was posted allready ... > > http://www.cisco.com/en/US/products/products_security_advisory09186a0080b4411f.shtml Cisco posts their advisories to the NANOG list. > 'The vulnerability manifests itself when a BGP peer announces a prefix > with a specific, valid but unrecognized transitive attribute. On > receipt of this prefix, the Cisco IOS XR device will corrupt the > attribute before sending it to the neighboring devices. Neighboring > devices that receive this corrupted update may reset the BGP peering > session.' I'm not sure what you intend to say by quoting this part of the advisory. If you think that it's an IOS XR bug which only needs fixing in IOS XR, you're showing the very attitude which has stopped us from making the network more resilient to these types of events. From fw at deneb.enyo.de Sat Aug 28 07:31:15 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 28 Aug 2010 14:31:15 +0200 Subject: Did your BGP crash today? In-Reply-To: (Randy Bush's message of "Sat, 28 Aug 2010 21:10:30 +0900") References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <87occnt1mw.fsf@mid.deneb.enyo.de> Message-ID: <87d3t2syuk.fsf@mid.deneb.enyo.de> * Randy Bush: >> To carry out such experiments responsibly, you have to conduct so much >> testing beforehand that the live test on the actual Internet will not >> yield new insights (assuming you did your pre-experiment testing >> properly). > > you seem to assume the purpose of the test was to see if routers > crashed. i certainly think mor ehighly of ripe lans folk than that. We don't yet precisely what was the point of the experiment. But it is very likely that it intended to study propagation of such updates. Not propagating them is a protocol violation, so in order to observe anything beyond propagation times, they would have to intend to cause protocol violations, which is, in fact, awfully close to session resets (thanks to the BGP protocol design). From raymond at prolocation.net Sat Aug 28 07:42:32 2010 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Sat, 28 Aug 2010 14:42:32 +0200 (CEST) Subject: Did your BGP crash today? In-Reply-To: <87eidisz05.fsf@mid.deneb.enyo.de> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> <87eidisz05.fsf@mid.deneb.enyo.de> Message-ID: Hi! > Cisco posts their advisories to the NANOG list. >> 'The vulnerability manifests itself when a BGP peer announces a prefix >> with a specific, valid but unrecognized transitive attribute. On >> receipt of this prefix, the Cisco IOS XR device will corrupt the >> attribute before sending it to the neighboring devices. Neighboring >> devices that receive this corrupted update may reset the BGP peering >> session.' > I'm not sure what you intend to say by quoting this part of the > advisory. If you think that it's an IOS XR bug which only needs > fixing in IOS XR, you're showing the very attitude which has stopped > us from making the network more resilient to these types of events. Its more a workaround then a bugfix ... Dont try to write down what I might think. I am perfectly capable of explaining this myselve. The narrow minded response you just did tells more about you then about me. So far for the rant. I think i am around long enough that you would not even consider thinking that i would say 'hey this is a IOS XR BUG. Its not.' I didnt say this at all. Did I? If it affects a large part of traffic on the internet and it obviously did. It took down a couple of the larger networks. http://www.ams-ix.net/cgi-bin/stats/16all?log=totalall;png=daily You can clearly see the drop there also. I think a 'fix' 'bugfix' 'workaround' whatever you want to call it, i still think its good they released it and fast. A more structural approach is nice but wont help a lot of networks right now. I am sorry i tried to add something to the thread. Think about this Florian. We are not the bad guys. Bye, Raymond. From thomas.mangin at exa-networks.co.uk Sat Aug 28 07:51:17 2010 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Sat, 28 Aug 2010 14:51:17 +0200 Subject: Did your BGP crash today? In-Reply-To: <87eidisz05.fsf@mid.deneb.enyo.de> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> <87eidisz05.fsf@mid.deneb.enyo.de> Message-ID: <5EA020FD-78CF-40EF-9C35-379DBD490499@exa-networks.co.uk> We had ASN4, AS-PATH and this one. More or less we hit this session reset problem once a year but nothing was done yet to change the RFC. So I am to blame as much as every network engineer to not have pushed for a change or at least a comprehensive explanation on the session teardown behaviour is like it is and should not be changed. It is only our fault for not having dealt with the problem the first time correctly, and will be next time if nothing is changed once more. I agree correctly framed invalid packet should be discarded without tearing the session down. --- from my iPhone On 28 Aug 2010, at 14:27, Florian Weimer wrote: > * Raymond Dijkxhoorn: > >> Not sure if the link was posted allready ... >> >> http://www.cisco.com/en/US/products/products_security_advisory09186a0080b4411f.shtml > > Cisco posts their advisories to the NANOG list. > >> 'The vulnerability manifests itself when a BGP peer announces a prefix >> with a specific, valid but unrecognized transitive attribute. On >> receipt of this prefix, the Cisco IOS XR device will corrupt the >> attribute before sending it to the neighboring devices. Neighboring >> devices that receive this corrupted update may reset the BGP peering >> session.' > > I'm not sure what you intend to say by quoting this part of the > advisory. If you think that it's an IOS XR bug which only needs > fixing in IOS XR, you're showing the very attitude which has stopped > us from making the network more resilient to these types of events. > From nanogf at spoofer.com Sat Aug 28 09:02:50 2010 From: nanogf at spoofer.com (nanogf .) Date: Sat, 28 Aug 2010 07:02:50 -0700 Subject: Hyperchip (was Re: PacketShader) Message-ID: <20100828070250.8C21F8A4@resin18.mta.everyone.net> http://docs.google.com/viewer?url=http://www.hyperchip.com/H40GPresentation.pdf --- oberman at es.net wrote: From: "Kevin Oberman" To: nanog at shankland.org Cc: nanog at nanog.org Subject: Re: PacketShader Date: Mon, 23 Aug 2010 11:56:29 -0700 > Date: Mon, 23 Aug 2010 06:27:00 -0700 > From: Jim Shankland > > Mark Smith wrote: > > On Mon, 23 Aug 2010 05:59:43 -0400 > > Valdis.Kletnieks at vt.edu wrote: > > > > I missed that, and that answers the "was it a GigaBytes verses Gigabits > > error" question. Nothing new here by the looks of it - people in this > > thread were getting those sorts of speeds a year ago out of PC hardware > > under Linux - > > > > http://lkml.org/lkml/2009/7/15/234 > > > > "I have achieved a collective throughput of 66.25 Gbit/s." > > > > "We've achieved 70 Gbps aggregate unidirectional TCP performance from > > one P6T6 based system to another." > > Very nice, but doing this with 1514-byte packets is the low-hanging > fruit. (9K packets? That's the fruit that falls off the tree and > into your basket while you're napping :-).) The more interesting limit: > how many 40-byte packets per second can you shovel into this system > and still have all of them come out the other end? Seems reasonable, but in our testing of 100G Ethernet capable routers we found one that handled 8000 bytes just fine, but could only run 9000 byte packets at about 90G. Just a bit unexpected. Really, in this day and age, a chassis throughput of 100G is pretty trivial. When you start getting up to the Tbps range on a system using "standard components", then I'll be really interested. We do have a network of many end systems attached with 10Gbps Ethernet cards. I'm sure that we are not unique, though probably unusual. We are achieving stable disk to disk transfer rates of well over 3G between the US and Australia. I don't think that PacketShader would handle the load too well. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 _____________________________________________________________ Get your own *free* email address like this one from www.OwnEmail.com From thomas.mangin at exa-networks.co.uk Sat Aug 28 09:53:47 2010 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Sat, 28 Aug 2010 15:53:47 +0100 Subject: Did your BGP crash today? In-Reply-To: <5EA020FD-78CF-40EF-9C35-379DBD490499@exa-networks.co.uk> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> <87eidisz05.fsf@mid.deneb.enyo.de> <5EA020FD-78CF-40EF-9C35-379DBD490499@exa-networks.co.uk> Message-ID: > I agree correctly framed invalid packet should be discarded without tearing the session down. This statement is way to simplistic. I would be interested if anyone has pointers toward any work which was done to sort this issue. Thanks. Thomas From cjeker at diehard.n-r-g.com Sat Aug 28 10:26:44 2010 From: cjeker at diehard.n-r-g.com (Claudio Jeker) Date: Sat, 28 Aug 2010 17:26:44 +0200 Subject: Did your BGP crash today? In-Reply-To: <5EA020FD-78CF-40EF-9C35-379DBD490499@exa-networks.co.uk> References: <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> <87eidisz05.fsf@mid.deneb.enyo.de> <5EA020FD-78CF-40EF-9C35-379DBD490499@exa-networks.co.uk> Message-ID: <20100828152644.GE30614@diehard.n-r-g.com> On Sat, Aug 28, 2010 at 02:51:17PM +0200, Thomas Mangin wrote: > We had ASN4, AS-PATH and this one. More or less we hit this session > reset problem once a year but nothing was done yet to change the RFC. You are mixing up three totaly different problems. Sure the result was the same (session drops). This time a IOS XR device was corrupting an attribute before sending it out. The corruption had to be in the header section of the attribute or the other side would not have detected it (since the neighbor did not know about this attribute either). Now if a system sends out corrupted BGP messages there is no way out, you need to close the session because not doing so may result in much bigger mayhem. It was not mentioned what the corruption was actually, was the lenght wrong or was the optional flag missing (makeing the attribute well known)? Unlike in the ASN4 issue this time the session to the faulty system was dropped and by doing so stopped further issues. > So I am to blame as much as every network engineer to not have pushed > for a change or at least a comprehensive explanation on the session > teardown behaviour is like it is and should not be changed. > > It is only our fault for not having dealt with the problem the first > time correctly, and will be next time if nothing is changed once more. > > I agree correctly framed invalid packet should be discarded without > tearing the session down. Great, corrupting your RIB and FIB and every of your peers RIB. Thanks a lot for routing loops and wrong announcements. The only thing you can drop without causing troubles are (tranistive) optional attributes. This is covered by draft-ietf-idr-optional-transitive and hopefully it will be adopted as RFC and implemented by vendors. If a well known attribute like AS-PATH is corrupted then there is no choice, the session needs to be reset. Which is bad when the AS-PATH validation code has a bug. -- :wq Claudio From rbf+nanog at panix.com Sat Aug 28 10:58:54 2010 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sat, 28 Aug 2010 10:58:54 -0500 Subject: Did your BGP crash today? In-Reply-To: <87lj7rrktr.fsf@mid.deneb.enyo.de> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> Message-ID: <20100828155853.GA12190@panix.com> On Sat, Aug 28, 2010 at 02:19:28PM +0200, Florian Weimer wrote: > * Claudio Jeker: > > > I think you blame the wrong people. The vendor should make sure that > > their implementation does not violate the very basics of the BGP > > protocol. > > The curious thing here is that the peer that resets the session, as > required by the spec, causes the actual damage (the session reset), > and not the peer producing the wrong update. > > This whole thread is quite schizophrenic because the consensus appears > to be that (a) a *researcher is not to blame* for sending out a BGP > message which eventually leads to session resets, and (b) an > *implementor is to blame* for sending out a BGP messages which > eventually leads to session resets. You really can't have it both > ways. The researcher is not to blame because all the BGP messages he sent out were properly formed. The implementor is to blame becuase the code he wrote send out BGP messages which were not properly formed. > I'm fed up with this situation, and we will fix it this time. My take > is that if you reset the session, you're part of the problem, and > consequently deserve part of the blame. So if you receive a > properly-framed BGP update message you cannot parse, you should just > log it, but not take down the session. If you get your wish, and that gets implemented, in some numer of years trree will be a NANOG posting (perhaps from you, perhaps not) arguing that any malformed BGP message should result in the session being torn down. This will be after a router develops a failure that causes it to send many incorrect messages, but only some of them malformed. So the malformed ones will be discarded, the remainder will be propogated throughout the Internet. If the ones that are incorrect but not malformed are, say, filled with more specifics for large portions of the Internet, someone will be asking: "How could all the other routers accept these advertisement from a router known to be broken ... it was sending malformed advertisements, but instead of tearning down the sessions, you decided to trust all the validly formed messages from this known-to-be-broken router". My point is: we can't always look at the most recent failure to decide what the correct policy is. We have good data on the cases where NOTIFY on any malformed packet has caused significantly outages in the Internet. We don't have nearly as good data on the cases where NOTIFY-on-any-malformed-packet saved the Internet from a significant outage. I don't claim to know which is the bigger problem. But any serious argument to change the behavior needs to consider the risk from propogating information received from a router known to be broken, on the theory that the brokenness only causes malformed messages (which can be discarded) and does not also cause incorrect but correctly formed messages to be sent. -- Brett From mysidia at gmail.com Sat Aug 28 12:47:00 2010 From: mysidia at gmail.com (James Hess) Date: Sat, 28 Aug 2010 12:47:00 -0500 Subject: Did your BGP crash today? In-Reply-To: <4C781312.3010903@otd.com> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> Message-ID: On Fri, Aug 27, 2010 at 2:33 PM, Dave Israel wrote: > On 8/27/2010 3:22 PM, Jared Mauch wrote: [snip] > an MD5 hash that can be added to the packet. ?If the TCP hash checks Hello, layering violation. If the TCP MD5 option was used, the MD5 checksum was probably correct. Malformed BGP Protocol messages, not malformed TCP messages. The BGP protocol that lives on top of TCP is a non-packetized stream. Dropping the IP packets, would just mean that the IP packets containing the malformed BGP data need to get resent (still containing malformed BGP application protocol data, when resent). > out, then you know the packet wasn't garbled, and just contained > information you didn't grok. ?That seems like enough evidence to be able > to shrug and toss the packet without dropping the session. If the attribute is malformed, and in particular, if the _length_ value is malformed, because more bits have been transmitted as part of an update than indicated in the length, how do you reliably determine exactly where the "junk" ends, and the next attribute starts, and resume the stream without loss of other critical data? Without a valid length of the attribute, you don't know which bit the next attribute starts at, or which bit the next update starts at. If the apparently length of the update is wrong, the rest of your session appears to be malformed. If your guess is wrong, you could wind up interpreting part of the attribute DATA portion as another route update, allowing an adversary to exploit the malformed bug to possibly inject new routes. A "recovery" mechanism could lead to worse problems, or lead to problems not being discovered. > -Dave -- -J From john_brzozowski at cable.comcast.com Sat Aug 28 12:49:30 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Sat, 28 Aug 2010 13:49:30 -0400 Subject: Comcast enables 6to4 relays Message-ID: FYI - thought this would be of interest to some of you, there will be more news on this front shortly. http://www.comcast6.net/ 6to4 Relays Activated Tuesday, August 17, 2010 As we started our IPv6 trials, we began to observe an increase in 6to4 relay traffic. 6to4 is a transition mechanism built into some operating systems and home gateways. While it is not a transition technology that Comcast planned to invest in due to limitations related to performance, we did observe poor performance when 6to4 was used by our customers. In many cases, these customers were not even aware that 6to4 was enabled by default or that their device or operating system was attempting to use 6to4 to communicate with IPv6 resources on the Internet. In most cases, we observed that 6to4-enabled operating systems and devices were attempting to use a 6to4 relay infrastructure hosted by a midwestern university. In order to improve the Internet experience for Comcast customers who are using 6to4, whether knowingly or not, we have decided to operate 6to4 relays on a temporary, trial basis. Comcast has decided to deploy 6to4 relays in five locations around our network to improve performance and predictability, as compared to operating relays from a single location. These 6to4 relays are available via the standard 6to4 Anycast IP address, according to RFC 3068, which is 192.88.99.1. Devices attempting to use 6to4 within our network should automatically discover and utilize these new 6to4 relays, without end user intervention or configuration. The first pair of these relays was activated today. We plan to activate the remaining three within the next seven to ten days. We plan to monitor the performance of the 6to4 relays, to measure any beneficial effects resulting from adding these elements to our network. As our IPv6 trials evolve and we develop our plans for 2011 and beyond, we will assess our plans to support 6to4 moving forward. John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com w) http://www.comcast6.net ========================================= From franck at genius.com Sat Aug 28 17:06:32 2010 From: franck at genius.com (Franck Martin) Date: Sun, 29 Aug 2010 10:06:32 +1200 (FJT) Subject: Comcast enables 6to4 relays In-Reply-To: Message-ID: <29207668.798.1283033191735.JavaMail.franck@franck-martins-macbook-pro.local> These are good news. However, if Comcast provides native IPv6 to their customers, then the IPv6 native customers don't need these 6to4 relays? Airport Extreme, Linksys and other user equipment, enable IPv6 by doing 6to4 tunnels, so what this press release says, is that there are many users who are already on IPv6 via Comcast network but not native? Providing relays close to them, is a good transition move. Alternatively, the measurement of this 6to4 bandwidth on IPv4 may give you an idea of the demand for IPv6 from your customers? May be you detected a non null number here? I'm just trying to understand more IPv6 by the examples. I'm personally using 6to4 at home, and experiencing some MTU issues, which seems related to some PTB packets suppressed on the way between some end points, and that can depend on which 6to4 relay I'm using. Still trying to debug this (I'm not too fanatic about it, but work on it when I have a bit of time). I thought I would mention that. The WAND people have done some good studies: http://www.ripe.net/ripe/meetings/ripe-60/presentations/Stasiewicz-Measurements_of_IPv6_Path_MTU_Discovery_Behaviour.pdf At the office, I have a more classical tunnel with he.net and do not have any issue there. ----- Original Message ----- From: "John Jason Brzozowski" To: "NANOG" Sent: Sunday, 29 August, 2010 5:49:30 AM Subject: Comcast enables 6to4 relays FYI - thought this would be of interest to some of you, there will be more news on this front shortly. http://www.comcast6.net/ 6to4 Relays Activated Tuesday, August 17, 2010 As we started our IPv6 trials, we began to observe an increase in 6to4 relay traffic. 6to4 is a transition mechanism built into some operating systems and home gateways. While it is not a transition technology that Comcast planned to invest in due to limitations related to performance, we did observe poor performance when 6to4 was used by our customers. In many cases, these customers were not even aware that 6to4 was enabled by default or that their device or operating system was attempting to use 6to4 to communicate with IPv6 resources on the Internet. From morrowc.lists at gmail.com Sun Aug 29 00:12:00 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 29 Aug 2010 01:12:00 -0400 Subject: Did your BGP crash today? In-Reply-To: <87tymfujqp.fsf@mid.deneb.enyo.de> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <87tymfujqp.fsf@mid.deneb.enyo.de> Message-ID: On Sat, Aug 28, 2010 at 6:14 AM, Florian Weimer wrote: > * Christopher Morrow: > >> (you are asking your vendors to run full bit sweeps of each protocol >> in a regimented manner checking for all possible edge cases and >> properly handling them, right?) > > The real issue is that both spec and current practice say you need to > drop the session as soon as you encounter any unexpected data. ?That's sorry, I conflated two things... or didn't mean to but did anyway. 1) users of gear that does BGP really need to ask loudly and longly (and then go test for themselves) that their BGP speakers do the 'right thing' when faced with oddball scenarios. If someone sends you a previously unknown attribute... don't corrupt it and pass it on, pass if transitive, drop if not. 2) some thought and writing and code-changes need to go into how the bgp-speakers of the world deal with bad-behaving bgp speakers. Is 'send notify and reset' the right answer? is there one 'right answer' ? Should some classes of fugly exchange end with a 'dropped that update, moved along' and some end with 'pull eject handle!' ? it's doubtful that 2 can get solved here (nanog, though certainly some operational thought on the right thing would be great as guidance). i would hope that 1 can get some traction here (via folks going back to their vendors and asking: "Did you run the Mu-security/Oolu-univ/etc fuzzing test suites against this code? can I see the results? I hope they match the results I'm going to be getting from my folks in ~2wks... or we'll be having a much more structured/loud conversation..." another poster had a great point about 'all the world can screw with you, you have no protections other than trust that the next guy won't screw you over (inadvertently)'. There are no protections available to you if someone sets (example) bit 77 in an ipv4 update message to 1 when it should by all accounts be 0. Or (apparently) if they send a previously unknown attribute on a route :( You can put in max-prefix limits, as-path limits (length and content), prefix-filters.. but internal-message-content you are stuck hoping the vendors all followed the same playbook. With everyone saying together: "Please appropriately test your implementation for all boundary cases" maybe we can get to where these happen less often (or nearly never) - every 3 months is a little tedious. -chris From deepak at ai.net Sun Aug 29 00:43:03 2010 From: deepak at ai.net (Deepak Jain) Date: Sun, 29 Aug 2010 01:43:03 -0400 Subject: Did your BGP crash today? Message-ID: On BB, so top posting. Apologies. It seems that creating a worst case BGP test suite for all kinds of nastiness (in light of the recent RIPE thing) might not be a bad idea - so that we can all test the implementation ourselves before we deploy new code. Like all funky attributes, all funky AS SETs... With knobs for 1 to mem exhaust (for long data sets, etc). Unless BGP is massively more complicated than I remember, its not a very advanced CS grad project. I'm thinking a quagga or perl BGP talker would be a good place to start. Deepak ----- Original Message ----- From: Christopher Morrow To: Florian Weimer Cc: nanog at nanog.org Sent: Sun Aug 29 01:12:00 2010 Subject: Re: Did your BGP crash today? On Sat, Aug 28, 2010 at 6:14 AM, Florian Weimer wrote: > * Christopher Morrow: > >> (you are asking your vendors to run full bit sweeps of each protocol >> in a regimented manner checking for all possible edge cases and >> properly handling them, right?) > > The real issue is that both spec and current practice say you need to > drop the session as soon as you encounter any unexpected data. ?That's sorry, I conflated two things... or didn't mean to but did anyway. 1) users of gear that does BGP really need to ask loudly and longly (and then go test for themselves) that their BGP speakers do the 'right thing' when faced with oddball scenarios. If someone sends you a previously unknown attribute... don't corrupt it and pass it on, pass if transitive, drop if not. 2) some thought and writing and code-changes need to go into how the bgp-speakers of the world deal with bad-behaving bgp speakers. Is 'send notify and reset' the right answer? is there one 'right answer' ? Should some classes of fugly exchange end with a 'dropped that update, moved along' and some end with 'pull eject handle!' ? it's doubtful that 2 can get solved here (nanog, though certainly some operational thought on the right thing would be great as guidance). i would hope that 1 can get some traction here (via folks going back to their vendors and asking: "Did you run the Mu-security/Oolu-univ/etc fuzzing test suites against this code? can I see the results? I hope they match the results I'm going to be getting from my folks in ~2wks... or we'll be having a much more structured/loud conversation..." another poster had a great point about 'all the world can screw with you, you have no protections other than trust that the next guy won't screw you over (inadvertently)'. There are no protections available to you if someone sets (example) bit 77 in an ipv4 update message to 1 when it should by all accounts be 0. Or (apparently) if they send a previously unknown attribute on a route :( You can put in max-prefix limits, as-path limits (length and content), prefix-filters.. but internal-message-content you are stuck hoping the vendors all followed the same playbook. With everyone saying together: "Please appropriately test your implementation for all boundary cases" maybe we can get to where these happen less often (or nearly never) - every 3 months is a little tedious. -chris From swmike at swm.pp.se Sun Aug 29 02:19:01 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 29 Aug 2010 09:19:01 +0200 (CEST) Subject: Comcast enables 6to4 relays In-Reply-To: References: Message-ID: On Sat, 28 Aug 2010, John Jason Brzozowski wrote: > In most cases, we observed that 6to4-enabled operating systems and devices > were attempting to use a 6to4 relay infrastructure hosted by a midwestern > university. Before that they used our (Tele2) 6to4 relays in Amsterdam and Paris. I think this was discussed here 1-2 years back. I couldn't find it, but says the same thing. I urge more people to look up what 6to4 relays you're using and set up your own if needed. People *are* using it and you not doing it is making things worse for your customers. Yes, 6to4 is generally bad but it's out there. Everybody needs to think about it. -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Sun Aug 29 02:23:49 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 29 Aug 2010 09:23:49 +0200 (CEST) Subject: Did your BGP crash today? In-Reply-To: <20100828155853.GA12190@panix.com> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> <20100828155853.GA12190@panix.com> Message-ID: On Sat, 28 Aug 2010, Brett Frankenberger wrote: > The implementor is to blame becuase the code he wrote send out BGP > messages which were not properly formed. People talk about not dropping sessions but instead dropping malformed messages. This is not safe. We've seen ISIS (which is TLV based and *can* drop individual messages) been wrongly implemented and platforms drop the entire ISIS *packet* instead of the individual message when seeing something malformed (or rather in this case, ISIS multi topology which the implementation didn't understand), and this made the link state database go out of sync and miss information for things it actually should have understood. This was *silent* error/corruption. I'm not sure I prefer to have silent problems instead of tearing down the session which is definitely noticable. -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Sun Aug 29 02:28:34 2010 From: randy at psg.com (Randy Bush) Date: Sun, 29 Aug 2010 16:28:34 +0900 Subject: Did your BGP crash today? In-Reply-To: References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> <20100828155853.GA12190@panix.com> Message-ID: > This was *silent* error/corruption. I'm not sure I prefer to have > silent problems instead of tearing down the session which is > definitely noticable. i call the silent fix "do-gooder software." it means to do good. when it works, nobody notices or says thanks. when it fails, there is hell to pay. randy From fergdawgster at gmail.com Sun Aug 29 02:30:21 2010 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sun, 29 Aug 2010 00:30:21 -0700 Subject: Did your BGP crash today? In-Reply-To: References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> <20100828155853.GA12190@panix.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Aug 29, 2010 at 12:23 AM, Mikael Abrahamsson wrote: > On Sat, 28 Aug 2010, Brett Frankenberger wrote: > >> The implementor is to blame becuase the code he wrote send out BGP >> messages which were not properly formed. > > People talk about not dropping sessions but instead dropping malformed > messages. This is not safe. We've seen ISIS (which is TLV based and *can* > drop individual messages) been wrongly implemented and platforms drop the > entire ISIS *packet* instead of the individual message when seeing > something malformed (or rather in this case, ISIS multi topology which > the > implementation didn't understand), and this made the link state database > go out of sync and miss information for things it actually should have > understood. > > This was *silent* error/corruption. I'm not sure I prefer to have silent > problems instead of tearing down the session which is definitely > noticable. > It would seem to me that there should actually be a better option, e.g. recognizing the malformed update, and simply discarding it (and sending the originator an error message) instead of resetting the session. Resetting of BGP sessions should only be done in the most dire of circumstances, to avoid a widespread instability incident. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMegyGq1pz9mNUZTMRAr6tAKDHDZk2/Yk3bHNKTvCJeniTCEdPvwCg0zhk HX/E0XsFOIURWI8UlfpM2Ms= =PSz3 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From adrian at creative.net.au Sun Aug 29 02:35:29 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Sun, 29 Aug 2010 15:35:29 +0800 Subject: Complain to your vendors (was Re: Did your BGP crash today?) Message-ID: <20100829073529.GA9681@skywalker.creative.net.au> Guys/girls/furry-creatures-from-!Earth, Complaining on nanog-ml is likely to only achieve personal stress relief. This is something you should bring up with your vendor. Say that you'll move vendors if they don't start making "better" BGP implementations and adding the features you guys want. Make the list of "better" features open, public, and actively solicit alternatives. Follow up on your threat. This is your business bottom line after all. Don't just use it as a reason to get lower prices from your current vendor and then continue complaining when dumb crap like this occurs. It would be great if vendor(s) participated in a public interoperability test suite where researchers could test their stuff against it before unleashing it on the public internet. I'd love to see something public -and- cross institutional, -and- include access to things like CRS-level equipment. Go on, I dare you. :) 2c, Adrian From fergdawgster at gmail.com Sun Aug 29 02:40:11 2010 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sun, 29 Aug 2010 00:40:11 -0700 Subject: Complain to your vendors (was Re: Did your BGP crash today?) In-Reply-To: <20100829073529.GA9681@skywalker.creative.net.au> References: <20100829073529.GA9681@skywalker.creative.net.au> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Aug 29, 2010 at 12:35 AM, Adrian Chadd wrote: > Guys/girls/furry-creatures-from-!Earth, > > Complaining on nanog-ml is likely to only achieve personal stress relief. > > This is something you should bring up with your vendor. Say that you'll > move vendors if they don't start making "better" BGP implementations and > adding the features you guys want. Make the list of "better" features > open, public, and actively solicit alternatives. Follow up on your > threat. This is your business bottom line after all. > > Don't just use it as a reason to get lower prices from your current > vendor and then continue complaining when dumb crap like this occurs. > > It would be great if vendor(s) participated in a public interoperability > test suite where researchers could test their stuff against it before > unleashing it on the public internet. I'd love to see something public > -and- cross institutional, -and- include access to things like CRS-level > equipment. > > Go on, I dare you. :) > Maybe the NANOG conference committee (or whatever its called) could get a couple of major router vendor gerbils to come to the next NANOG and talk to this issue? Maybe? Okay, I give up. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMeg7Uq1pz9mNUZTMRAtLzAJwNzJMf4YwjP9C42CFANvESJCVoDQCg9trZ lS5Wd5kpH27JBLKkDhibIOg= =fdTs -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From rdobbins at arbor.net Sun Aug 29 05:22:39 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 29 Aug 2010 10:22:39 +0000 Subject: Did your BGP crash today? In-Reply-To: References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> <20100828155853.GA12190@panix.com> Message-ID: <88B6EF77-AADB-4036-A160-2FB325A6C573@arbor.net> On Aug 29, 2010, at 2:30 PM, Paul Ferguson wrote: > It would seem to me that there should actually be a better option, e.g. recognizing the malformed update, and simply discarding it (and sending the originator an error message) instead of resetting the session. Generation of the error message should probably have a user toggle. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From john_brzozowski at cable.comcast.com Sun Aug 29 08:25:23 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Sun, 29 Aug 2010 09:25:23 -0400 Subject: Comcast enables 6to4 relays In-Reply-To: <29207668.798.1283033191735.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: Franck, As you know 6to4 is enabled by default in many cases and is used perhaps more than folks realize. Because of this and other observations we decided to deploy our own relays. This does not alter our plans for our native dual stack trials, in fact, I hope to have more news on this front soon. It is true that 6to4 has challenges, some of these may be related to how 6to4 relays have been deployed. Others may be related to the protocol itself. Either way, by deploying our own we observed an improvement, we hope others have as well. John On 8/28/10 6:06 PM, "Franck Martin" wrote: > These are good news. > > However, if Comcast provides native IPv6 to their customers, then the IPv6 > native customers don't need these 6to4 relays? > > Airport Extreme, Linksys and other user equipment, enable IPv6 by doing 6to4 > tunnels, so what this press release says, is that there are many users who are > already on IPv6 via Comcast network but not native? Providing relays close to > them, is a good transition move. Alternatively, the measurement of this 6to4 > bandwidth on IPv4 may give you an idea of the demand for IPv6 from your > customers? May be you detected a non null number here? > > I'm just trying to understand more IPv6 by the examples. > > I'm personally using 6to4 at home, and experiencing some MTU issues, which > seems related to some PTB packets suppressed on the way between some end > points, and that can depend on which 6to4 relay I'm using. Still trying to > debug this (I'm not too fanatic about it, but work on it when I have a bit of > time). I thought I would mention that. > The WAND people have done some good studies: > http://www.ripe.net/ripe/meetings/ripe-60/presentations/Stasiewicz-Measurement > s_of_IPv6_Path_MTU_Discovery_Behaviour.pdf > > At the office, I have a more classical tunnel with he.net and do not have any > issue there. > > ----- Original Message ----- > From: "John Jason Brzozowski" > To: "NANOG" > Sent: Sunday, 29 August, 2010 5:49:30 AM > Subject: Comcast enables 6to4 relays > > FYI - thought this would be of interest to some of you, there will be more > news on this front shortly. > > http://www.comcast6.net/ > > 6to4 Relays Activated > Tuesday, August 17, 2010 > > As we started our IPv6 trials, we began to observe an increase in 6to4 relay > traffic. 6to4 is a transition mechanism built into some operating systems > and home gateways. While it is not a transition technology that Comcast > planned to invest in due to limitations related to performance, we did > observe poor performance when 6to4 was used by our customers. In many cases, > these customers were not even aware that 6to4 was enabled by default or that > their device or operating system was attempting to use 6to4 to communicate > with IPv6 resources on the Internet. > > > > ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From john_brzozowski at cable.comcast.com Sun Aug 29 08:28:42 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Sun, 29 Aug 2010 09:28:42 -0400 Subject: Comcast enables 6to4 relays In-Reply-To: Message-ID: Mikael, I agree with your points and echoed them in my earlier reply. 6to4 is out there and is likely not to go away any time soon. Folks should definitely see what 6to4 relay they default to, you might be surprised (or not). FWIW - I updated ARIN's wiki for 6to4 relay deployment with some generic updates. I will add some more text shortly that folks may find useful if they decide to deploy their own 6to4 relays. John On 8/29/10 3:19 AM, "Mikael Abrahamsson" wrote: > On Sat, 28 Aug 2010, John Jason Brzozowski wrote: > >> In most cases, we observed that 6to4-enabled operating systems and devices >> were attempting to use a 6to4 relay infrastructure hosted by a midwestern >> university. > > Before that they used our (Tele2) 6to4 relays in Amsterdam and Paris. I > think this was discussed here 1-2 years back. > > I couldn't find it, but > > says the same thing. > > I urge more people to look up what 6to4 relays you're using and set up > your own if needed. People *are* using it and you not doing it is making > things worse for your customers. Yes, 6to4 is generally bad but it's out > there. Everybody needs to think about it. ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From rbf+nanog at panix.com Sun Aug 29 09:11:03 2010 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sun, 29 Aug 2010 09:11:03 -0500 Subject: Did your BGP crash today? In-Reply-To: References: <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> <20100828155853.GA12190@panix.com> Message-ID: <20100829141102.GA6540@panix.com> On Sun, Aug 29, 2010 at 12:30:21AM -0700, Paul Ferguson wrote: > > It would seem to me that there should actually be a better option, e.g. > recognizing the malformed update, and simply discarding it (and sending the > originator an error message) instead of resetting the session. > > Resetting of BGP sessions should only be done in the most dire of > circumstances, to avoid a widespread instability incident. The only thing you know for sure when you receive a malformed update is that the router on the other end of the connection is broken (or that there's something in between the other router and you that is corrupting messages, but for the purposes of this, that's essentially the same thing). Accepting information received from a router known to be broken, and then passing that on to other routers, is a bad idea and something that could lead to a widespread instability incident. Of course, in theory, you discard the bad updates and only pass on the good updates, but doing that relies on the assumption that the known-to-be-broken router on the other end of the connection is broken in such a way that ensures that all the corrupted messages it sends will be recognizable as malformed and can be discarded. There's plenty of corruption that can't be detected on the receiving end. On top of that, there's problems with being out of sync with the router on the other end. For example, suppose a router developed a condition that caused it to malform all withdraw messages (or, more precisely, all UPDATE messages where the withdrarn routes length field is non-zero). If we implement what you suggest above, then we'll accept all the advertisements from that router, but ignore all the withdraws, and end up sending that router a bunch of traffic that it won't actually be able to handle. -- Brett From vixie at isc.org Sun Aug 29 11:21:51 2010 From: vixie at isc.org (Paul Vixie) Date: Sun, 29 Aug 2010 16:21:51 +0000 Subject: Comcast enables 6to4 relays In-Reply-To: (John Jason Brzozowski's message of "Sun, 29 Aug 2010 09:25:23 -0400") References: <29207668.798.1283033191735.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: John Jason Brzozowski writes: > This does not alter our plans for our native dual stack trials, in fact, I > hope to have more news on this front soon. comcast native dual stack is working fine at my house. "traceroute6 -q1 mol.redbarn.org" shows details. From joelja at bogus.com Sun Aug 29 11:24:13 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 29 Aug 2010 09:24:13 -0700 Subject: Comcast enables 6to4 relays In-Reply-To: References: Message-ID: <4C7A89AD.1050107@bogus.com> On 8/29/10 6:25 AM, John Jason Brzozowski wrote: > Franck, > > As you know 6to4 is enabled by default in many cases and is used perhaps > more than folks realize. Because of this and other observations we decided > to deploy our own relays. Right prior to this the nearest 6to4 relay router from the vantage-point of comcast customers was at AMSIX. It's a given that you're going to have path asymmetry, in this case however it was frequently worse in one direction than in the other. This ought greatly improve the performance of existing devices located at comcast's customers. > This does not alter our plans for our native dual stack trials, in fact, I > hope to have more news on this front soon. > > It is true that 6to4 has challenges, some of these may be related to how > 6to4 relays have been deployed. Others may be related to the protocol > itself. Either way, by deploying our own we observed an improvement, we > hope others have as well. > > John > > On 8/28/10 6:06 PM, "Franck Martin" wrote: > >> These are good news. >> >> However, if Comcast provides native IPv6 to their customers, then the IPv6 >> native customers don't need these 6to4 relays? >> >> Airport Extreme, Linksys and other user equipment, enable IPv6 by doing 6to4 >> tunnels, so what this press release says, is that there are many users who are >> already on IPv6 via Comcast network but not native? Providing relays close to >> them, is a good transition move. Alternatively, the measurement of this 6to4 >> bandwidth on IPv4 may give you an idea of the demand for IPv6 from your >> customers? May be you detected a non null number here? >> >> I'm just trying to understand more IPv6 by the examples. >> >> I'm personally using 6to4 at home, and experiencing some MTU issues, which >> seems related to some PTB packets suppressed on the way between some end >> points, and that can depend on which 6to4 relay I'm using. Still trying to >> debug this (I'm not too fanatic about it, but work on it when I have a bit of >> time). I thought I would mention that. >> The WAND people have done some good studies: >> http://www.ripe.net/ripe/meetings/ripe-60/presentations/Stasiewicz-Measurement >> s_of_IPv6_Path_MTU_Discovery_Behaviour.pdf >> >> At the office, I have a more classical tunnel with he.net and do not have any >> issue there. >> >> ----- Original Message ----- >> From: "John Jason Brzozowski" >> To: "NANOG" >> Sent: Sunday, 29 August, 2010 5:49:30 AM >> Subject: Comcast enables 6to4 relays >> >> FYI - thought this would be of interest to some of you, there will be more >> news on this front shortly. >> >> http://www.comcast6.net/ >> >> 6to4 Relays Activated >> Tuesday, August 17, 2010 >> >> As we started our IPv6 trials, we began to observe an increase in 6to4 relay >> traffic. 6to4 is a transition mechanism built into some operating systems >> and home gateways. While it is not a transition technology that Comcast >> planned to invest in due to limitations related to performance, we did >> observe poor performance when 6to4 was used by our customers. In many cases, >> these customers were not even aware that 6to4 was enabled by default or that >> their device or operating system was attempting to use 6to4 to communicate >> with IPv6 resources on the Internet. >> >> >> >> > > ========================================= > John Jason Brzozowski > Comcast Cable > e) mailto:john_brzozowski at cable.comcast.com > o) 609-377-6594 > m) 484-962-0060 > w) http://www.comcast6.net > ========================================= > > From bjorn at mork.no Sun Aug 29 11:31:26 2010 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Sun, 29 Aug 2010 18:31:26 +0200 Subject: Did your BGP crash today? In-Reply-To: <20100827191324.GJ1946@gerbil.cluepon.net> (Richard A. Steenbergen's message of "Fri, 27 Aug 2010 14:13:24 -0500") References: <20100827191324.GJ1946@gerbil.cluepon.net> Message-ID: <87bp8l4bz5.fsf@nemi.mork.no> Richard A Steenbergen writes: > Just out of curiosity, at what point will we as operators rise up > against the ivory tower protocol designers at the IETF and demand that > they add a mechanism to not bring down the entire BGP session because of > a single malformed attribute? Did I miss the memo about the meeting? I guess you did. http://tools.ietf.org/html/draft-ietf-idr-optional-transitive-02 Bj?rn From william.allen.simpson at gmail.com Sun Aug 29 11:43:18 2010 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Sun, 29 Aug 2010 12:43:18 -0400 Subject: Did your BGP crash today? In-Reply-To: References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> <20100828155853.GA12190@panix.com> Message-ID: <4C7A8E26.2020009@gmail.com> On 8/29/10 3:23 AM, Mikael Abrahamsson wrote: > On Sat, 28 Aug 2010, Brett Frankenberger wrote: > >> The implementor is to blame becuase the code he wrote send out BGP messages which were not properly formed. > > People talk about not dropping sessions but instead dropping malformed messages. This is not safe. We've seen ISIS (which is TLV based and *can* drop individual messages) been wrongly implemented and platforms drop the entire ISIS *packet* instead of the > individual message when seeing something malformed (or rather in this case, ISIS multi topology which the implementation didn't understand), and this made the link state database go out of sync and miss information for things it actually should have > understood. > Reminder: TCP itself has also "been wrongly implemented" with horrid consequences. Unknown TCP options are supposed to be silently discarded. Instead, some middlebox vendors simply copy them into the return packet. There are some circumstances where it makes sense to silently discard one TLV option, and others where it makes sense to discard the whole packet, and still others where it makes sense to drop the session. A problem is that many of the early designers (BGP is a fairly early design) used one-size-fits-all error handling. There's not much anybody can do about bad implementation (as in this case) that corrupts data. But a lot more thought needs to go into error recovery! > This was *silent* error/corruption. I'm not sure I prefer to have silent problems instead of tearing down the session which is definitely noticable. > Personally, I've usually advocated returning an error message. Many of the protocols I've developed use this approach. (Please forgive RADIUS, which for some odd reason is my most frequently cited work according to Google. My original draft had a Reject, subsequent WG activity took it away. All I could do is throw up my hands and walk away.) From joelja at bogus.com Sun Aug 29 11:58:48 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 29 Aug 2010 09:58:48 -0700 Subject: Did your BGP crash today? In-Reply-To: <87bp8l4bz5.fsf@nemi.mork.no> References: <20100827191324.GJ1946@gerbil.cluepon.net> <87bp8l4bz5.fsf@nemi.mork.no> Message-ID: <4C7A91C8.1070909@bogus.com> On 8/29/10 9:31 AM, Bj?rn Mork wrote: > Richard A Steenbergen writes: > >> Just out of curiosity, at what point will we as operators rise up >> against the ivory tower protocol designers at the IETF and demand that >> they add a mechanism to not bring down the entire BGP session because of >> a single malformed attribute? Did I miss the memo about the meeting? > > I guess you did. > > http://tools.ietf.org/html/draft-ietf-idr-optional-transitive-02 rfc 4893 (4 octet as numbers) leverages the assumption that you can send the as4_path attribute and that even router's that don't understand it will forward it. given that 4 byte as numbers exist in the internet and many non-4byte aware routers exist, that seems like a reasonable assumption. > > Bj?rn > > From joelja at bogus.com Sun Aug 29 12:13:44 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 29 Aug 2010 10:13:44 -0700 Subject: Did your BGP crash today? In-Reply-To: <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> Message-ID: <4C7A9548.5080604@bogus.com> On 8/27/10 1:07 PM, Mike Gatti wrote: > where's the change management process in all of this. > basically now we are going to starting changing things that can > potentially have an adverse affect on users without letting anyone know > before hand .... Interesting concept. BGP is transitive, change management is not. you have a change management process, your peer might integrate into that but have their own, your peer's peers almost certainly do not. Every time a wet-behind-the-ears network engineer connects a bgp speaker to the edge of the network it's an experiment in the the stability of the Internet. This on the fact of it seems like a quite reasonable experiment, which should have worked, except that it happened to tickle a bug... > On Aug 27, 2010, at 3:33 PM, Dave Israel wrote: > >> >> On 8/27/2010 3:22 PM, Jared Mauch wrote: >>> When you are processing something, it's sometimes hard to tell if something >>> just was mis-parsed (as I think the case is here with the "missing-2-bytes") >>> vs just getting garbage. Perhaps there should be some way to "re-sync" when >>> you are having this problem, or a parallel "keepalive" path similar to >>> MACA/MCAS/MIDCAS/TCAS between the devices to talk when something bad is >>> happening. >> >> I know it wasn't there originally, and isn't mandatory now, but there is >> an MD5 hash that can be added to the packet. If the TCP hash checks >> out, then you know the packet wasn't garbled, and just contained >> information you didn't grok. That seems like enough evidence to be able >> to shrug and toss the packet without dropping the session. >> >> -Dave >> >> >> > > =+=+=+=+=+=+=+=+=+=+=+=+= > Mike Gatti > ekim.ittag at gmail.com > =+=+=+=+=+=+=+=+=+=+=+=+= > > > > > From john_brzozowski at cable.comcast.com Sun Aug 29 12:27:05 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Sun, 29 Aug 2010 13:27:05 -0400 Subject: Comcast enables 6to4 relays In-Reply-To: <4C7A89AD.1050107@bogus.com> Message-ID: Before we turned up our own relays the closest 6to4 relay was a single relay hosted by a mid-western university. Regardless where the next closest relays are located deploying our own resulted in improvements (as you pointed out below). John On 8/29/10 12:24 PM, "Joel Jaeggli" wrote: > On 8/29/10 6:25 AM, John Jason Brzozowski wrote: >> Franck, >> >> As you know 6to4 is enabled by default in many cases and is used perhaps >> more than folks realize. Because of this and other observations we decided >> to deploy our own relays. > > Right prior to this the nearest 6to4 relay router from the vantage-point > of comcast customers was at AMSIX. It's a given that you're going to > have path asymmetry, in this case however it was frequently worse in one > direction than in the other. > > This ought greatly improve the performance of existing devices located > at comcast's customers. > >> This does not alter our plans for our native dual stack trials, in fact, I >> hope to have more news on this front soon. >> >> It is true that 6to4 has challenges, some of these may be related to how >> 6to4 relays have been deployed. Others may be related to the protocol >> itself. Either way, by deploying our own we observed an improvement, we >> hope others have as well. >> >> John >> >> On 8/28/10 6:06 PM, "Franck Martin" wrote: >> >>> These are good news. >>> >>> However, if Comcast provides native IPv6 to their customers, then the IPv6 >>> native customers don't need these 6to4 relays? >>> >>> Airport Extreme, Linksys and other user equipment, enable IPv6 by doing 6to4 >>> tunnels, so what this press release says, is that there are many users who >>> are >>> already on IPv6 via Comcast network but not native? Providing relays close >>> to >>> them, is a good transition move. Alternatively, the measurement of this 6to4 >>> bandwidth on IPv4 may give you an idea of the demand for IPv6 from your >>> customers? May be you detected a non null number here? >>> >>> I'm just trying to understand more IPv6 by the examples. >>> >>> I'm personally using 6to4 at home, and experiencing some MTU issues, which >>> seems related to some PTB packets suppressed on the way between some end >>> points, and that can depend on which 6to4 relay I'm using. Still trying to >>> debug this (I'm not too fanatic about it, but work on it when I have a bit >>> of >>> time). I thought I would mention that. >>> The WAND people have done some good studies: >>> http://www.ripe.net/ripe/meetings/ripe-60/presentations/Stasiewicz-Measureme >>> nt >>> s_of_IPv6_Path_MTU_Discovery_Behaviour.pdf >>> >>> At the office, I have a more classical tunnel with he.net and do not have >>> any >>> issue there. >>> >>> ----- Original Message ----- >>> From: "John Jason Brzozowski" >>> To: "NANOG" >>> Sent: Sunday, 29 August, 2010 5:49:30 AM >>> Subject: Comcast enables 6to4 relays >>> >>> FYI - thought this would be of interest to some of you, there will be more >>> news on this front shortly. >>> >>> http://www.comcast6.net/ >>> >>> 6to4 Relays Activated >>> Tuesday, August 17, 2010 >>> >>> As we started our IPv6 trials, we began to observe an increase in 6to4 relay >>> traffic. 6to4 is a transition mechanism built into some operating systems >>> and home gateways. While it is not a transition technology that Comcast >>> planned to invest in due to limitations related to performance, we did >>> observe poor performance when 6to4 was used by our customers. In many cases, >>> these customers were not even aware that 6to4 was enabled by default or that >>> their device or operating system was attempting to use 6to4 to communicate >>> with IPv6 resources on the Internet. >>> >>> >>> >>> >> >> ========================================= >> John Jason Brzozowski >> Comcast Cable >> e) mailto:john_brzozowski at cable.comcast.com >> o) 609-377-6594 >> m) 484-962-0060 >> w) http://www.comcast6.net >> ========================================= >> >> > ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From thomas.mangin at exa-networks.co.uk Sun Aug 29 14:50:26 2010 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Sun, 29 Aug 2010 21:50:26 +0200 Subject: Did your BGP crash today? In-Reply-To: References: Message-ID: <98B64AC5-0EFB-464E-AF35-C0E1E7C64F29@exa-networks.co.uk> > It seems that creating a worst case BGP test suite for all kinds of nastiness (in light of the recent RIPE thing) might not be a bad idea - so that we can all test the implementation ourselves before we deploy new code. Normally those things are done by vendors - that what we pay them good money for software update and support. You need a fully mesh network of all the vendors as it would seems that you need to check the outgoing packet as well as making sure the router is as well not chocking on the packet. Definitively no rocket science, still quite some work for something which should not be the end-user's problem. Thomas From thomas.mangin at exa-networks.co.uk Sun Aug 29 15:12:35 2010 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Sun, 29 Aug 2010 22:12:35 +0200 Subject: Did your BGP crash today? In-Reply-To: References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> <20100828155853.GA12190@panix.com> Message-ID: <4EC01755-8572-4AAD-9470-BDD4F6841A3F@exa-networks.co.uk> > It would seem to me that there should actually be a better option, e.g. > recognizing the malformed update, and simply discarding it (and sending the > originator an error message) instead of resetting the session. > > Resetting of BGP sessions should only be done in the most dire of > circumstances, to avoid a widespread instability incident. I had the same thought before giving up on it. Negotiating a new error message could be a per peer option. BGP has capabilities for this exact reason. However to make sense you would need to find a resynchronisation point to only exclude the one faulty message. Initially I thought that the last received KEEPALIVE (for the receiver of the error message) could do - but you find yourselves with races conditions - so perhaps two KEEPALIVE back ? Each TCP packet can contain multiple message, so the messages would have to be then split and ACK individually to find the faulty one and then ACK individually. EOR could be used for that purpose. Still it adds lots of complexity in the conversation - are we not going to introduce bug in that not much used and tested code path as well ? Unless you have a new "ACK" capability for each message - another idea but those are clearly a discussions for outside NANOG. Thomas From franck at genius.com Sun Aug 29 18:24:41 2010 From: franck at genius.com (Franck Martin) Date: Mon, 30 Aug 2010 11:24:41 +1200 (FJT) Subject: Comcast enables 6to4 relays In-Reply-To: <4C7A89AD.1050107@bogus.com> Message-ID: <22190054.1139.1283124279212.JavaMail.franck@franck-martins-macbook-pro.local> As the 6to4 is an "default" option on Apple Airport Extreme to enable ipv6, I would have thought that Apple would have provided a few gateways? Same for Microsoft that has it in its OS? Reminds me of the ntp servers issue built in on some devices... From mysidia at gmail.com Sun Aug 29 22:32:38 2010 From: mysidia at gmail.com (James Hess) Date: Sun, 29 Aug 2010 22:32:38 -0500 Subject: Did your BGP crash today? In-Reply-To: <4EC01755-8572-4AAD-9470-BDD4F6841A3F@exa-networks.co.uk> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> <20100828155853.GA12190@panix.com> <4EC01755-8572-4AAD-9470-BDD4F6841A3F@exa-networks.co.uk> Message-ID: On Sun, Aug 29, 2010 at 3:12 PM, Thomas Mangin wrote: > However to make sense you would need to find a resynchronisation point to only exclude the one faulty message. Initially I thought that the last received KEEPALIVE (for the receiver of the error message) could do - but you find yourselves with races conditions - so perhaps two KEEPALIVE back ? > Each TCP packet can contain multiple message, so the messages would have to be then split and ACK individually to find the faulty one and then ACK individually. EOR could be used for that purpose. Every BGP message header has a portion that starts with 16 all-bits-1 octets, for compatibility. This is distinctive enough an implementation can guess where the next message starts. However, suppose you have an attacker.. if for example, a BGP speaker passes on too short a length value for an attribute... and the attacker knows what length will be sent instead of the right one. Places an entry into the Data portion, that will appear to the other peer to be "the rest" of the malformed update, Result: the "malformed" update is received and appears to be perfectly valid. The next thing the attacker inserts into the data portion of the attribute is the 16 all-bits-1 octets, BGP header, update message, and their malicious update. This will appear properly formed, when the buggy BGP speaker sends it. As far as the buggy BGP speaker is concerned, it has propagated 1 route update. As far as the buggy BGP speaker's other peers are concerned, they have received 3 messages from the buggy speaker. * The update "completed" in the attribute data section. (This is "malformed", but intentionally not detectable as malformed) * The maliciously injected route. (This isn't supposed to exist. The buggy speaker is unaware of its existence, there is a disagreement between peers about how the message is interpreted) * A malformed message that does not make any sense. If the injection were perfect, nothing would be detectable as malformed. But alas, the attacker does not know exactly what other attributes or prepending buggy router will add to the message before passing it on. They could work this out through trial and error, however, some admin will hopefully notice all the CEASEs, before the attacker achieved complete success. In this case, by the time the other speakers detect something as malformed, the two preceding updates are already in the table, and possibly even propagated further. A "CEASE" rolls this back, by rolling back the entire session. Peers could (perhaps) safely re-synchronize in this case is if there was an extension to partially roll back some of the updates in a session and request a portion of the messages to be resent. Or if an extension such as authentication is used to make it impossible to inject BGP messages within the value of an attribute. Through data quarantine: requiring all BGP speakers to disallow the all-bits-1 sequence in any attribute value. Or through peer-specific authentication mechanisms, or checksums and digital signature, in the message header portion of each BGP message. -- -J From randy at psg.com Sun Aug 29 22:41:35 2010 From: randy at psg.com (Randy Bush) Date: Mon, 30 Aug 2010 12:41:35 +0900 Subject: Did your BGP crash today? In-Reply-To: References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> <20100828155853.GA12190@panix.com> <4EC01755-8572-4AAD-9470-BDD4F6841A3F@exa-networks.co.uk> Message-ID: > Every BGP message header has a portion that starts with 16 > all-bits-1 octets, for compatibility. > This is distinctive enough an implementation can guess where the next > message starts. i desperately feared reading this. i do not want to bet the internet on guessing where anythings starts. randy From feldman at twincreeks.net Sun Aug 29 23:02:59 2010 From: feldman at twincreeks.net (Steve Feldman) Date: Sun, 29 Aug 2010 21:02:59 -0700 Subject: [NANOG-announce] Reminder: NANOG Steering Committee nominations close soon In-Reply-To: <2E74F72E-843F-48D7-9A72-C124A32CE327@twincreeks.net> References: <2E74F72E-843F-48D7-9A72-C124A32CE327@twincreeks.net> Message-ID: The deadline for nominations for the NANOG Steering Committee is tomorrow, at 11:59 PM EDT on Monday, August 30. If you are interested in running for an SC position, or know someone who might be a good candidate, please send the nomination to nominations at nanog.org. More details are below. This is a very important time in the evolution of NANOG, and the SC members elected this fall will have a great opportunity to help represent the community and shape our future. For the SC, Steve Feldman > Elections for three of the six elected positions on the NANOG Steering Committee will be held in October, 2010, for two-year terms ending in October, 2012. > > The current SC members whose terms are expiring are Patrick Gilmore, Joe Provo, and Robert Seastrom. Joe is finishing his second consecutive term, so per the charter, cannot be considered for reelection until October 2011. > If you care about NANOG as a forum, and think you would like to take a turn at volunteering your time to help make it better, please consider either volunteering yourself or nominating someone else. > > For more information about the role of the Steering Committee, or to find out more about what's involved in being a Steering Committee member, please consult the NANOG charter or contact someone who is already serving and ask them directly. > > http://www.nanog.org/governance/charter/ > http://www.nanog.org/governance/steering/steeringcommittee.php > > Per the charter, Steering Committee members must attend at least two of three NANOG meetings per year while in office. > > HOW TO NOMINATE SOMEONE > > You may nominate someone else, or yourself. There is no limit to the number of nominations that may be submitted by a single person. Individual nominees will be contacted directly to confirm that they are willing to accept the nomination, and so that they can supply a biography for the NANOG web page. > > To submit a nomination, send the nominee's full name and contact details to nominations at nanog.org. The deadline for nominations is 11:59 PM EDT on Monday, August 30. > > The candidates will be given an opportunity to make brief comments and/or accept questions from the community at the NANOG 50 Community Meeting on Sunday, October 3. > > As a reminder, the full election timeline is: > > Aug. 2 - SC Nominations begin > Aug. 24 - Potential charter amendments discussed in nanog-futures > Aug. 24 - PC Nominations begin > Aug. 30 - SC Candidate information posted/nominations close > Sep. 13 - Call for Communications Committee nominations > Sep. 21 - Ballot approved > Oct. 3 - Voting opens at 12:00 EDT > Oct. 4 - PC Candidate Information posted/nominations close > Oct. 6 - Voting closes at 09:15 EDT, results announced > before the close of NANOG 50. _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From cjeker at diehard.n-r-g.com Mon Aug 30 02:51:52 2010 From: cjeker at diehard.n-r-g.com (Claudio Jeker) Date: Mon, 30 Aug 2010 09:51:52 +0200 Subject: Did your BGP crash today? In-Reply-To: <4EC01755-8572-4AAD-9470-BDD4F6841A3F@exa-networks.co.uk> References: <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> <20100828155853.GA12190@panix.com> <4EC01755-8572-4AAD-9470-BDD4F6841A3F@exa-networks.co.uk> Message-ID: <20100830075152.GA19972@diehard.n-r-g.com> On Sun, Aug 29, 2010 at 10:12:35PM +0200, Thomas Mangin wrote: > > It would seem to me that there should actually be a better option, e.g. > > recognizing the malformed update, and simply discarding it (and sending the > > originator an error message) instead of resetting the session. > > > > Resetting of BGP sessions should only be done in the most dire of > > circumstances, to avoid a widespread instability incident. > > > I had the same thought before giving up on it. > > Negotiating a new error message could be a per peer option. BGP has > capabilities for this exact reason. > > However to make sense you would need to find a resynchronisation point > to only exclude the one faulty message. Initially I thought that the > last received KEEPALIVE (for the receiver of the error message) could do > - but you find yourselves with races conditions - so perhaps two > KEEPALIVE back ? Apart from one big vendor most BGP speaker only send KEEPALIVES when they need to. So on my full feeds I see sessions running for more then 1 month which received less then 300 KEEPALIVE packets. -- :wq Claudio From thomas.mangin at exa-networks.co.uk Mon Aug 30 03:58:09 2010 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Mon, 30 Aug 2010 10:58:09 +0200 Subject: Did your BGP crash today? In-Reply-To: <20100830075152.GA19972@diehard.n-r-g.com> References: <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> <20100828155853.GA12190@panix.com> <4EC01755-8572-4AAD-9470-BDD4F6841A3F@exa-networks.co.uk> <20100830075152.GA19972@diehard.n-r-g.com> Message-ID: <95795D09-D859-4170-A20D-3D67C83CE380@exa-networks.co.uk> > Apart from one big vendor most BGP speaker only send KEEPALIVES when they > need to. So on my full feeds I see sessions running for more then 1 month > which received less then 300 KEEPALIVE packets. The negociaged holdtime is always the lower value presented between two routers. The default HoldTime timer for Cisco is 180 seconds and for Juniper 90. So you should see a KEEPALIVE packet every minute from/to Cisco routers, and one every 30 seconds between Junipers. Should a BGP speaker do not see any KEEPALIVE during $HOLDTIME, it will tear the session down. You are telling me that your effective holdtime is 2592000 seconds when the HOLDTIME field is 16 bits ... hum ... http://www.faqs.org/rfcs/rfc4271.html section 4.2 So unless you know something I don't, I believe you are totally mistaken :) Thomas From daniel at bit.nl Mon Aug 30 04:08:49 2010 From: daniel at bit.nl (Daniel Verlouw) Date: Mon, 30 Aug 2010 11:08:49 +0200 Subject: Did your BGP crash today? In-Reply-To: <95795D09-D859-4170-A20D-3D67C83CE380@exa-networks.co.uk> References: <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> <20100828155853.GA12190@panix.com> <4EC01755-8572-4AAD-9470-BDD4F6841A3F@exa-networks.co.uk> <20100830075152.GA19972@diehard.n-r-g.com> <95795D09-D859-4170-A20D-3D67C83CE380@exa-networks.co.uk> Message-ID: <1283159329.30109.2.camel@daniel> On Mon, 2010-08-30 at 10:58 +0200, Thomas Mangin wrote: > http://www.faqs.org/rfcs/rfc4271.html section 4.2 > > So unless you know something I don't, I believe you are totally mistaken :) updates serve as implicit keepalives. in that same section: "Hold Time: The calculated value indicates the maximum number of seconds that may elapse between the receipt of successive KEEPALIVE and/or UPDATE messages from the sender." also check section 6.5: "If a system does not receive successive KEEPALIVE, UPDATE, and/or NOTIFICATION messages [...]" --Daniel From thomas.mangin at exa-networks.co.uk Mon Aug 30 04:18:22 2010 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Mon, 30 Aug 2010 11:18:22 +0200 Subject: Did your BGP crash today? In-Reply-To: <1283159329.30109.2.camel@daniel> References: <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> <20100828155853.GA12190@panix.com> <4EC01755-8572-4AAD-9470-BDD4F6841A3F@exa-networks.co.uk> <20100830075152.GA19972@diehard.n-r-g.com> <95795D09-D859-4170-A20D-3D67C83CE380@exa-networks.co.uk> <1283159329.30109.2.camel@daniel> Message-ID: > On Mon, 2010-08-30 at 10:58 +0200, Thomas Mangin wrote: >> http://www.faqs.org/rfcs/rfc4271.html section 4.2 >> >> So unless you know something I don't, I believe you are totally mistaken :) > > updates serve as implicit keepalives. Rule #1 do not post when you are not awake yet and quote the text which tells you are wrong .. broken :p Thank you Claudio for showing me why it would not work. Thomas From pierre.francois at uclouvain.be Mon Aug 30 04:21:42 2010 From: pierre.francois at uclouvain.be (Pierre Francois) Date: Mon, 30 Aug 2010 11:21:42 +0200 Subject: Did your BGP crash today? In-Reply-To: <95795D09-D859-4170-A20D-3D67C83CE380@exa-networks.co.uk> References: <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> <20100828155853.GA12190@panix.com> <4EC01755-8572-4AAD-9470-BDD4F6841A3F@exa-networks.co.uk> <20100830075152.GA19972@diehard.n-r-g.com> <95795D09-D859-4170-A20D-3D67C83CE380@exa-networks.co.uk> Message-ID: <4C7B7826.9020203@uclouvain.be> Thomas, Wouldn't the confusion come from the fact that updates are considered as keepalives, so that Claudio sees so few type 4 messages because he receives updates ? Sec 4.2, Hold Time : "The calculated value indicates the maximum number of seconds that may elapse between the receipt of successive KEEPALIVE and/or UPDATE messages from the sender." Regards, Pierre. Thomas Mangin wrote: >> Apart from one big vendor most BGP speaker only send KEEPALIVES when they >> need to. So on my full feeds I see sessions running for more then 1 month >> which received less then 300 KEEPALIVE packets. > > > The negociaged holdtime is always the lower value presented between two routers. The default HoldTime timer for Cisco is 180 seconds and for Juniper 90. > So you should see a KEEPALIVE packet every minute from/to Cisco routers, and one every 30 seconds between Junipers. > > Should a BGP speaker do not see any KEEPALIVE during $HOLDTIME, it will tear the session down. > You are telling me that your effective holdtime is 2592000 seconds when the HOLDTIME field is 16 bits ... hum ... > http://www.faqs.org/rfcs/rfc4271.html section 4.2 > > So unless you know something I don't, I believe you are totally mistaken :) > > Thomas > > > From sthaug at nethelp.no Mon Aug 30 04:22:23 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Mon, 30 Aug 2010 11:22:23 +0200 (CEST) Subject: AT&T routing problems towards www.worldspan.com? Message-ID: <20100830.112223.74701026.sthaug@nethelp.no> We have problems reaching www.worldspan.com (216.113.132.22) from some locations. The common problem seems to be AT&T (AS 7018). Our AS path towards the 216.113.128.0/19 prefix is typically 3356 7018 17228 19631 Anybody else see problems here? I note that I can ping 216.113.132.22 from some locations within our network - but not, for instance, from route-server.ip.att.net. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From bclark at spectraaccess.com Mon Aug 30 04:43:27 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Mon, 30 Aug 2010 05:43:27 -0400 Subject: AT&T routing problems towards www.worldspan.com? In-Reply-To: <20100830.112223.74701026.sthaug@nethelp.no> References: <20100830.112223.74701026.sthaug@nethelp.no> Message-ID: <4C7B7D3F.6020107@spectraaccess.com> That host is not working for us either, but looks more like a host problem rather then BGP problem. I have no problem getting to other IP's in that range like 216.113.132.21 which is probably it's default gateway. On 08/30/2010 05:22 AM, sthaug at nethelp.no wrote: > We have problems reaching www.worldspan.com (216.113.132.22) from > some locations. The common problem seems to be AT&T (AS 7018). Our > AS path towards the 216.113.128.0/19 prefix is typically > > 3356 7018 17228 19631 > > Anybody else see problems here? I note that I can ping 216.113.132.22 > from some locations within our network - but not, for instance, from > route-server.ip.att.net. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > > From Robert.MacDonald at Haworth.com Mon Aug 30 04:51:19 2010 From: Robert.MacDonald at Haworth.com (Robert MacDonald) Date: Mon, 30 Aug 2010 05:51:19 -0400 Subject: AT&T routing problems towards www.worldspan.com? In-Reply-To: <20100830.112223.74701026.sthaug@nethelp.no> References: <20100830.112223.74701026.sthaug@nethelp.no> Message-ID: --- Original Message --- >From: sthaug at nethelp.no >Sent: Monday, August 30, 2010 5:22 AM >To: nanog at nanog.org > >We have problems reaching www.worldspan.com (216.113.132.22) from >some locations. The common problem seems to be AT&T (AS 7018). Our >AS path towards the 216.113.128.0/19 prefix is typically > > 3356 7018 17228 19631 > >Anybody else see problems here? I note that I can ping 216.113.132.22 >from some locations within our network - but not, for instance, from >route-server.ip.att.net. > >Steinar Haug, Nethelp consulting, sthaug at nethelp.no > Not sure if this would be helpful.... Similar from West Michigan-USA. I also have troubles via Qwest (USA) and Qwest (via Colt) in Germany. I too cannot ping that IP from these locations. My guess is a possible node issue, not network. #trace ip 216.113.132.22 Tracing the route to www.worldspan.net (216.113.132.22) 1 12.87.238.5 [AS 7018] 8 msec 4 msec 12 msec 2 cr82.dtrmi.ip.att.net (12.122.102.90) [AS 7018] 44 msec 40 msec 40 msec 11 12-122-254-82.attens.net (12.122.254.82) [AS 7018] 40 msec 40 msec 40 msec 12 mdf001c7613r0004-tge-12-1.atl1.attens.net (12.129.65.142) [AS 17228] 44 msec 44 msec 40 msec 13 12.129.64.122 [AS 17228] 40 msec 40 msec 12.129.64.126 [AS 17228] 40 msec 14 10.5.158.229 40 msec 10.5.158.225 44 msec 44 msec 15 * * * #sh ip bgp 216.113.132.22/19 BGP routing table entry for 216.113.128.0/19, version 54509208 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to update-groups: 1 7018 17228 19631 12.87.238.5 from 12.87.238.5 (12.122.83.244) Origin IGP, localpref 100, valid, external, best >From our German router (just a defgwy towards Qwest...) #trace ip 216.113.132.22 Tracing the route to 216.113.132.22 1 209.181.1.21 12 msec 12 msec 16 msec 2 65.120.25.53 16 msec 12 msec 16 msec 3 205.171.251.110 104 msec 104 msec 108 msec 4 192.205.34.253 108 msec 108 msec 108 msec 5 12.122.134.166 128 msec 124 msec 128 msec 6 12.122.1.173 120 msec 120 msec 120 msec 7 12.123.22.110 124 msec 128 msec 128 msec 8 12.122.141.69 124 msec 124 msec 128 msec 9 12.122.254.82 128 msec 120 msec 132 msec 10 12.129.65.142 124 msec 128 msec 12.129.65.138 120 msec 11 12.129.64.122 124 msec 12.129.64.126 120 msec 120 msec 12 * * * 13 * * * 14 * * * From sthaug at nethelp.no Mon Aug 30 05:05:15 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Mon, 30 Aug 2010 12:05:15 +0200 (CEST) Subject: AT&T routing problems towards www.worldspan.com? In-Reply-To: <4C7B7D3F.6020107@spectraaccess.com> References: <20100830.112223.74701026.sthaug@nethelp.no> <4C7B7D3F.6020107@spectraaccess.com> Message-ID: <20100830.120515.41681039.sthaug@nethelp.no> > That host is not working for us either, but looks more like a host > problem rather then BGP problem. I have no problem getting to other > IP's in that range like 216.113.132.21 which is probably it's default > gateway. I can ping 216.113.132.21 from all the places I have tried too. So I agree with you, a possible host problem. *Or* it could be a problem involving parallell links with src/dst hashing where one of the links is not working properly. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From MAdcock at hisna.com Mon Aug 30 09:28:02 2010 From: MAdcock at hisna.com (Adcock, Matt [HISNA]) Date: Mon, 30 Aug 2010 07:28:02 -0700 Subject: Recycling old cabling? References: <20100817220849.68E39692@resin07.mta.everyone.net><1885992790-1282113493-cardhu_decombobulator_blackberry.rim.net-1687831139-@bda903.bisx.prod.on.blackberry> Message-ID: <6AB0A22CB81B784A8CFF7B9A3AF11A2E420B59@hkeexm03v.hke.local> Assumption: Construction guys are present. 1. Dump cable in large pile on the floor 2. Yell "Does anybody want this copper?" 3. Use broom to fend of multiple takers 4. Tell the guy who wants it that he can have it as long as he hauls it away Not that I've ever done this of course... The information in this email and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information.?If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited.??We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message.?We cannot accept liability for any loss or damage caused by software viruses.?If you believe that you have received this email in error, please contact the sender immediately and delete the email and all of its attachments From: Patrik Wallstrom [mailto:pawal at blipp.com] Sent: Thu 8/19/2010 10:12 AM To: nanog at nanog.org Subject: Re: Recycling old cabling? On Aug 18, 2010, at 8:45 AM, Mikael Abrahamsson wrote: > On Wed, 18 Aug 2010, khatfield at socllc.net wrote: > >> More companies recycle and properly dispose of equipment than they did ten years ago. Yet, if they aren't being looked at to be "green" or something along those lines then many choose the cheapest route (the dumpster). > > The amazing thing is sometimes they will pay to have it trashed instead of the option of a recycler/reseller coming around and picking it up at no cost. > > As you said, it's just one of those things. The cables might still have some ultra-secret bits in them. ? From jbates at brightok.net Mon Aug 30 10:55:03 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 30 Aug 2010 10:55:03 -0500 Subject: Did your BGP crash today? In-Reply-To: <87lj7rrktr.fsf@mid.deneb.enyo.de> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> Message-ID: <4C7BD457.3030307@brightok.net> Florian Weimer wrote: > This whole thread is quite schizophrenic because the consensus appears > to be that (a) a *researcher is not to blame* for sending out a BGP > message which eventually leads to session resets, and (b) an > *implementor is to blame* for sending out a BGP messages which > eventually leads to session resets. You really can't have it both > ways. > As good a place to break in on the thread as any, I guess. Randy and others believe more testing should have been done. I'm not completely sure they didn't test against XR. They very likely could have tested in a 1 on 1 connection and everything looked fine. I don't know the full details, but at what point did the corruption appear, and was it visible? We know that it was corrupt on the output which caused peer resets, but was it necessarily visible in the router itself? Do we require a researcher to setup a chain of every vender BGP speaker in every possible configuration and order to verify a bug doesn't cause things to break? In this case, one very likely would need an XR receiving and transmitting updates to detect the failure, so no less than 3 routers with the XR in the middle. What about individual configurations? Perhaps the update is received and altered by one vendor due to specific configurations, sent to the next vendor, accepted and altered (due to the first alteration, where as it wouldn't be altered if the original update had been received) which causes the next vendor to reset. Then we add to this that it may pass silently through several middle vendor routers without problems and we realize the scope of such problems and why connecting to the Internet is so unpredictable. Jack From lists at netrogenic.com Mon Aug 30 11:14:01 2010 From: lists at netrogenic.com (Jay Ess) Date: Mon, 30 Aug 2010 18:14:01 +0200 Subject: Off-Topic: Seeking sponsor for infrastructure related site. Message-ID: <4C7BD8C9.4040600@netrogenic.com> First of all i want to apologize for the off topic nature of this post. I am seeking sponsorship for one of my hobby project. My needs is one or two dedicated servers on a stable network in USA and or Europe. DNSDigger.com is one of my hobby projects that has outgrown my own means of hosting as i am on 75% sick leave from my ordinary job. DNSDigger is a database of domain and hostnames that is resolved into IP-adresses and can show what domains a IP-adress (or IP-span) has "behind". The data is collected by downloading com/net-zone from Verisign and http spidering. Then "simply" resolving all the hundreds of millions of hostnames and make it search able. This sounds like a bandwidth hog but i actually run all this from a home private cable connection (dont tell anyone ;) and i have had no troubles except for outgrowing my Pentium D "server". If you find this service fun and valuable and have the means of providing an high end dedicated server plus hosting i would love to hear from you. An "powered by "-link/button and information page will be offered. /John Stromstedt (john at netrogenic.com) From kemp at network-services.uoregon.edu Mon Aug 30 11:23:24 2010 From: kemp at network-services.uoregon.edu (John Kemp) Date: Mon, 30 Aug 2010 09:23:24 -0700 Subject: route-views.sydney.routeviews.org Message-ID: <4C7BDAFC.3000404@network-services.uoregon.edu> RouteViews has now established a routing data collector at the EQUINIX exchange in Sydney, Australia. We are now accepting peers. If you would like to participate in the project by contributing your routes, please contact us at: help at routeviews.org. RouteViews currently operates collectors at the University of Oregon, at the Palo Alto IX, at the Equinix IX in Ashburn Virginia, at the LINX in London, at WIDE in Tokyo, and at other locations. We are now ready to serve peers who are reachable at EQIX SYD1. RouteViews collectors are useful as operational looking glasses, as well as a sources of data for network research. RouteViews also participates in the BGPMON project, which provides real-time data feeds in support of the Cyclops free route-monitoring service. In general, we ask for full routes input, and filter to zero output. Our peering details are: AS6447, V4 Address: 202.167.228.100/25, V6 Address: 2001:de8:6::6447:1/64 Additional information is available at http://www.routeviews.org/ John Kemp (kemp at network-services.uoregon.edu) RouteViews Engineer E-MAIL: help at routeviews.org PHONE: 541-346-1714 From oberman at es.net Mon Aug 30 11:40:10 2010 From: oberman at es.net (Kevin Oberman) Date: Mon, 30 Aug 2010 09:40:10 -0700 Subject: Did your BGP crash today? In-Reply-To: Your message of "Mon, 30 Aug 2010 10:55:03 CDT." <4C7BD457.3030307@brightok.net> Message-ID: <20100830164010.431A61CC3A@ptavv.es.net> > Date: Mon, 30 Aug 2010 10:55:03 -0500 > From: Jack Bates > > > Florian Weimer wrote: > > This whole thread is quite schizophrenic because the consensus appears > > to be that (a) a *researcher is not to blame* for sending out a BGP > > message which eventually leads to session resets, and (b) an > > *implementor is to blame* for sending out a BGP messages which > > eventually leads to session resets. You really can't have it both > > ways. > > > > As good a place to break in on the thread as any, I guess. Randy and > others believe more testing should have been done. I'm not completely > sure they didn't test against XR. They very likely could have tested in > a 1 on 1 connection and everything looked fine. > > I don't know the full details, but at what point did the corruption > appear, and was it visible? We know that it was corrupt on the output > which caused peer resets, but was it necessarily visible in the router > itself? > > Do we require a researcher to setup a chain of every vender BGP speaker > in every possible configuration and order to verify a bug doesn't cause > things to break? In this case, one very likely would need an XR > receiving and transmitting updates to detect the failure, so no less > than 3 routers with the XR in the middle. > > What about individual configurations? Perhaps the update is received and > altered by one vendor due to specific configurations, sent to the next > vendor, accepted and altered (due to the first alteration, where as it > wouldn't be altered if the original update had been received) which > causes the next vendor to reset. Then we add to this that it may pass > silently through several middle vendor routers without problems and we > realize the scope of such problems and why connecting to the Internet is > so unpredictable. This only way they could have caught this one was to have tested to a CRS which had another router to which it was announcing the attribute in a mal-formed packet. Worse, the resets should just keep happening as the CRS would still have the route with the unknown attribute which would just generate another malformed update to cause the session to reset again. While it may be possible to recover from something like this, it sure would not be easy. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From mike at sentex.net Mon Aug 30 12:28:26 2010 From: mike at sentex.net (Mike Tancsa) Date: Mon, 30 Aug 2010 13:28:26 -0400 Subject: Did your BGP crash today? In-Reply-To: <20100830164010.431A61CC3A@ptavv.es.net> References: <20100830164010.431A61CC3A@ptavv.es.net> Message-ID: <201008301728.o7UHSTNR091626@lava.sentex.ca> At 12:40 PM 8/30/2010, Kevin Oberman wrote: >This only way they could have caught this one was to have tested to a >CRS which had another router to which it was announcing the attribute in >a mal-formed packet. Worse, the resets should just keep happening as the >CRS would still have the route with the unknown attribute which would >just generate another malformed update to cause the session to reset >again. > >While it may be possible to recover from something like this, it sure >would not be easy. We experienced something like this a year ago on a couple of quagga boxes. At least we had source code to go through and resources to make use of that source code to find the problem and implement a quick work around. Its for situations like this, debugging logging is ooooohhh so important. What did people do in this case to identify the issue ? Did you just pass it off to your vendor ? or did anyone try to diagnose it locally ? If so, what did you do ? ---Mike >-- >R. Kevin Oberman, Network Engineer >Energy Sciences Network (ESnet) >Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) >E-mail: oberman at es.net Phone: +1 510 486-8634 >Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From jason at lixfeld.ca Mon Aug 30 13:27:55 2010 From: jason at lixfeld.ca (Jason Lixfeld) Date: Mon, 30 Aug 2010 14:27:55 -0400 Subject: Life experience: Cisco ASR9000 vs. Juniper MX960 Message-ID: <985A80DE-08C5-44E0-ADCF-519763597D4F@lixfeld.ca> I'm looking for feedback on Cisco's ASR9000 vs. Juniper MX960. We're evaluating the two and are in the process of testing these two platforms and I'd like to try to have a leg up on testing if there are any gotchas that have crept up in the real world. What we're looking for information on are problems that have arisen in these areas: - Interface linerate issues (oversubscription, etc) - Backplane/slot capacity issues (oversubscription, etc) - Supervisor/RE switchover - DC PDUs and power redundancy - BGP4/MP-BGP - IPv6 - L2VPN - L3VPN - VPLS - LDP - RSVP - MPLS-TE - MPLS-FRR - OSPF - ISIS - In the case of Juniper, interoperability with Cisco for MPLS and associated protocols and features. - Anything else you'd like to mention, good or bad. If anyone is interested, I'll compile the results and provide them to whomever. Thanks in advance. From achatz at forthnet.gr Mon Aug 30 14:15:37 2010 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Mon, 30 Aug 2010 22:15:37 +0300 Subject: Life experience: Cisco ASR9000 vs. Juniper MX960 In-Reply-To: <985A80DE-08C5-44E0-ADCF-519763597D4F@lixfeld.ca> References: <985A80DE-08C5-44E0-ADCF-519763597D4F@lixfeld.ca> Message-ID: <4C7C0359.7000500@forthnet.gr> We're planning to do exactly the same, but not in parallel. ASR9k first (in September), MX960 after. I'll be interested in your results (and everyone else), especially in the areas of L2VPN, M(V)PLS, OSPF and everything Carrier Ethernet related. -- Tassos Jason Lixfeld wrote on 30/08/2010 21:27: > I'm looking for feedback on Cisco's ASR9000 vs. Juniper MX960. We're evaluating the two and are in the process of testing these two platforms and I'd like to try to have a leg up on testing if there are any gotchas that have crept up in the real world. > > What we're looking for information on are problems that have arisen in these areas: > > - Interface linerate issues (oversubscription, etc) > - Backplane/slot capacity issues (oversubscription, etc) > - Supervisor/RE switchover > - DC PDUs and power redundancy > - BGP4/MP-BGP > - IPv6 > - L2VPN > - L3VPN > - VPLS > - LDP > - RSVP > - MPLS-TE > - MPLS-FRR > - OSPF > - ISIS > - In the case of Juniper, interoperability with Cisco for MPLS and associated protocols and features. > - Anything else you'd like to mention, good or bad. > > If anyone is interested, I'll compile the results and provide them to whomever. > > Thanks in advance. > > From gary.buhrmaster at gmail.com Mon Aug 30 14:39:16 2010 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Mon, 30 Aug 2010 19:39:16 +0000 Subject: Did your BGP crash today? In-Reply-To: <4C7BD457.3030307@brightok.net> References: <20100827191324.GJ1946@gerbil.cluepon.net> <4C780F54.8070607@unfix.org> <4C781312.3010903@otd.com> <73C4F36B-BD17-4343-B4A5-53169C04647D@gmail.com> <20100828114222.GB30614@diehard.n-r-g.com> <87lj7rrktr.fsf@mid.deneb.enyo.de> <4C7BD457.3030307@brightok.net> Message-ID: On Mon, Aug 30, 2010 at 15:55, Jack Bates wrote: > ... > As good a place to break in on the thread as any, I guess. Randy and others > believe more testing should have been done. I'm not completely sure they > didn't test against XR. They very likely could have tested in a 1 on 1 > connection and everything looked fine. > > I don't know the full details, but at what point did the corruption appear, > and was it visible? We know that it was corrupt on the output which caused > peer resets, but was it necessarily visible in the router itself? > > Do we require a researcher to setup a chain of every vender BGP speaker in > every possible configuration and order to verify a bug doesn't cause things > to break? In this case, one very likely would need an XR receiving and > transmitting updates to detect the failure, so no less than 3 routers with > the XR in the middle. > > What about individual configurations? Perhaps the update is received and > altered by one vendor due to specific configurations, sent to the next > vendor, accepted and altered (due to the first alteration, where as it > wouldn't be altered if the original update had been received) which causes > the next vendor to reset. Then we add to this that it may pass silently > through several middle vendor routers without problems and we realize the > scope of such problems and why connecting to the Internet is so > unpredictable. I am not aware that anyone has provided the complete details at this point which would include any test plans that may have been performed. From what I have been able to discern, it does seem likely that a test plan that would have caught this almost had to know of the specific issue in advance. More testing would have been better, but there is just too much variability out there to assure you can do a complete test. I am also not aware that the introduction of the attribute was announced to the usual operational lists in advance "just in case" (Ok, in this case, I mean NANOG). This, is my mind, is actually the bigger faux pas. An "Oh S***" moment has happened to most of us. It probably will happen again to many of us. But letting people know in advance of scheduled changes is the important thing. I would hope that in the future researchers will commit to test plans to (at least) all the major vendor BGP speakers (which, I admit, would likely not have caught this issue), and that before introducing such "new" attributes into the "Internet", they would announce it to the usual operational lists, again, "just in case". But my hopes are often dashed. Gary From franck at genius.com Mon Aug 30 16:21:58 2010 From: franck at genius.com (Franck Martin) Date: Tue, 31 Aug 2010 09:21:58 +1200 (FJT) Subject: Comcast enables 6to4 relays In-Reply-To: Message-ID: <31216075.0.1283202877790.JavaMail.franck@franck-martins-macbook-pro.local> Is there a list of 6to4 relays? I'm curious. Also, I'm also curious to know if ISPs in Europe (which are more advanced in IPv6 deployment) have experienced the same issues? From franck at genius.com Mon Aug 30 16:47:14 2010 From: franck at genius.com (Franck Martin) Date: Tue, 31 Aug 2010 09:47:14 +1200 (FJT) Subject: Comcast enables 6to4 relays In-Reply-To: <31216075.0.1283202877790.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <33530604.6.1283204829965.JavaMail.franck@franck-martins-macbook-pro.local> found it: http://www.bgpmon.net/6to4.php?week=4 Not what I call a big list, considering... ----- Original Message ----- From: "Franck Martin" To: "John Jason Brzozowski" Cc: "NANOG" Sent: Tuesday, 31 August, 2010 9:21:58 AM Subject: Re: Comcast enables 6to4 relays Is there a list of 6to4 relays? I'm curious. Also, I'm also curious to know if ISPs in Europe (which are more advanced in IPv6 deployment) have experienced the same issues? From jbates at brightok.net Mon Aug 30 16:44:11 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 30 Aug 2010 16:44:11 -0500 Subject: Comcast enables 6to4 relays In-Reply-To: <31216075.0.1283202877790.JavaMail.franck@franck-martins-macbook-pro.local> References: <31216075.0.1283202877790.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4C7C262B.3060406@brightok.net> Franck Martin wrote: > Is there a list of 6to4 relays? > > I'm curious. > > Also, I'm also curious to know if ISPs in Europe (which are more advanced in IPv6 deployment) have experienced the same issues? > > Sprint has one which is absolutely horrible (or was a year or two ago). I'd recommend any and every ISP to setup a 6to4, even if it runs over a v6 tunnel to HE. Accidentally getting one from someone else can give you exceptionally broken 6to4 connectivity. Being anycast, I'd say routeviews might be a good place to check for some, but often times they are hidden within the networks they serve. That being said, 6to4 itself is often horrible. It works fine if you are talking 6to4 direct to the remote site (vs using a relay), but relays often break and are hard to troubleshoot due to their nature. In the last year, my 6to4 tunnel has peaked at 6.44mb/s (1day average) but more common peaks are 150-250kb/s (5min average). My tunnel to he.net was running 4-8 times that including the 6to4 relay serving all my customers + native traffic for 15 hosts and 2 servers. It's hard to get accurate on recent traffic loads as much of my v6 traffic shifted to dual stacked peers and I don't have a method of separating the v4/v6 traffic in the graphs (me thinks it's time to test ipv6 over mpls). Jack From lists at billfehring.com Mon Aug 30 16:57:22 2010 From: lists at billfehring.com (Bill Fehring) Date: Mon, 30 Aug 2010 14:57:22 -0700 Subject: Comcast enables 6to4 relays In-Reply-To: References: Message-ID: On Sat, Aug 28, 2010 at 10:49, John Jason Brzozowski wrote: > > As we started our IPv6 trials, we began to observe an increase in 6to4 relay > traffic. 6to4 is a transition mechanism built into some operating systems > and home gateways. While it is not a transition technology that Comcast > planned to invest in due to limitations related to performance, we did > observe poor performance when 6to4 was used by our customers. In many cases, > these customers were not even aware that 6to4 was enabled by default or that > their device or operating system was attempting to use 6to4 to communicate > with IPv6 resources on the Internet. > > In most cases, we observed that 6to4-enabled operating systems and devices > were attempting to use a 6to4 relay infrastructure hosted by a midwestern > university. In order to improve the Internet experience for Comcast > customers who are using 6to4, whether knowingly or not, we have decided to > operate 6to4 relays on a temporary, trial basis. > > Comcast has decided to deploy 6to4 relays in five locations around our > network to improve performance and predictability, as compared to operating > relays from a single location. These 6to4 relays are available via the > standard 6to4 Anycast IP address, according to RFC 3068, which is > 192.88.99.1. Devices attempting to use 6to4 within our network should > automatically discover and utilize these new 6to4 relays, without end user > intervention or configuration. > > The first pair of these relays was activated today. We plan to activate the > remaining three within the next seven to ten days. We plan to monitor the > performance of the 6to4 relays, to measure any beneficial effects resulting > from adding these elements to our network. As our IPv6 trials evolve and we > develop our plans for 2011 and beyond, we will assess our plans to support > 6to4 moving forward. > Hi John, First of all, that's great news -- I think it will help a lot. Have you also considered deploying Teredo relays? I'm guessing that there are quite a few Windows Vista+ systems that could benefit from having a few closer Teredo relays and it's probably a similar amount of traffic that you're seeing compared to 6to4 tunnels. Best, Bill Fehring From bicknell at ufp.org Mon Aug 30 17:00:27 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 30 Aug 2010 15:00:27 -0700 Subject: Comcast enables 6to4 relays In-Reply-To: <33530604.6.1283204829965.JavaMail.franck@franck-martins-macbook-pro.local> References: <31216075.0.1283202877790.JavaMail.franck@franck-martins-macbook-pro.local> <33530604.6.1283204829965.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <20100830220027.GA33052@ussenterprise.ufp.org> In a message written on Tue, Aug 31, 2010 at 09:47:14AM +1200, Franck Martin wrote: > found it: > > http://www.bgpmon.net/6to4.php?week=4 > > Not what I call a big list, considering... Note that these are people willing to provide a 6to4 relay free to the entire Internet. There are plenty of people who offer 6to4 inside their own network for their own customers, but never advertise the prefix to world+dog. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From john_brzozowski at cable.comcast.com Mon Aug 30 17:09:17 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Mon, 30 Aug 2010 18:09:17 -0400 Subject: Comcast enables 6to4 relays In-Reply-To: <33530604.6.1283204829965.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: The Comcast 6to4 relays are not on this list, perhaps this is a list of open ones? John On 8/30/10 5:47 PM, "Franck Martin" wrote: > found it: > > http://www.bgpmon.net/6to4.php?week=4 > > Not what I call a big list, considering... > > ----- Original Message ----- > From: "Franck Martin" > To: "John Jason Brzozowski" > Cc: "NANOG" > Sent: Tuesday, 31 August, 2010 9:21:58 AM > Subject: Re: Comcast enables 6to4 relays > > Is there a list of 6to4 relays? > > I'm curious. > > Also, I'm also curious to know if ISPs in Europe (which are more advanced in > IPv6 deployment) have experienced the same issues? > > > > ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From franck at genius.com Mon Aug 30 17:13:10 2010 From: franck at genius.com (Franck Martin) Date: Tue, 31 Aug 2010 10:13:10 +1200 (FJT) Subject: Comcast enables 6to4 relays In-Reply-To: <4C7C262B.3060406@brightok.net> Message-ID: <4308552.12.1283206387170.JavaMail.franck@franck-martins-macbook-pro.local> Well I found my 6to4 gateway: traceroute to 192.88.99.1 (192.88.99.1), 30 hops max, 40 byte packets 10 te3-3.ccr01.ind01.atlas.cogentco.com (154.54.3.30) [AS174] 244.965 ms 244.964 ms 244.952 ms 11 38.20.52.226 (38.20.52.226) [AS174] 244.336 ms 38.20.52.222 (38.20.52.222) [AS174] 244.300 ms 266.250 ms 12 38.104.214.6 (38.104.214.6) [AS174] 326.141 ms 326.139 ms 376.926 ms 13 ge-7-0-0.103.rtr.ictc.indiana.gigapop.net (149.165.254.142) [AS10680] 612.357 ms 612.367 ms 612.358 ms 14 rtr3.ul.indiana.gigapop.net (149.165.255.129) [AS10680] 376.777 ms 319.641 ms * and I have so much issues with 6to4 that I have decided to disable it at home (airport extreme). I found out PTB was not transmitted and using scamper and the help of Matthew Luckie there is an odd MTU of 1422 from Internet to me. I suspect the 6to4 relay did not put the MTU to 1280 to be on the safe side... (I saw a recommendation like that on the net). I have seen that the new hardware of the airport extreme has a new firmware that does more IPv6 magic, but old hardware are not yet benefiting this new firmware... Once a new firmware comes I'll re-enable and see... PS: I found scamper to be a very good troubleshooting tool (once you know what to do) and wish it would be on all OS, like traceroute and now tracepath is... ----- Original Message ----- From: "Jack Bates" To: "Franck Martin" Cc: "John Jason Brzozowski" , "NANOG" Sent: Tuesday, 31 August, 2010 9:44:11 AM Subject: Re: Comcast enables 6to4 relays Franck Martin wrote: > Is there a list of 6to4 relays? > > I'm curious. > > Also, I'm also curious to know if ISPs in Europe (which are more advanced in IPv6 deployment) have experienced the same issues? > > Sprint has one which is absolutely horrible (or was a year or two ago). I'd recommend any and every ISP to setup a 6to4, even if it runs over a v6 tunnel to HE. Accidentally getting one from someone else can give you exceptionally broken 6to4 connectivity. Being anycast, I'd say routeviews might be a good place to check for some, but often times they are hidden within the networks they serve. That being said, 6to4 itself is often horrible. It works fine if you are talking 6to4 direct to the remote site (vs using a relay), but relays often break and are hard to troubleshoot due to their nature. From franck at genius.com Mon Aug 30 17:16:33 2010 From: franck at genius.com (Franck Martin) Date: Tue, 31 Aug 2010 10:16:33 +1200 (FJT) Subject: Comcast enables 6to4 relays In-Reply-To: Message-ID: <2342928.16.1283206591420.JavaMail.franck@franck-martins-macbook-pro.local> Yes this is the list of visible relays as seen from the BGP backbone monitoring... If you don't offer your relays to the rest of the world, they won't show up there... ----- Original Message ----- From: "John Jason Brzozowski" To: "Franck Martin" Cc: "NANOG" Sent: Tuesday, 31 August, 2010 10:09:17 AM Subject: Re: Comcast enables 6to4 relays The Comcast 6to4 relays are not on this list, perhaps this is a list of open ones? John On 8/30/10 5:47 PM, "Franck Martin" wrote: > found it: > > http://www.bgpmon.net/6to4.php?week=4 > > Not what I call a big list, considering... > > ----- Original Message ----- > From: "Franck Martin" > To: "John Jason Brzozowski" > Cc: "NANOG" > Sent: Tuesday, 31 August, 2010 9:21:58 AM > Subject: Re: Comcast enables 6to4 relays > > Is there a list of 6to4 relays? > > I'm curious. > > Also, I'm also curious to know if ISPs in Europe (which are more advanced in > IPv6 deployment) have experienced the same issues? > > > > ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From john_brzozowski at cable.comcast.com Mon Aug 30 17:17:38 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Mon, 30 Aug 2010 18:17:38 -0400 Subject: Comcast enables 6to4 relays In-Reply-To: <4C7C262B.3060406@brightok.net> Message-ID: I actually agree with the below. Using whatever you learn "today" via BGP does not appear to be a good plan. 6to4 in particular becomes very unpredictable and does in fact contribute to brokenness. I am not saying deploying your own will make 6to4 good or great, it will however, help to make it less broken and more controllable. If operators deployed their own it would likely be beneficial to their subscribers, particularly if there is a lot of 6to4. I would also go out on a limb and say that absent and poorly deployed 6to4 relays collectively play hugely into the perception of brokenness. There was a noticeable difference deploying our own 6to4 relays compared to using the next or first available. I am not saying the other relay was poorly run, just saying it is different having one on-net versus off-net. John On 8/30/10 5:44 PM, "Jack Bates" wrote: > > Franck Martin wrote: >> Is there a list of 6to4 relays? >> >> I'm curious. >> >> Also, I'm also curious to know if ISPs in Europe (which are more advanced in >> IPv6 deployment) have experienced the same issues? >> >> > > Sprint has one which is absolutely horrible (or was a year or two ago). > I'd recommend any and every ISP to setup a 6to4, even if it runs over a > v6 tunnel to HE. Accidentally getting one from someone else can give you > exceptionally broken 6to4 connectivity. Being anycast, I'd say > routeviews might be a good place to check for some, but often times they > are hidden within the networks they serve. > > That being said, 6to4 itself is often horrible. It works fine if you are > talking 6to4 direct to the remote site (vs using a relay), but relays > often break and are hard to troubleshoot due to their nature. > > In the last year, my 6to4 tunnel has peaked at 6.44mb/s (1day average) > but more common peaks are 150-250kb/s (5min average). > > My tunnel to he.net was running 4-8 times that including the 6to4 relay > serving all my customers + native traffic for 15 hosts and 2 servers. > It's hard to get accurate on recent traffic loads as much of my v6 > traffic shifted to dual stacked peers and I don't have a method of > separating the v4/v6 traffic in the graphs (me thinks it's time to test > ipv6 over mpls). > > > Jack ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From john_brzozowski at cable.comcast.com Mon Aug 30 17:18:27 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Mon, 30 Aug 2010 18:18:27 -0400 Subject: Comcast enables 6to4 relays In-Reply-To: Message-ID: Hey Bill, No plans for Teredo at this time. John On 8/30/10 5:57 PM, "Bill Fehring" wrote: > On Sat, Aug 28, 2010 at 10:49, John Jason Brzozowski > wrote: > >> >> As we started our IPv6 trials, we began to observe an increase in 6to4 relay >> traffic. 6to4 is a transition mechanism built into some operating systems >> and home gateways. While it is not a transition technology that Comcast >> planned to invest in due to limitations related to performance, we did >> observe poor performance when 6to4 was used by our customers. In many cases, >> these customers were not even aware that 6to4 was enabled by default or that >> their device or operating system was attempting to use 6to4 to communicate >> with IPv6 resources on the Internet. >> >> In most cases, we observed that 6to4-enabled operating systems and devices >> were attempting to use a 6to4 relay infrastructure hosted by a midwestern >> university. In order to improve the Internet experience for Comcast >> customers who are using 6to4, whether knowingly or not, we have decided to >> operate 6to4 relays on a temporary, trial basis. >> >> Comcast has decided to deploy 6to4 relays in five locations around our >> network to improve performance and predictability, as compared to operating >> relays from a single location. These 6to4 relays are available via the >> standard 6to4 Anycast IP address, according to RFC 3068, which is >> 192.88.99.1. Devices attempting to use 6to4 within our network should >> automatically discover and utilize these new 6to4 relays, without end user >> intervention or configuration. >> >> The first pair of these relays was activated today. We plan to activate the >> remaining three within the next seven to ten days. We plan to monitor the >> performance of the 6to4 relays, to measure any beneficial effects resulting >> from adding these elements to our network. As our IPv6 trials evolve and we >> develop our plans for 2011 and beyond, we will assess our plans to support >> 6to4 moving forward. >> > > > Hi John, > > First of all, that's great news -- I think it will help a lot. > > Have you also considered deploying Teredo relays? I'm guessing that > there are quite a few Windows Vista+ systems that could benefit from > having a few closer Teredo relays and it's probably a similar amount > of traffic that you're seeing compared to 6to4 tunnels. > > Best, > > Bill Fehring ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From jbates at brightok.net Mon Aug 30 17:14:39 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 30 Aug 2010 17:14:39 -0500 Subject: Comcast enables 6to4 relays In-Reply-To: <4308552.12.1283206387170.JavaMail.franck@franck-martins-macbook-pro.local> References: <4308552.12.1283206387170.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4C7C2D4F.40109@brightok.net> Franck Martin wrote: > Well I found my 6to4 gateway: > and I have so much issues with 6to4 that I have decided to disable it at home (airport extreme). I found out PTB was not transmitted and using scamper and the help of Matthew Luckie there is an odd MTU of 1422 from Internet to me. I suspect the 6to4 relay did not put the MTU to 1280 to be on the safe side... (I saw a recommendation like that on the net). > Actually, their MTU won't matter. 6to4 is EXTREMELY asymmetric when using relays. The return traffic to you will be via the first router than can support 6to4, not the relay you sent packets to. This is why troubleshooting 6to4 is such a PITA. If your airport supports static tunnels, set one up at tunnel brokers and be done with it. Jack From franck at genius.com Mon Aug 30 17:33:03 2010 From: franck at genius.com (Franck Martin) Date: Tue, 31 Aug 2010 10:33:03 +1200 (FJT) Subject: Comcast enables 6to4 relays In-Reply-To: <4C7C2D4F.40109@brightok.net> Message-ID: <326810.28.1283207579061.JavaMail.franck@franck-martins-macbook-pro.local> if only I had a static IPv4 address, but who gives such luxury for free nowadays to a end user? I'm in an end user configuration here The office configuration is working perfectly fine. I'm talking about my experience as a "end user" just enabling IPv6 on my airport extreme and trying to figure out what is happening.... On my return path I got: traceroute from 2001:470:1:74::3 to 2002:7114:4a9d:0:xxxxxxxx 1 2001:470:1:74::1 5.582 ms [mtu: 1500] 2 2001:470:0:2d::2 0.483 ms [mtu: 1500] 3 2001:470:0:30::2 173.747 ms [mtu: 1500] 4 2001:470:0:13b::2 0.848 ms [mtu: 1500] 5 2002:7114:4a9d::1 274.299 ms [mtu: 1480] 6 2002:7114:4a9d:0:xxxxxxxx 299.939 ms [*mtu: 1422] So I suspect on return path I use a HE.Net relay? And yes I agree it is such a PITA to troubleshoot, I cannot pinpoint the issue. Nor I cannot see if I'm the only one with this kind of troubles, I suspect most just give up immediately... ----- Original Message ----- From: "Jack Bates" To: "Franck Martin" Cc: "John Jason Brzozowski" , "NANOG" Sent: Tuesday, 31 August, 2010 10:14:39 AM Subject: Re: Comcast enables 6to4 relays Franck Martin wrote: > Well I found my 6to4 gateway: > and I have so much issues with 6to4 that I have decided to disable it at home (airport extreme). I found out PTB was not transmitted and using scamper and the help of Matthew Luckie there is an odd MTU of 1422 from Internet to me. I suspect the 6to4 relay did not put the MTU to 1280 to be on the safe side... (I saw a recommendation like that on the net). > Actually, their MTU won't matter. 6to4 is EXTREMELY asymmetric when using relays. The return traffic to you will be via the first router than can support 6to4, not the relay you sent packets to. This is why troubleshooting 6to4 is such a PITA. If your airport supports static tunnels, set one up at tunnel brokers and be done with it. Jack From jbates at brightok.net Mon Aug 30 17:34:31 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 30 Aug 2010 17:34:31 -0500 Subject: Comcast enables 6to4 relays In-Reply-To: References: Message-ID: <4C7C31F7.9000503@brightok.net> John Jason Brzozowski wrote: > Hey Bill, > > No plans for Teredo at this time. > I'm sure, like us, you looked at what was involved and said, "eh, easier to just provide native v6 than deal with that mess." 6to4 is definitely a more friendly protocol for the network engineer. Jack From jbates at brightok.net Mon Aug 30 17:45:28 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 30 Aug 2010 17:45:28 -0500 Subject: Comcast enables 6to4 relays In-Reply-To: <326810.28.1283207579061.JavaMail.franck@franck-martins-macbook-pro.local> References: <326810.28.1283207579061.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4C7C3488.1030202@brightok.net> Others may correct me, but... Franck Martin wrote: > 5 2002:7114:4a9d::1 274.299 ms [mtu: 1480] > 6 2002:7114:4a9d:0:xxxxxxxx 299.939 ms [*mtu: 1422] > > So I suspect on return path I use a HE.Net relay? > Yes, and it appears that your host is replying back to the office. > And yes I agree it is such a PITA to troubleshoot, I cannot pinpoint the issue. Nor I cannot see if I'm the only one with this kind of troubles, I suspect most just give up immediately... > Given that you seem to complete the trace one direction, but not the other, I can think of 2 things, 1) Your originating host may be breaking PMTU (so the packet you send is too large and doesn't make it, you never resend a smaller packet, but it works when tracerouting from the other side due to PMTU working in that direction and you are responding with the same size packet). 2) If hosts in the middle on your traceroute to the destination don't have access to 6to4 relay, they won't be able to reply back to you, so you may end up with timeout hops before getting to the endpoint. Jack From cb.list6 at gmail.com Mon Aug 30 17:54:57 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Mon, 30 Aug 2010 15:54:57 -0700 Subject: Comcast enables 6to4 relays In-Reply-To: <4C7C31F7.9000503@brightok.net> References: <4C7C31F7.9000503@brightok.net> Message-ID: On Mon, Aug 30, 2010 at 3:34 PM, Jack Bates wrote: > John Jason Brzozowski wrote: >> >> Hey Bill, >> >> No plans for Teredo at this time. >> > > I'm sure, like us, you looked at what was involved and said, "eh, easier to > just provide native v6 than deal with that mess." 6to4 is definitely a more > friendly protocol for the network engineer. 100% agree about deploying native IPv6 being better than any "transition mechanism". Time spent deploying IPv6 native is time well spent with real long term payback (ROI ...). Any significant amount of time spent on any transition mechanism that is not strategic to your business, especially unmanaged off-network tunnels, will be painful. Better to work on the piloting a long term solution that will scale and fits the long term reality of living in a IPv4-only + IPv6-only + dual-stack internet. Although i think 6to4 has hurt IPv6 adoption more than help it, i believe comcast is doing the right thing given the fact that many people are running 6to4 and don't even know it.... and without on-net relays, the experience leaves a lot to be desired.. Regards, Cameron ======== http://groups.google.com/group/tmoipv6beta ======== From graham at apolix.co.za Tue Aug 31 00:04:13 2010 From: graham at apolix.co.za (Graham Beneke) Date: Tue, 31 Aug 2010 07:04:13 +0200 Subject: Comcast enables 6to4 relays In-Reply-To: <33530604.6.1283204829965.JavaMail.franck@franck-martins-macbook-pro.local> References: <33530604.6.1283204829965.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4C7C8D4D.5090107@apolix.co.za> On 30/08/2010 23:47, Franck Martin wrote: > found it: > > http://www.bgpmon.net/6to4.php?week=4 > > Not what I call a big list, considering... The list seems to be showing relays that announce both the IPv4 and the IPv6 anycast prefixes. I have noticed a number of deployments that announce the (in)famous IPv4 prefix and then consider their deployment complete. I suspect that there is a lack of 2002::/16 announcements and this would be contributing to the regular problems with return paths. Obviously the IPv6 content networks benefit the most from having a relay translating back to IPv4. Anyone have experience with this? -- Graham Beneke From swmike at swm.pp.se Tue Aug 31 00:14:29 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 31 Aug 2010 07:14:29 +0200 (CEST) Subject: Comcast enables 6to4 relays In-Reply-To: <4C7C31F7.9000503@brightok.net> References: <4C7C31F7.9000503@brightok.net> Message-ID: On Mon, 30 Aug 2010, Jack Bates wrote: > I'm sure, like us, you looked at what was involved and said, "eh, easier > to just provide native v6 than deal with that mess." 6to4 is definitely > a more friendly protocol for the network engineer. End users are using 6to4 and Teredo, if an ISP isn't providing their own relays, someone else is and the performance might be good or bad. Same logic applies to Teredo as to 6to4 and why if you're an ISP who cares, you should run your own. Your customers are using both, whether they know it or not. -- Mikael Abrahamsson email: swmike at swm.pp.se From wardenm at wardenm.net Tue Aug 31 01:22:03 2010 From: wardenm at wardenm.net (Mitchell Warden) Date: Tue, 31 Aug 2010 16:22:03 +1000 Subject: Comcast enables 6to4 relays In-Reply-To: 4C7C8D4D.5090107@apolix.co.za Message-ID: <20100831062203.be89ed60@mail.wardenm.net> > The list seems to be showing relays that announce both the IPv4 and the > IPv6 anycast prefixes. > > I have noticed a number of deployments that announce the (in)famous IPv4 > prefix and then consider their deployment complete. I suspect that there > is a lack of 2002::/16 announcements and this would be contributing to > the regular problems with return paths. > > Obviously the IPv6 content networks benefit the most from having a relay > translating back to IPv4. > > Anyone have experience with this? > > -- > Graham Beneke > > Is there a reason not to advertise more specific prefixes from 2002::/16 to ensure that traffic for your v4 routes comes back to your own 6to4 router? If for example all my users have v4 addresses in 192.0.2.0/24, I could advertise 2002:C002:0000::/40 instead of or in addition to the full 2002::/16. Cheers. Mitchell From jeroen at unfix.org Tue Aug 31 01:46:52 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 31 Aug 2010 08:46:52 +0200 Subject: Comcast enables 6to4 relays In-Reply-To: <20100831062203.be89ed60@mail.wardenm.net> References: <20100831062203.be89ed60@mail.wardenm.net> Message-ID: <4C7CA55C.5020902@unfix.org> On 2010-08-31 08:22, Mitchell Warden wrote: [..] > Is there a reason not to advertise more specific prefixes from 2002::/16 to ensure that traffic for your v4 routes comes back to your own 6to4 router? > > If for example all my users have v4 addresses in 192.0.2.0/24, I could advertise 2002:C002:0000::/40 instead of or in addition to the full 2002::/16. The RFC forbids that with a good reason, as then we'll end up importing the IPv4 BGP table into IPv6... not something we want to see (unless one loves to import 300k routes in there, I guess people will really start whining about that though ;). Greets, Jeroen From john_brzozowski at cable.comcast.com Tue Aug 31 01:18:21 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Tue, 31 Aug 2010 02:18:21 -0400 Subject: UPDATED - Comcast enables 6to4 relays In-Reply-To: Message-ID: Enabled two more 6to4 relays this morning. :) John On 8/31/10 1:14 AM, "Mikael Abrahamsson" wrote: > On Mon, 30 Aug 2010, Jack Bates wrote: > >> I'm sure, like us, you looked at what was involved and said, "eh, easier >> to just provide native v6 than deal with that mess." 6to4 is definitely >> a more friendly protocol for the network engineer. > > End users are using 6to4 and Teredo, if an ISP isn't providing their own > relays, someone else is and the performance might be good or bad. > > Same logic applies to Teredo as to 6to4 and why if you're an ISP who > cares, you should run your own. Your customers are using both, whether > they know it or not. ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From franck at genius.com Tue Aug 31 02:20:09 2010 From: franck at genius.com (Franck Martin) Date: Tue, 31 Aug 2010 19:20:09 +1200 (FJT) Subject: Comcast enables 6to4 relays In-Reply-To: <4C7CA55C.5020902@unfix.org> Message-ID: <5986541.52.1283239205154.JavaMail.franck@franck-martins-macbook-pro.local> I think this http://www.gossamer-threads.com/lists/nsp/ipv6/13537 may answer some of the questions on how to make it work correctly. I like the fact the 6to4 gateway should be on a separate machine that BGP with the main router. If the gateway dies, the routes are withdrawn and clients go and look for another gateway somewhere else.... ----- Original Message ----- From: "Jeroen Massar" To: "Mitchell Warden" Cc: nanog at nanog.org Sent: Tuesday, 31 August, 2010 6:46:52 PM Subject: Re: Comcast enables 6to4 relays On 2010-08-31 08:22, Mitchell Warden wrote: [..] > Is there a reason not to advertise more specific prefixes from 2002::/16 to ensure that traffic for your v4 routes comes back to your own 6to4 router? > > If for example all my users have v4 addresses in 192.0.2.0/24, I could advertise 2002:C002:0000::/40 instead of or in addition to the full 2002::/16. The RFC forbids that with a good reason, as then we'll end up importing the IPv4 BGP table into IPv6... not something we want to see (unless one loves to import 300k routes in there, I guess people will really start whining about that though ;). Greets, Jeroen From franck at genius.com Tue Aug 31 02:21:00 2010 From: franck at genius.com (Franck Martin) Date: Tue, 31 Aug 2010 19:21:00 +1200 (FJT) Subject: UPDATED - Comcast enables 6to4 relays In-Reply-To: Message-ID: <32362307.56.1283239259550.JavaMail.franck@franck-martins-macbook-pro.local> Way to go! more! more! ;) ----- Original Message ----- From: "John Jason Brzozowski" To: "NANOG" Sent: Tuesday, 31 August, 2010 6:18:21 PM Subject: UPDATED - Comcast enables 6to4 relays Enabled two more 6to4 relays this morning. :) John From pekkas at netcore.fi Tue Aug 31 06:36:12 2010 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 31 Aug 2010 14:36:12 +0300 (EEST) Subject: UPDATED - Comcast enables 6to4 relays In-Reply-To: References: Message-ID: On Tue, 31 Aug 2010, John Jason Brzozowski wrote: > Enabled two more 6to4 relays this morning. :) Out of curiousity, what is the aggregate Mbps load on the relays? Related question is the platform on which these are run. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From john_brzozowski at cable.comcast.com Tue Aug 31 07:57:37 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Tue, 31 Aug 2010 08:57:37 -0400 Subject: UPDATED - Comcast enables 6to4 relays In-Reply-To: Message-ID: On 8/31/10 7:36 AM, "Pekka Savola" wrote: > On Tue, 31 Aug 2010, John Jason Brzozowski wrote: >> Enabled two more 6to4 relays this morning. :) > > Out of curiousity, what is the aggregate Mbps load on the relays? > Related question is the platform on which these are run. [jjmb] for now I can say the traffic doubled after the first pair of relays were deployed. They are Linux based. ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From andrei at ripe.net Tue Aug 31 07:58:13 2010 From: andrei at ripe.net (Andrei Robachevsky) Date: Tue, 31 Aug 2010 14:58:13 +0200 Subject: RIPE Labs article on the Duke/RIPE NCC BGP experiment Message-ID: <128F4B5F-DCED-47C1-AFC8-0AFD45C42A8B@ripe.net> Dear Colleagues, On Friday, 27 August, at 08:41 (UTC), RIPE NCC staff involved in the Routing Information Service (RIS) project conducted an Internet routing experiment in conjunction with a research group from Duke University in the United States. The goal of this experiment was to further global understanding of Internet routing behaviour, specifically the use of optional attributes in Border Gateway Protocol (BGP). The experiment ended as scheduled at 09:08 (UTC). Shortly after this, we discovered that the experiment had caused an unexpected and unintended negative impact on Internet operations, lasting for approximately 30 minutes. An article has now been published that provides more information on the experiment and its effect on the network: https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment/ If you have any questions or comments regarding this incident, please contact . Regards, Andrei Robachevsky Chief Technical Officer, RIPE NCC From jbates at brightok.net Tue Aug 31 08:09:06 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 31 Aug 2010 08:09:06 -0500 Subject: Comcast enables 6to4 relays In-Reply-To: References: <4C7C31F7.9000503@brightok.net> Message-ID: <4C7CFEF2.2000505@brightok.net> Mikael Abrahamsson wrote: > End users are using 6to4 and Teredo, if an ISP isn't providing their own > relays, someone else is and the performance might be good or bad. > Teredo usage isn't common enough on our network to warrant the work. Very few apps will activate it is my guess. > Same logic applies to Teredo as to 6to4 and why if you're an ISP who > cares, you should run your own. Your customers are using both, whether > they know it or not. > A customer is more likely (not always) to know when teredo has been activated. I've considered putting it in, but it is not friendly in many ways. 6to4 is usually running on routers in various pops. Teredo, I'd have to back feed to a server farm. This doesn't make for ideal traffic patterns even with bandwidth being so low. Then there is the "customer is unaware" fact. If the customer is unaware that their NAT is being pierced for IPv6 communication, then we have contributed to decreasing their security. For this reason, it might not be completely unwarranted for an ISP to block teredo all together. 6to4 doesn't suffer from this as there is no NAT traversal. Jack From andrei at ripe.net Tue Aug 31 07:58:13 2010 From: andrei at ripe.net (Andrei Robachevsky) Date: Tue, 31 Aug 2010 14:58:13 +0200 Subject: [members-discuss] [ncc-announce] RIPE Labs article on the Duke/RIPE NCC BGP experiment Message-ID: <128F4B5F-DCED-47C1-AFC8-0AFD45C42A8B@ripe.net> Dear Colleagues, On Friday, 27 August, at 08:41 (UTC), RIPE NCC staff involved in the Routing Information Service (RIS) project conducted an Internet routing experiment in conjunction with a research group from Duke University in the United States. The goal of this experiment was to further global understanding of Internet routing behaviour, specifically the use of optional attributes in Border Gateway Protocol (BGP). The experiment ended as scheduled at 09:08 (UTC). Shortly after this, we discovered that the experiment had caused an unexpected and unintended negative impact on Internet operations, lasting for approximately 30 minutes. An article has now been published that provides more information on the experiment and its effect on the network: https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment/ If you have any questions or comments regarding this incident, please contact . Regards, Andrei Robachevsky Chief Technical Officer, 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. From swmike at swm.pp.se Tue Aug 31 09:54:08 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 31 Aug 2010 16:54:08 +0200 (CEST) Subject: Comcast enables 6to4 relays In-Reply-To: <4C7CFEF2.2000505@brightok.net> References: <4C7C31F7.9000503@brightok.net> <4C7CFEF2.2000505@brightok.net> Message-ID: On Tue, 31 Aug 2010, Jack Bates wrote: > Teredo usage isn't common enough on our network to warrant the work. > Very few apps will activate it is my guess. As I stated, either your users are using your Teredo server, or they're using someone elses. Not running one yourself doesn't mean your users aren't running Teredo. > A customer is more likely (not always) to know when teredo has been > activated. I've considered putting it in, but it is not friendly in many > ways. 6to4 is usually running on routers in various pops. Teredo, I'd > have to back feed to a server farm. This doesn't make for ideal traffic > patterns even with bandwidth being so low. Then the traffic is going to someone elses, how is that more optimal? > Then there is the "customer is unaware" fact. If the customer is unaware > that their NAT is being pierced for IPv6 communication, then we have > contributed to decreasing their security. For this reason, it might not > be completely unwarranted for an ISP to block teredo all together. 6to4 > doesn't suffer from this as there is no NAT traversal. Blocking Teredo completely is a whole other discussion. Also, some NAT gateways will support a single device behind it doing Proto 41, so saying 6to4 has no NAT traversal and thus won't work beind NAT isn't true in all cases. -- Mikael Abrahamsson email: swmike at swm.pp.se From jeroen at unfix.org Tue Aug 31 10:11:55 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 31 Aug 2010 17:11:55 +0200 Subject: Comcast enables 6to4 relays In-Reply-To: References: <4C7C31F7.9000503@brightok.net> <4C7CFEF2.2000505@brightok.net> Message-ID: <4C7D1BBB.2060502@unfix.org> On 2010-08-31 16:54, Mikael Abrahamsson wrote: > On Tue, 31 Aug 2010, Jack Bates wrote: > >> Teredo usage isn't common enough on our network to warrant the work. >> Very few apps will activate it is my guess. > > > > As I stated, either your users are using your Teredo server, or they're > using someone elses. Not running one yourself doesn't mean your users > aren't running Teredo. psssst it's relay not server :) I guess everybody mixes that up one day or another, it is also a reason why just having Microsoft's default server is not a huge issue. [..] >> Then there is the "customer is unaware" fact. If the customer is >> unaware that their NAT is being pierced for IPv6 communication, then >> we have contributed to decreasing their security. For this reason, it >> might not be completely unwarranted for an ISP to block teredo all >> together. 6to4 doesn't suffer from this as there is no NAT traversal. Jack: there are a lot more methods to infect a host than this as there are lots and lots of p2p protocols which are being used by C&C botnets. And never forgot about this very simple protocol called HTTP(S). > Blocking Teredo completely is a whole other discussion. > > Also, some NAT gateways will support a single device behind it doing > Proto 41, so saying 6to4 has no NAT traversal and thus won't work beind > NAT isn't true in all cases. Flaky but it works. Generally they just tag 'oh protocol 41 has to go to host X' thus when you enable a second all traffic either moves there or sticks at the first. It's the reason Teredo/AYIYA/etc exist ;) Greets, Jeroen From jbates at brightok.net Tue Aug 31 11:07:34 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 31 Aug 2010 11:07:34 -0500 Subject: Comcast enables 6to4 relays In-Reply-To: <4C7D1BBB.2060502@unfix.org> References: <4C7C31F7.9000503@brightok.net> <4C7CFEF2.2000505@brightok.net> <4C7D1BBB.2060502@unfix.org> Message-ID: <4C7D28C6.1020004@brightok.net> Jeroen Massar wrote: > > Jack: there are a lot more methods to infect a host than this as there > are lots and lots of p2p protocols which are being used by C&C botnets. > And never forgot about this very simple protocol called HTTP(S). > I agree, though let's consider HTTP. If a firewall is set to filter it, yet you are tunneling through with IPv6, you've bypassed your HTTP filters which may, among other things, provide AV protection. I recognize that there are plenty of ways to infect a machine. My concern is that teredo can bypass firewall security and relies upon host security to protect the computer. Unfortunately, not everyone utilizes host security and has dependence on network firewalls. Jack From jeroen at unfix.org Tue Aug 31 11:31:01 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 31 Aug 2010 18:31:01 +0200 Subject: Comcast enables 6to4 relays In-Reply-To: <4C7D28C6.1020004@brightok.net> References: <4C7C31F7.9000503@brightok.net> <4C7CFEF2.2000505@brightok.net> <4C7D1BBB.2060502@unfix.org> <4C7D28C6.1020004@brightok.net> Message-ID: <4C7D2E45.7020704@unfix.org> On 2010-08-31 18:07, Jack Bates wrote: > Jeroen Massar wrote: >> >> Jack: there are a lot more methods to infect a host than this as there >> are lots and lots of p2p protocols which are being used by C&C botnets. >> And never forgot about this very simple protocol called HTTP(S). >> > > I agree, though let's consider HTTP. If a firewall is set to filter it, > yet you are tunneling through with IPv6, you've bypassed your HTTP > filters which may, among other things, provide AV protection. I > recognize that there are plenty of ways to infect a machine. My concern > is that teredo can bypass firewall security and relies upon host > security to protect the computer. Unfortunately, not everyone utilizes > host security and has dependence on network firewalls. If you have a "firewall" which only blocks things it knows you don't have a proper firewall. The only 'firewall' that makes sense anyway is the one which is unplugged. There is always a way out of the network as long as you can have a controlled box on the outside that you can send packets to and from. Network firewalls are great for 'centralized' mitigation and trying to at least cut out most of the wrong stuff you don't want to see as an administrator, but if you are truly serious about it then you should be deploying monitoring on the hosts that are attached to your network too, just remember that a lot of people have VPN software, connect from home to that VPN and do other weird setups (Skype for instance, BitTorrent) where there are possibilities to bypass your "firewall". And indeed, there is no proper solution for that unless you create a walled garden and allow people to only connect to known services and only allow them to send minimal messages, no flash, no other cruft like images. Steganography is also so much fun, Too many ways, even per default and also if someone really wants. Only thing you can do is keep your eyes wide open and of course define what you are really trying to protect against, as one can just as well just use sneakernet to move data around. Greets, Jeroen From Skywing at valhallalegends.com Tue Aug 31 11:51:22 2010 From: Skywing at valhallalegends.com (Skywing) Date: Tue, 31 Aug 2010 11:51:22 -0500 Subject: UPDATED - Comcast enables 6to4 relays Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D601CDDEB5EABE@caralain.haven.nynaeve.net> - S -----Original Message----- From: John Jason Brzozowski Sent: Tuesday, August 31, 2010 5:57 To: Pekka Savola Cc: NANOG Subject: Re: UPDATED - Comcast enables 6to4 relays On 8/31/10 7:36 AM, "Pekka Savola" wrote: > On Tue, 31 Aug 2010, John Jason Brzozowski wrote: >> Enabled two more 6to4 relays this morning. :) > > Out of curiousity, what is the aggregate Mbps load on the relays? > Related question is the platform on which these are run. [jjmb] for now I can say the traffic doubled after the first pair of relays were deployed. They are Linux based. ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From jbates at brightok.net Tue Aug 31 12:02:56 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 31 Aug 2010 12:02:56 -0500 Subject: Comcast enables 6to4 relays In-Reply-To: <4C7D2E45.7020704@unfix.org> References: <4C7C31F7.9000503@brightok.net> <4C7CFEF2.2000505@brightok.net> <4C7D1BBB.2060502@unfix.org> <4C7D28C6.1020004@brightok.net> <4C7D2E45.7020704@unfix.org> Message-ID: <4C7D35C0.6040106@brightok.net> Jeroen Massar wrote: > just remember that a lot of people have VPN software, connect from home > to that VPN and do other weird setups (Skype for instance, BitTorrent) > where there are possibilities to bypass your "firewall". > I agree. My concern here is that we are dealing with improper firewalls. We are dealing with ignorance, and we have M$ enabling teredo by default (though not active until they install the appropriate app). Creating what is essentially a public vpn through a firewall without the user being aware of it is insecure. For all the wonderful popups that vista+ gives, it amazes me that teredo isn't one of them. 6to4 doesn't suffer the same issues. Primarily because RFC1918 addressing can't be used in 6to4. This means that at a minimum, the router has to participate or the host behind it must be manually configured with a 6to4 address (for the proto 41 pass through to work). Neither is an automatic traversal of the router's policies without user knowledge. Jack From Valdis.Kletnieks at vt.edu Tue Aug 31 12:12:45 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 31 Aug 2010 13:12:45 -0400 Subject: Comcast enables 6to4 relays In-Reply-To: Your message of "Tue, 31 Aug 2010 12:02:56 CDT." <4C7D35C0.6040106@brightok.net> References: <4C7C31F7.9000503@brightok.net> <4C7CFEF2.2000505@brightok.net> <4C7D1BBB.2060502@unfix.org> <4C7D28C6.1020004@brightok.net> <4C7D2E45.7020704@unfix.org> <4C7D35C0.6040106@brightok.net> Message-ID: <5224.1283274765@localhost> On Tue, 31 Aug 2010 12:02:56 CDT, Jack Bates said: > 6to4 doesn't suffer the same issues. Primarily because RFC1918 > addressing can't be used in 6to4. This means that at a minimum, the > router has to participate or the host behind it must be manually > configured with a 6to4 address (for the proto 41 pass through to work). > Neither is an automatic traversal of the router's policies without user > knowledge. I'm sure that somewhere, somebody has managed to configure their gear such that one of those two things can happen without user knowledge. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jeroen at unfix.org Tue Aug 31 12:23:37 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 31 Aug 2010 19:23:37 +0200 Subject: Teredo and 'firewalls' (Re: Comcast enables 6to4 relays) In-Reply-To: <4C7D35C0.6040106@brightok.net> References: <4C7C31F7.9000503@brightok.net> <4C7CFEF2.2000505@brightok.net> <4C7D1BBB.2060502@unfix.org> <4C7D28C6.1020004@brightok.net> <4C7D2E45.7020704@unfix.org> <4C7D35C0.6040106@brightok.net> Message-ID: <4C7D3A99.5070808@unfix.org> On 2010-08-31 19:02, Jack Bates wrote: > Jeroen Massar wrote: >> just remember that a lot of people have VPN software, connect from home >> to that VPN and do other weird setups (Skype for instance, BitTorrent) >> where there are possibilities to bypass your "firewall". >> > > I agree. My concern here is that we are dealing with improper firewalls. Then fix your firewall, next to those administrators. You seem to love managing things centrally, but you forget that if you do things the MS way: Active Directory / Domains, that Teredo&6to4 are automatically turned off unless you turn the policy switch on. MS thus takes care of this. > We are dealing with ignorance, and we have M$ enabling teredo by default > (though not active until they install the appropriate app). No, Teredo & 6to4 (and ISATAP) are enabled per default on Vista/Win7 and also XP if you install IPv6, if the host has native it will use that, if is in non-RFC1918 space it will try 6to4, if it is in RFC1918 space it will try Teredo. This is great for getting IPv6 connectivity going. It is 'bad' for a corporate network. You can work around it two ways: enable native IPv6 or use active directory and voila the moment that a host is in the domain it does not do this automatically. If you do not administer the hosts then you don't have anything that you can do anyway as there will be software on those hosts which you will not like and which will easily pierce through your puny firewall. DNS tunnels near always work for that matter. > Creating what is essentially a public vpn through a firewall without > the user being aware of it is insecure. For all the wonderful popups that vista+ > gives, it amazes me that teredo isn't one of them. As there are no listening ports being opened and only outbound traffic is permitted, just the same as the IPv4 adapter, how is this 'dangerous' ? (unless the IPv6 stack is breakable) > 6to4 doesn't suffer the same issues. Primarily because RFC1918 > addressing can't be used in 6to4. This means that at a minimum, the > router has to participate or the host behind it must be manually > configured with a 6to4 address (for the proto 41 pass through to work). > Neither is an automatic traversal of the router's policies without user > knowledge. If you have one person setting up ICS on their machine and they have enabled IPv6 voila the whole network gets IPv6, that thus does not solve your problem either. Or are you monitoring IPv6 RAs etc? I think you have to move to better analyzing & monitoring your network and more control over the hosts which participate in that network. Greets, Jeroen From jbates at brightok.net Tue Aug 31 12:32:46 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 31 Aug 2010 12:32:46 -0500 Subject: Teredo and 'firewalls' (Re: Comcast enables 6to4 relays) In-Reply-To: <4C7D3A99.5070808@unfix.org> References: <4C7C31F7.9000503@brightok.net> <4C7CFEF2.2000505@brightok.net> <4C7D1BBB.2060502@unfix.org> <4C7D28C6.1020004@brightok.net> <4C7D2E45.7020704@unfix.org> <4C7D35C0.6040106@brightok.net> <4C7D3A99.5070808@unfix.org> Message-ID: <4C7D3CBE.70702@brightok.net> Jeroen Massar wrote: > > If you have one person setting up ICS on their machine and they have > enabled IPv6 voila the whole network gets IPv6, that thus does not solve > your problem either. Or are you monitoring IPv6 RAs etc? Setting up ICS with IPv6 is user knowledge in my opinion. In addition, the ICS will handle the firewall rules unless the user chooses to turn it off. > > I think you have to move to better analyzing & monitoring your network > and more control over the hosts which participate in that network. > My concern is as an ISP that has customers who are unaware that their little routers aren't filtering all of their packets. There are a million ways they might get infected or have security problems. However, teredo is obviously a circumvention of protection they *think* they have. Corporate networks can secure their own networks (or not, but they are held to a higher standard than average home user and failure to protect is their own fault). Jack From jeroen at unfix.org Tue Aug 31 12:40:26 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 31 Aug 2010 19:40:26 +0200 Subject: Teredo and 'firewalls' (Re: Comcast enables 6to4 relays) In-Reply-To: <4C7D3CBE.70702@brightok.net> References: <4C7C31F7.9000503@brightok.net> <4C7CFEF2.2000505@brightok.net> <4C7D1BBB.2060502@unfix.org> <4C7D28C6.1020004@brightok.net> <4C7D2E45.7020704@unfix.org> <4C7D35C0.6040106@brightok.net> <4C7D3A99.5070808@unfix.org> <4C7D3CBE.70702@brightok.net> Message-ID: <4C7D3E8A.4020805@unfix.org> On 2010-08-31 19:32, Jack Bates wrote: > Jeroen Massar wrote: >> >> If you have one person setting up ICS on their machine and they have >> enabled IPv6 voila the whole network gets IPv6, that thus does not solve >> your problem either. Or are you monitoring IPv6 RAs etc? > > Setting up ICS with IPv6 is user knowledge in my opinion. In addition, > the ICS will handle the firewall rules unless the user chooses to turn > it off. > >> >> I think you have to move to better analyzing & monitoring your network >> and more control over the hosts which participate in that network. >> > > My concern is as an ISP that has customers who are unaware that their > little routers aren't filtering all of their packets. There are a > million ways they might get infected or have security problems. However, > teredo is obviously a circumvention of protection they *think* they > have. There is no circumvention here. Teredo is the same as having a P2P app (take Skype as a random example) that connects to an outside host and uses that to relay messages to something else. Allowing outside hosts to use that network to connect to your inbound host. Teredo does not enable more inbound connections than before, unless a an App supports IPv6, but then that app was installed by the user thus they want it to run. Also note that XP/2k3/Vista/Seven/2k8 all have firewalls per default that support IPv6 and that handle IPv4 and IPv6 exactly the same: ask the user with an annoying popup. Vista/Seven/2k8 even (can) do that for outbound connections. The only thing you can do to help your users is to provide them with proper education and to explain them to keep up to date and run the right tools and not click anywhere they can.... and that is a mission which is near impossible. Teredo though is far from your worst worry. Just check how many "Teredo", or heck, IPv6 related infections you have and how many you have who have autodialers and the gazillion of other botnets on their hosts. You can sleep very tight over your perceived "Teredo" problem ;) Greets, Jeroen From nathan at atlasnetworks.us Tue Aug 31 12:58:03 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Tue, 31 Aug 2010 17:58:03 +0000 Subject: Teredo and 'firewalls' (Re: Comcast enables 6to4 relays) In-Reply-To: <4C7D3E8A.4020805@unfix.org> References: <4C7C31F7.9000503@brightok.net> <4C7CFEF2.2000505@brightok.net> <4C7D1BBB.2060502@unfix.org> <4C7D28C6.1020004@brightok.net> <4C7D2E45.7020704@unfix.org> <4C7D35C0.6040106@brightok.net> <4C7D3A99.5070808@unfix.org> <4C7D3CBE.70702@brightok.net> <4C7D3E8A.4020805@unfix.org> Message-ID: <8C26A4FDAE599041A13EB499117D3C281649D426@ex-mb-1.corp.atlasnetworks.us> > The only thing you can do to help your users is to provide them with proper > education and to explain them to keep up to date and run the right tools and > not click anywhere they can.... and that is a mission which is near impossible. I thought user education in threat management was long ago abandoned as a realistic defense mechanism. Don't get me wrong, I loved my users when I was supporting a desktop fleet; but the key to their survival was always policy implementation through Active Directory; back in the day, blocking executable files in email prevented a lot more problems than training users not to open them did. Don't get me wrong, every little bit helps. But when you consider your security with a scrutinous eye, you should always ignore the question 'how educated are my users'. It's irrelevant. From Sean.Siler at microsoft.com Tue Aug 31 13:01:43 2010 From: Sean.Siler at microsoft.com (Sean Siler) Date: Tue, 31 Aug 2010 18:01:43 +0000 Subject: Teredo and 'firewalls' (Re: Comcast enables 6to4 relays) In-Reply-To: <4C7D3E8A.4020805@unfix.org> References: <4C7C31F7.9000503@brightok.net> <4C7CFEF2.2000505@brightok.net> <4C7D1BBB.2060502@unfix.org> <4C7D28C6.1020004@brightok.net> <4C7D2E45.7020704@unfix.org> <4C7D35C0.6040106@brightok.net> <4C7D3A99.5070808@unfix.org> <4C7D3CBE.70702@brightok.net> <4C7D3E8A.4020805@unfix.org> Message-ID: <726B24CA0C7F494795894989DCF1FE0146656564@TK5EX14MBXC123.redmond.corp.microsoft.com> 1. I completely agree with Jeroen 2. Jack, if you have specific concerns that Jeroen hasn't answered, feel free to ping me off line. I own Teredo in Windows. Sean from "M$" -----Original Message----- From: Jeroen Massar [mailto:jeroen at unfix.org] Sent: Tuesday, August 31, 2010 10:40 AM To: Jack Bates Cc: NANOG Subject: Re: Teredo and 'firewalls' (Re: Comcast enables 6to4 relays) On 2010-08-31 19:32, Jack Bates wrote: > Jeroen Massar wrote: >> >> If you have one person setting up ICS on their machine and they have >> enabled IPv6 voila the whole network gets IPv6, that thus does not >> solve your problem either. Or are you monitoring IPv6 RAs etc? > > Setting up ICS with IPv6 is user knowledge in my opinion. In addition, > the ICS will handle the firewall rules unless the user chooses to turn > it off. > >> >> I think you have to move to better analyzing & monitoring your >> network and more control over the hosts which participate in that network. >> > > My concern is as an ISP that has customers who are unaware that their > little routers aren't filtering all of their packets. There are a > million ways they might get infected or have security problems. > However, teredo is obviously a circumvention of protection they > *think* they have. There is no circumvention here. Teredo is the same as having a P2P app (take Skype as a random example) that connects to an outside host and uses that to relay messages to something else. Allowing outside hosts to use that network to connect to your inbound host. Teredo does not enable more inbound connections than before, unless a an App supports IPv6, but then that app was installed by the user thus they want it to run. Also note that XP/2k3/Vista/Seven/2k8 all have firewalls per default that support IPv6 and that handle IPv4 and IPv6 exactly the same: ask the user with an annoying popup. Vista/Seven/2k8 even (can) do that for outbound connections. The only thing you can do to help your users is to provide them with proper education and to explain them to keep up to date and run the right tools and not click anywhere they can.... and that is a mission which is near impossible. Teredo though is far from your worst worry. Just check how many "Teredo", or heck, IPv6 related infections you have and how many you have who have autodialers and the gazillion of other botnets on their hosts. You can sleep very tight over your perceived "Teredo" problem ;) Greets, Jeroen From jeroen at unfix.org Tue Aug 31 13:05:39 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 31 Aug 2010 20:05:39 +0200 Subject: Teredo and 'firewalls' (Re: Comcast enables 6to4 relays) In-Reply-To: <8C26A4FDAE599041A13EB499117D3C281649D426@ex-mb-1.corp.atlasnetworks.us> References: <4C7C31F7.9000503@brightok.net> <4C7CFEF2.2000505@brightok.net> <4C7D1BBB.2060502@unfix.org> <4C7D28C6.1020004@brightok.net> <4C7D2E45.7020704@unfix.org> <4C7D35C0.6040106@brightok.net> <4C7D3A99.5070808@unfix.org> <4C7D3CBE.70702@brightok.net> <4C7D3E8A.4020805@unfix.org> <8C26A4FDAE599041A13EB499117D3C281649D426@ex-mb-1.corp.atlasnetworks.us> Message-ID: <4C7D4473.8010305@unfix.org> On 2010-08-31 19:58, Nathan Eisenberg wrote: >> The only thing you can do to help your users is to provide them with proper >> education and to explain them to keep up to date and run the right tools and >> not click anywhere they can.... and that is a mission which is near impossible. > > I thought user education in threat management was long ago abandoned as a > realistic defense mechanism. Don't get me wrong, I loved my users when I > was supporting a desktop fleet; but the key to their survival was always > policy implementation through Active Directory; back in the day, blocking > executable files in email prevented a lot more problems than training users > not to open them did. When you control the hosts in your network then indeed that works quite well and is most very likely the best approach, though it fails miserably again when users don't want to be part of your control. If you are an ISP then you don't control the hosts of your users and then the only thing left is to educate... which is near impossible as you state. > Don't get me wrong, every little bit helps. But when you consider > your security with a scrutinous eye, you should always ignore the question > 'how educated are my users'. It's irrelevant. As long as you check the PDF viewer version of the ladies at the HR department ;) Greets, Jeroen From marka at isc.org Tue Aug 31 17:13:57 2010 From: marka at isc.org (Mark Andrews) Date: Wed, 01 Sep 2010 08:13:57 +1000 Subject: Comcast enables 6to4 relays In-Reply-To: Your message of "Tue, 31 Aug 2010 16:22:03 +1000." <20100831062203.be89ed60@mail.wardenm.net> References: <20100831062203.be89ed60@mail.wardenm.net> Message-ID: <20100831221358.25FB63F9323@drugs.dv.isc.org> In message <20100831062203.be89ed60 at mail.wardenm.net>, "Mitchell Warden" writes : > > The list seems to be showing relays that announce both the IPv4 and the > > IPv6 anycast prefixes. > > > > I have noticed a number of deployments that announce the (in)famous IPv4 > > prefix and then consider their deployment complete. I suspect that there > > is a lack of 2002::/16 announcements and this would be contributing to > > the regular problems with return paths. > > > > Obviously the IPv6 content networks benefit the most from having a relay > > translating back to IPv4. > > > > Anyone have experience with this? > > > > -- > > Graham Beneke > > Is there a reason not to advertise more specific prefixes from 2002::/16 > to ensure that traffic for your v4 routes comes back to your own 6to4 > router? > > If for example all my users have v4 addresses in 192.0.2.0/24, I could > advertise 2002:C002:0000::/40 instead of or in addition to the full > 2002::/16. > > Cheers. > Mitchell Which would end up with the entire set of IPv4 routes in IPv6. This is not a good idea. Just do you part and encapuslate/decapsulate as soon as possible and let the other end do the same. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From giulianocm at uol.com.br Tue Aug 31 19:25:07 2010 From: giulianocm at uol.com.br (Giuliano Cardozo Medalha) Date: Tue, 31 Aug 2010 21:25:07 -0300 Subject: Q-In-Q using M7i and CISCO Switch In-Reply-To: <4C7D9CA7.1030504@uol.com.br> References: <4C7D9C6A.407@wztech.com.br> <4C7D9CA7.1030504@uol.com.br> Message-ID: <4C7D9D63.7090901@uol.com.br> People, We have a client with the following situation: v1, v2, v3 -------| Switch | ----------| Switch |----------------| Switch|------------- JUNIPER M7i IQ2E ----- Carrier offers only 3 vlans to the client. But he wants to push some more vlans inside the 3 ones. It is possible to initiate and finish Q-In-Q vlans using a cisco ME switch and a JUNIPER M7i with IQ2E interface ? The following link shows stack configuration. It can be used to do Q-In-Q with this situation ? http://www.juniper.com.lv/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-network-interfaces/id-12155750.html Someone tries to configure it any time ? Thanks a lot, Giuliano