From marcoh at marcoh.net Thu Apr 1 02:34:03 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 1 Apr 2010 09:34:03 +0200 Subject: Home CPE choice In-Reply-To: <4BB3E30D.6070604@foobar.org> References: <4BB3D2FF.7030608@knownelement.com> <4BB3E30D.6070604@foobar.org> Message-ID: <77817965-8EAE-4A28-8786-983FAD2B62CC@marcoh.net> On 1 apr 2010, at 02:04, Nick Hilliard wrote: > On 31/03/2010 23:55, Charles N Wyble wrote: >> What good off the shelf solutions are out there? Should one buy the high >> end d-link/linksys/netgear products? I've had bad experiences with those >> (netgear in particular). > > Some people have said that the Fritz!box is quite good. No idea if it's approved for use in the US. They have a very rich VoIP implementation and are really good for the less technical user. But for more eloborate setups they are a bit rigid, telnet to the box and you void warranty etc. Got a few hundred thousand in the field and most people seem to be happy with them. A limited set of IPv6 features is available in beta for some models, very basic interface to support various flavours of native connectios and tunnels. Small firewall interface to punch some pinholes (bit buggy still, being worked on). Enough for your average connection demands. As far as I know they aren't certified for US. Most of the boxes come with ISDN (the have german origins) and DECT base station, so next to the regular WiFi there is a lot of other stuff that needs changing an certification for the US market. My guess however is that those things are primairly driven by demand and if you order a truckload things can be fixed. At home I run cisco, but I guess that's due to my background. It's stable, flexible and I'm used to the interface. From a consumer perspective I'm really impressed by the latest Draytek Vigor (2130n). Pretty amazing RG which has a rich and easy to use future set and has a full and working IPv6 box on board. Unfortunately this doesn't include a VoIP client or DSL interface, both are being worked on I was told. It's build around a linux stack so everything is there: routing, firewalling. Mostly via the webinterface some only via cli (ssh/telnet). SNMP is included. For the DSL there is a workaround using the Vigor 120 box, which can tie DSL to ethernet and even is able to translate PPPoA into PPPoE. With the latest firmware it can also handle IPv6 on those PPP sessions. And since it's standard PPPoE out of the back it's also an easy fix for other RGs. Tested it yesterday together with an airport express and worked perfectly. Only problem I found was the airport seems to lack IPv6 support on it's PPPoE stack, which I was testing for. Enough for the plugging of the vendors :) Shameless plug for myself: I'm compiling a list of IPv6 ready CPE to be presented at RIPE-60, any hints and tips on what is out there and experiences so far are welcome off list. I'm about to send a simple questionair to known vendors, if you happen to be a CPE manufacturer and want to be included please contact me. Thansk, MarcoH From patrick at vande-walle.eu Thu Apr 1 03:28:21 2010 From: patrick at vande-walle.eu (Patrick Vande Walle) Date: Thu, 01 Apr 2010 10:28:21 +0200 Subject: Home CPE choice Message-ID: <6d018344aa47423bb33fca1d70ada845@localhost> On Thu, 01 Apr 2010 01:04:29 +0100, Nick Hilliard wrote: > On 31/03/2010 23:55, Charles N Wyble wrote: >> What good off the shelf solutions are out there? Should one buy the high >> end d-link/linksys/netgear products? I've had bad experiences with those >> (netgear in particular). > > Some people have said that the Fritz!box is quite good. No idea if it's > approved for use in the US. > > Nick The latest Fritz!Box is delivered with firmware that supports IPv6 (native, SixXS and 6to4 tunnels). They can do VoIP, too, and even include a built-in phone answering machine forwarding messages through email. There are official IPv6-enabled firmwares available for several models. They are not cheap but the quality is there. The manufacturer has been very responsive to advanced users expectations. If, for whatever reason the ADSL/VDSL modem part does not work well with your ISP, it can be used as a router only, with whatever cheapo modem that works in your area. http://www.avm.de/en/ Patrick Vande Walle -- Blog: http://patrick.vande-walle.eu Twitter: http://twitter.vande-walle.eu From jmamodio at gmail.com Thu Apr 1 04:10:43 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 1 Apr 2010 04:10:43 -0500 Subject: Finding content in your job title In-Reply-To: References: <4BB2BE2C.9000901@ibctech.ca> <4BB2C1DE.1070004@cox.net> <4BB3EA9F.4030302@mompl.net> Message-ID: I remember in the ol'days when everybody was fighting to have the "postmaster" title ... It was often associated with the possession of the root password, you had to feel the power !!! Cheers Jorge From lists at quux.de Thu Apr 1 04:19:14 2010 From: lists at quux.de (Jens Link) Date: Thu, 01 Apr 2010 11:19:14 +0200 Subject: Home CPE choice In-Reply-To: <4BB3D2FF.7030608@knownelement.com> (Charles N. Wyble's message of "Wed\, 31 Mar 2010 15\:55\:59 -0700") References: <4BB3D2FF.7030608@knownelement.com> Message-ID: <87mxxna5t9.fsf@bowmore.quux.de> Charles N Wyble writes: > Should one get a "real" cisco router? The 877 or something? 871 works very well here. You may find on heap on eBay. But *don't* get an 861. Last time i checked there was no IOS with IPv6 support for this model. > My current home router is a cisco 1841. I keep my 6mbps DSL line pretty > much saturated all the time. Often times my wife will be watching Hulu > in the living room, I'll be streaming music and running torrents > (granted I have tuned my Azures client fairly well) all at the same time > and it's a good experience. If it's working stick to it. ;-) Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From lists at quux.de Thu Apr 1 04:22:03 2010 From: lists at quux.de (Jens Link) Date: Thu, 01 Apr 2010 11:22:03 +0200 Subject: Home CPE choice In-Reply-To: <4BB3EB48.6010900@knownelement.com> (Charles N. Wyble's message of "Wed\, 31 Mar 2010 17\:39\:36 -0700") References: <4BB3D2FF.7030608@knownelement.com> <4BB3EB48.6010900@knownelement.com> Message-ID: <87iq8ba5ok.fsf@bowmore.quux.de> Charles N Wyble writes: > Have you tried pfsense, or do you find the built in > functionality/configuration system to be sufficient? AFAIK IPv6 is not supported via the GUI, but everything else is okay. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From jgreco at ns.sol.net Thu Apr 1 07:00:26 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 1 Apr 2010 06:00:26 -0600 (CST) Subject: 100% want IPv6 - Was: New Linksys CPE, IPv6 ? In-Reply-To: <20100401032232.GB5032@dan.olp.net> from "Dan White" at Mar 31, 2010 10:22:32 PM Message-ID: <201004011200.o31C0QLN095311@aurora.sol.net> > On 31/03/10?23:18?-0400, Patrick Giagnocavo wrote: > >Dan White wrote: > >> From a content perspective, you may be right. Those with a quickly > >> dwindling supply of v4 addresses will most likely use what they have left > >> for business customers, and for content. > >> > >> However, there will be a time when a significant number of > >> customers will not be able to access your content. > > > >^^ Uncertainty . > > > >> What percentage of sales are you willing to eat? > > > >^^ Fear . > > > >> > >> Are you willing to gamble your business on your expectations? Business > >> models will develop that will take advantage of global addressing to end > >> devices. The Next Big (Nth) Thing will. Do you feel that you have a perfect > >> Crystal Ball, or do you want to start hedging your bets now? > > > >^^ Doubt. > > http://www.iana.org/assignments/ipv4-address-space/ And on that note, I enclose the following, which was rejected by the RFC Editor, but seems relevant to this discussion, so here's the draft. ... 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. Network Working Group Joe Greco Request for Comments: [nnnn] sol.net Network Services Category: Experimental April 1, 2010 Expires March 2011 IPv4 Future Allocation Is Limited Unless Registries Expand Status of this Memo Distribution of this memo is unlimited. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The momentum of the currently deployed IPv4 network has resulted in a slower transition to IPv6 than expected, and IPv4 address reserves may soon be exhausted. This memo defines an additional class of IPv4 space which may be deployed as an interim solution. Greco, Joe Expires March 2011 FORMFEED[Page 1] Internet Draft IPv4 Class F Space April 1, 2010 Table of Contents 1. Introduction ....................................................2 2. Classful Addressing .............................................2 2.1. Expansion via Classful Addressing ..........................3 2.2. Impact on existing infrastructure ..........................3 2.3. Negative aspects to extending IPv4 lifetime ................4 2.4. Positive aspects to extending IPv4 lifetime ................4 2.5. Adjusted estimated IPv4 depletion date .....................4 2.6. Impact on IPv6 adoption ....................................4 3. Security Considerations .........................................5 4. IANA Considerations .............................................5 5. References ......................................................5 5.1. Informative References .....................................5 5.2. Acknowledgements ...........................................5 1. Introduction The current Internet addressing scheme has been reasonably successful at providing an Internet capable of providing network services to users. However, because of massive growth and the increasing number of networks being connected to the Internet, an ongoing shortage of network numbers has brought us close to the point where assignable IPv4 prefixes are exhausted. To combat this, the Internet is currently undergoing a major transition to IPv6. Despite the looming exhaustion of IPv4 space [IPv4_Report], IPv6 adoption rates have been slower than expected. Policy suggestions to extend the availability of IPv4 have ranged from reclamation of unused legacy IPv4 delegations [ICANN_feb08] to the use of carrier-grade NAT to place most customers of service providers on RFC1918 space [Nishitani]. We propose a different solution to the problem. RFC 1365 [RFC1365] and RFC 1375 [RFC1375] suggest some possible methods for implementing additional address classes. While classful addressing is now considered obsolete, the use of class to refer to a particular portion of the IPv4 address space is still useful for that purpose. Allocations within this space are expected to conform to existing CIDR allocation guidelines. By allocating an additional class, we gain a substantial amount of IP space. Greco, Joe Expires March 2011 FORMFEED[Page 2] Internet Draft IPv4 Class F Space April 1, 2010 2. Classful Addressing Classful addressing was introduced in RFC 791 [RFC791], providing Class A, B, and C spaces. RFC 1700 [RFC1700] defines Class D and E, and we derive the resulting table: Leading Network Class Bits Bits Range ------ ------- ------- ----- A 0 8 .0.n.n.n-127.n.n.n B 10 16 128.n.n.n-191.n.n.n C 110 24 192.n.n.n-223.n.n.n D 1110 undef 224.n.n.n-239.n.n.n E 1111 undef 240.n.n.n-255.n.n.n 2.1. Expansion via Classful Addressing While classful routing is generally no longer relevant, it provides us with a useful clue about how to proceed. The prepending of a new leading bit provides access to additional IP space, and so it would seem to be a reasonable short-term fix to define a new class, Class F, giving us: Leading Network Class Bits Bits Range ------ ------- ------- ----- A 0 8 0.n.n.n-127.n.n.n B 10 16 128.n.n.n-191.n.n.n C 110 24 192.n.n.n-223.n.n.n D 1110 undef 224.n.n.n-239.n.n.n E 1111 undef 240.n.n.n-255.n.n.n F 10000 undef 256.n.n.n-511.n.n.n This theoretically offers up to a few hundred more /8 assignments that IANA would delegate to registries as an interim solution. 2.2. Impact on existing infrastructure Currently deployed equipment may not be able to cope with an expanded range within the first octet. In particular, a router might fail to observe the additional leading bit. Such a scenario would effectively map network 257/8 into 1/8 on that device. Such a limitation can be carefully worked around through an allocation strategy that avoids currently occupied space in the Class A through C spaces. For example, 1/8 and 5/8 are currently IANA reserved space, 7/8 is assigned to DoD, and other various networks are unrouted or unoccupied as well. This suggests that 261/8 and 263/8 would be good targets for immediate allocation. Greco, Joe Expires March 2011 FORMFEED[Page 3] Internet Draft IPv4 Class F Space April 1, 2010 2.3. Negative aspects to extending IPv4 lifetime IPv4 lifetime estimates have frequently been incorrect. This has been one factor that had led to sluggish momentum in adopting IPv6, and has not generated sufficient urgency to move from IPv4 to IPv6. Artificially extending IPv4's available space with this proposal would be likely to slow IPv6 adoption rates, at least somewhat, as many decision makers would interpret the expansion of the IPv4 free pool as a compelling reason to avoid unnecessary near-term investment in migration to IPv6. 2.4. Positive aspects to extending IPv4 lifetime The cost of upgrading or replacing many networking devices globally is extremely high. A quick survey of contemporary networking devices suggests that even many current devices are incapable of supporting IPv6. The world is clearly not entirely ready for IPv6, and therefore IPv4 can be expected to be a requirement for many more years. Further, IPv6 renders it almost impossible to memorize IP addresses, which places undue burden on network engineers and analysts. Setting up a newly configured device virtually demands a cut-and-paste capable interface under IPv6. Finally, IPv6 is designed to waste a few billion v4 Internets worth of IP addresses for every autoconfigured ethernet. There are virtually endless IP addresses that will never be used, and the untapped potential wasted by IPv6 is depressing. IPv4, on the other hand, will ultimately be pushed to its technical limits, with triple- NAT becoming commonplace as service providers seek to optimize available space. This will be very exciting and will also help to keep network engineers gainfully employed. 2.5. Adjusted estimated IPv4 depletion date The current RIR allocation rate is approximately 12 /8's per year. This rate has grown slowly over time, and is estimated to be at least 20 /8's within five years. Extrapolation using conservative estimates suggests that Class F space would be exhausted around April 1st, 2020. 2.6. Impact on IPv6 adoption There has been much concern expressed about the slow adoption rate of IPv6. In a situation where IPv4 space was nearly depleted, the slow rate would be of great concern. However, by implementing Class F space as outlined in this document, it should be clear that depletion Greco, Joe Expires March 2011 FORMFEED[Page 4] Internet Draft IPv4 Class F Space April 1, 2010 need not be imminent, and in 2020, when there are finally 5,000 routes in the IPv6 table and Class F space is depleted, another clever solution will need to be devised. 3. Security Considerations There are no security considerations relevant to this document. 4. IANA Considerations No actions are required from IANA as result of the publication of this document. Implementation of the proposal contained herein may require some action, however. 5. References 5.1. Informative References [IPv4_Report] Huston, G., "IPv4 Address Report", 2009, . [ICANN_feb08] ICANN, "ICANN Recovers Large Block of Internet Address Space", February 2008, . [Nishitani] Nishitani, T., Yamagata, I., et. al., "Common Functions of Large Scale NAT", draft-nishitani-cgn-03. [RFC791] Information Sciences Institute, USC, "DARPA Internet Program Protocol Specification", RFC 791, September 1981. [RFC1365] Siyan, K., "An IP Address Extension Proposal", RFC 1365, September 1992. [RFC1375] Robinson, P., "Suggestion for New Classes of IP Addresses", RFC 1375, October 1992. [RFC1700] Reynolds, J. and Postel, J., "Assigned Numbers", RFC 1700, October 1994. 5.2. Acknowledgements The author would like to offer a special note of thanks to Robert E. Seastrom for pointing out that this would be Class F space. Greco, Joe Expires March 2011 FORMFEED[Page 5] Internet Draft IPv4 Class F Space April 1, 2010 Authors' Addresses Joe Greco sol.net Network Services P.O. Box 16 Milwaukee, WI 53201-0016 Phone: +1-888-830-2216 URI: http://www.sol.net/~jgreco EMail: rfc-apr1 at 4ac18e35.biz.jgreco.net Greco, Joe Expires March 2011 FORMFEED[Page 6] Internet Draft IPv4 Class F Space April 1, 2010 Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr at ietf.org. Greco, Joe Expires March 2011 FORMFEED[Page 7] From sil at infiltrated.net Thu Apr 1 07:15:43 2010 From: sil at infiltrated.net (J. Oquendo) Date: Thu, 01 Apr 2010 08:15:43 -0400 Subject: Juniper Denial of Service vulnerabilities Message-ID: <4BB48E6F.2010107@infiltrated.net> A Dual-Homed Swapfile Overflow Error can occur under controlled conditions causing multiple Denials of Service on Juniper SRX platforms. http://www.disgraced.org/junipervulns.html -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From braaen at zcorum.com Thu Apr 1 07:33:44 2010 From: braaen at zcorum.com (Brian Raaen) Date: Thu, 1 Apr 2010 08:33:44 -0400 Subject: Finding content in your job title In-Reply-To: <87fx3ggqhe.fsf@bowmore.quux.de> References: <4BB2BE2C.9000901@ibctech.ca> <87fx3ggqhe.fsf@bowmore.quux.de> Message-ID: <201004010833.45352.braaen@zcorum.com> Did that mean that your job was to ensure that the guillotine was sharpened and engineered securely? -- ---------------------- Brian Raaen Network Engineer braaen at zcorum.com On Wednesday 31 March 2010, Jens Link wrote: > Steve Bertrand writes: > > > For instance, I like to present myself as a 'network engineer'. I have > > never taken formal education, don't hold any certifications (well, since > > 2001), and can't necessarily prove my worth. > > Hey, network engineer is good. Some time back someone gave me the title > "senior executioner security engineer". They even send a document to a > customer with this title. > > Jens > -- > ------------------------------------------------------------------------- > | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | > | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | > ------------------------------------------------------------------------- > > From scott at sberkman.net Thu Apr 1 07:44:53 2010 From: scott at sberkman.net (Scott Berkman) Date: Thu, 1 Apr 2010 08:44:53 -0400 Subject: Home CPE choice In-Reply-To: <4BB3ECB9.6050209@knownelement.com> References: <4BB3D2FF.7030608@knownelement.com> <4BB3D5BE.9000808@emmanuelcomputerconsulting.com> <4BB3ECB9.6050209@knownelement.com> Message-ID: <005c01cad199$2099c3f0$61cd4bd0$@net> If you like open source routing platforms but want support and (possibly) a HW appliance (you can also just use their software), you may also want to take a look at Vyatta (http://www.vyatta.com/). They make a I haven't personally worked with the gear yet but I've heard some good things. -Scott -----Original Message----- From: Charles N Wyble [mailto:charles at knownelement.com] Sent: Wednesday, March 31, 2010 8:46 PM To: nanog at nanog.org Subject: Re: Home CPE choice On 03/31/2010 04:07 PM, William Warren wrote: > I run Astaro on a p-4 celey i had lying around. Get far more than any > little router you'll see..can't beat the price. Astaro looks cool. I hadn't heard of it before. Thanks for sharing. From jmamodio at gmail.com Thu Apr 1 07:58:22 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 1 Apr 2010 07:58:22 -0500 Subject: 100% want IPv6 - Was: New Linksys CPE, IPv6 ? In-Reply-To: <20100401031253.GA5032@dan.olp.net> References: <4BB3AB96.8050409@bogus.com> <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> Message-ID: I don't have any reference to support the idea that 100% of regular users want IPv6, I don't think they know or care to know what IPv6 is or what's the difference with IPv4 which most probably they don't know either besides few configuration screens of the devices they use. What for sure they eally want is high speed, reliable and omnipresent connectivity. I regularly ask about IPv6 when I find new information about a Home CPE class router because I'm engaged in some activities related to connecting "things" (which I don't intend to mean that people are also things), particularly in residential applications. Think about a combination of wired/wireless sensors and devices, energy management, security, home automation stuff. On the wireless front we are making some progress (probably too slow) on the IETF with 6LoWPAN, many other applications are gradually switching to ethernet or at least using lite TCP/IP. Then my interest is to have better knowledge about what on that class of equipment is on the pipeline, to deal with questions such as, do the particular application I mentioned above needs to be developed totally with native IPv6 ?, or IPv4 ?, or combination of both ?, do we require translation/tunneling/etc ?, or can defer that function to another device that will take care to send and get the packets from/to the net ? That sort of thing. Just to play with, I purchased a soekris net5501 board (very nice board for that price) and planning to start playing with it using FreeBSD. I took a look at the RouterBoard but the firmware license is too restrictive and there is no much hacking (well there is always a way to hack) you can do, but they are dirty cheap. Cheers Jorge From jgreco at ns.sol.net Thu Apr 1 08:49:05 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 1 Apr 2010 07:49:05 -0600 (CST) Subject: New Linksys CPE, IPv6 ? In-Reply-To: <2EC8CCE1-ADF3-4F67-AEFA-8CBFC8068111@delong.com> from "Owen DeLong" at Mar 31, 2010 04:08:00 PM Message-ID: <201004011349.o31Dn5TD000331@aurora.sol.net> > On Mar 31, 2010, at 1:53 PM, Michael Holstein wrote: > > > >> I checked the documentation for two models (Linux model and highest-end non-Linux model), and there's no mention of IPv6. > >> > > > > If this is a strictly "hardware" discussion, v6 "works" on a variety of > > models, albeit not with stock firmware. > > To wit : http://www.dd-wrt.com/wiki/index.php/IPv6 > > > > This suggests that Cisco (et.al.) can release an "official" firmware > > image to support v6 on existing devices whenever they're sufficiently > > motivated to do so. I'd wager the only reason it hasn't been made GA is > > to limit the number of "pass-the-buck" support calls that start at $isp > > and get bounced back saying "we don't support that yet, call whoever > > makes your router". > > Not necessarily. dd-wrt lacks the memory expense of the silly web > interface that Linksys is oh so fond of implementing in their consumer > grade boxen. I suspect that adding features to the Linksys code may > be a bit tighter on image and data space than dd-wrt's "stripped down" > efficiency. For cheap access points, we run OpenWRT on something like a 32M/8M WRT54G-TM, and there's never been a problem with memory, even after adding somewhat piggy (for embedded) stuff like ntpd. Of course, the normal platforms are a bit more cramped. It's apparently very easy to add IPv6 to OpenWRT, and you can opt to include or exclude things like a web interface. It's fairly competent and can support things like multi-SSID. Good place to start if you're used to a UNIX shell environment and Linux. Anyways, the point is, a lot of the heavy lifting has already been done to make multiple IPv6 firmwares for many of these devices. ... 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 nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Apr 1 08:50:08 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Fri, 2 Apr 2010 00:20:08 +1030 Subject: New Linksys CPE, IPv6 ? In-Reply-To: References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> Message-ID: <20100402002008.1fa6c7fb@opy.nosense.org> On Thu, 1 Apr 2010 00:16:03 +0000 Michael Dillon wrote: > On 1 April 2010 00:05, Nick Hilliard wrote: > > On 01/04/2010 00:40, Michael Dillon wrote: > >> > >> In fact, consumer demand for IPv6 is close to 100%. > > > > Michael, ?I think you fat-fingered "0%". > > > > Just to be clear, I'm talking about the real world here. > > I did not fat finger anything. In the real world, nearly 100% of consumers > demand IPv6 from their ISP. Exactly. Running out of "Internet Phone Numbers" is an unacceptable excuse to both customers and ISP management. > But consumers are not techies so they don't > talk that way with acronyms and technical gobbledygook version numbers. > In plain English they tell us that they want the Internet access service to > just plain work. They want it to work all the time, including tomorrow and > if they move across town, or to another city, they want to order a move > from the ISP, and have it done in a few days. > > ISPs who don't have IPv6 will soon be unable to provide access to all > Internet sites, as content providers begin to bring IPv6 sites onstream. > And ISPs without IPv6 will not be able to continue growing their networks, > even for something as trivial as an existing customer who moves to a > different PoP. > > The approaching time is going to be a crisis for the ISP industry, and > the press will tar some ISPs in a very bad light if they can't smoothly > introduce IPv6. There will be bargain basement sellouts and happy > M&A departments at ISPs with foresight who got their IPv6 capability > ready early. > > It's now like the calm before the storm. We know that a battle is coming > and we know roughly where and when it will be fought. Reports from > the field indicate that all is quiet, but that is normal just before the > battle commences. The wise general will not be put off by these reports > of peace and quiet, but will prepare his forces and keep an eye on > the preparations of his adversaries. > > --Michael Dillon > From LarrySheldon at cox.net Thu Apr 1 09:13:20 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 01 Apr 2010 09:13:20 -0500 Subject: 100% want IPv6 - Was: New Linksys CPE, IPv6 ? In-Reply-To: <20100401031253.GA5032@dan.olp.net> References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> Message-ID: <4BB4AA00.50808@cox.net> On 3/31/2010 22:12, Dan White wrote: > On 31/03/10 22:14 -0300, jim deleskie wrote: >> I'm a real life user, I know the difference and I could careless about >> v6. most anything I want I is on v4 and will still be there long >> after ( when ever it is) we run out of v4 addresses. If I'm on a > > From a content perspective, you may be right. Those with a quickly > dwindling supply of v4 addresses will most likely use what they have left > for business customers, and for content. > > However, there will be a time when a significant number of > customers will not be able to access your content. > >> content provider and I'm putting something new online I want everyone >> to see, they will find away for all of us with v4 and credit cards to >> see it, and not be so worried about developing countries or the sub 5% >> of people in developed countries for now. I'm sure @ some point v6 There is an indication here of the fault that is present in way too much of the world. We have here another example of [engineers|elites|experts|people-with-soap-boxes] think something is a good idea THEREFORE "Everybody wants it". My rant here needs refurbishment to account for wireless connections, but I've gotten a lot of mileage out of it. Most people of the world want something to eat. Omitting all of the intermediate steps, the few that have all of their other needs taken care of want smart wall paper. Most care not a whit how the wallpaper does it, they just want when the plug a lamp into it to get light. A toaster, warmed bread. A computer, to be able to exchange email, read the news, watch pornography, or play games. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Thu Apr 1 09:38:17 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 01 Apr 2010 09:38:17 -0500 Subject: 100% want IPv6 - Was: New Linksys CPE, IPv6 ? In-Reply-To: <4BB4AA00.50808@cox.net> References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> <4BB4AA00.50808@cox.net> Message-ID: <4BB4AFD9.7070906@cox.net> On 4/1/2010 09:13, Larry Sheldon wrote: > Most care not a whit how the wallpaper does it, they just want when the > plug a lamp into it to get light. A toaster, warmed bread. A computer, > to be able to exchange email, read the news, watch pornography, or play > games. Kindasorta related: http://www.4-blockworld.com/2010/03/computers-just-keep-getting-cheaper-and-better.html -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From marka at isc.org Thu Apr 1 09:54:58 2010 From: marka at isc.org (Mark Andrews) Date: Fri, 02 Apr 2010 01:54:58 +1100 Subject: FTC / Nexband In-Reply-To: Your message of "Tue, 30 Mar 2010 13:09:17 -0000." <20100330130917.GA32495@vacation.karoshi.com.> References: <78bfcf051003300603u10d0a4f9r1b094280c4bd32a2@mail.gmail.com> <20100330130917.GA32495@vacation.karoshi.com.> Message-ID: <201004011454.o31Esw27034942@drugs.dv.isc.org> In message <20100330130917.GA32495 at vacation.karoshi.com.>, bmanning at vacation.ka roshi.com writes: > On Tue, Mar 30, 2010 at 03:03:48PM +0200, Colin Alston wrote: > > In the real world, the result is more like: > > > > [coffee ~]$ dig +short adsl.fultontelephone.net A > > ;; Truncated, retrying in TCP mode. > > dig: dns_rdata_totext: ran out of space Logged as: [ISC-Bugs #21113] dig +short, fixed buffer size > > So yeah... if someone wants to correct that, it would be great. > > > > And if everyone else in the world can please not EVER do something > > like this, that would also be good. > > anyone for reverse mapping an IPv6 /32? > > --bill You only need to add PTR records for the addresses in use. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From ml at kenweb.org Thu Apr 1 10:04:25 2010 From: ml at kenweb.org (ML) Date: Thu, 01 Apr 2010 11:04:25 -0400 Subject: CPE Ethernet switch suggestions Message-ID: <4BB4B5F9.5020503@kenweb.org> Lately I've been delivering triple play services over a single CAT5 drop from a IDF to customers. We have been using small SOHO switches but they've been turning into a bit of a hassle since we have to stage each switch before deployment. I want remove the initial staging step by allowing the installer to just plug the switch in and have the switch grab a config from a TFTP server noted by a DHCP option. Features that I would absolutely need for the switch to be viable: IGMP Snooping Dot1q VLAN tagging Preferably 8-ports A decent set of rate limiting options (5/10/20Mbps) Extra bonus if it can also be PoE powered Does anyone on list know of such a dream CPE device? From drais at icantclick.org Thu Apr 1 10:13:55 2010 From: drais at icantclick.org (david raistrick) Date: Thu, 1 Apr 2010 11:13:55 -0400 (EDT) Subject: 100% want IPv6 - Was: New Linksys CPE, IPv6 ? In-Reply-To: <4BB41D70.7000409@bogus.com> References: <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> <4BB4109E.90006@zill.net> <20100401032232.GB5032@dan.olp.net> <4BB41871.8050608@zill.net> <4BB41D70.7000409@bogus.com> Message-ID: On Wed, 31 Mar 2010, Joel Jaeggli wrote: > On 03/31/2010 08:52 PM, Patrick Giagnocavo wrote: >> We have just (anecdotally, empirically) established earlier in this >> thread, that anything smaller than a mid-sized business, can't even >> *GET* IPv6 easily (at least in the USA); much less care about it. > > fwiw, that last time I was at a company that needed a prefix, we wrote > up an addressing plan, applied, received an assignment, payed our money > and were done. if a pool of public addresses are a resource you need to But were you able to get transit that let you use the address space? I'm sure it's getting better, but as recently as 2 years ago it was near impossible to get for most areas (and most providers, and most colo facilities). -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From scott at doc.net.au Thu Apr 1 10:55:20 2010 From: scott at doc.net.au (Scott Howard) Date: Thu, 1 Apr 2010 08:55:20 -0700 Subject: Raised floor, Solid floor... or carpet? Message-ID: Adding to the recent debate over raised v's solid floor, seem there's another option that wasn't discussed... http://www.iphouse.com/ Scott. From joelja at bogus.com Thu Apr 1 11:00:42 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 01 Apr 2010 09:00:42 -0700 Subject: 100% want IPv6 - Was: New Linksys CPE, IPv6 ? In-Reply-To: References: <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> <4BB4109E.90006@zill.net> <20100401032232.GB5032@dan.olp.net> <4BB41871.8050608@zill.net> <4BB41D70.7000409@bogus.com> Message-ID: <4BB4C32A.8030105@bogus.com> On 04/01/2010 08:13 AM, david raistrick wrote: > On Wed, 31 Mar 2010, Joel Jaeggli wrote: > >> On 03/31/2010 08:52 PM, Patrick Giagnocavo wrote: >>> We have just (anecdotally, empirically) established earlier in this >>> thread, that anything smaller than a mid-sized business, can't even >>> *GET* IPv6 easily (at least in the USA); much less care about it. >> >> fwiw, that last time I was at a company that needed a prefix, we wrote >> up an addressing plan, applied, received an assignment, payed our money >> and were done. if a pool of public addresses are a resource you need to > > > But were you able to get transit that let you use the address space? The entities that we pay money to to provide us with ip transit were willing to carry our ipv6 prefix yes, at the time, not all of them could do it on the first-hop router. > I'm sure it's getting better, but as recently as 2 years ago it was near > impossible to get for most areas (and most providers, and most colo > facilities). talk to your sales person, then make sure that their AS appears in the ipv6 DFZ. The well connected ASes at the center of the graph are prepared to sell you services. > > > -- > david raistrick http://www.netmeister.org/news/learn2quote.html > drais at icantclick.org http://www.expita.com/nomime.html > From owen at delong.com Thu Apr 1 01:00:22 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 31 Mar 2010 23:00:22 -0700 Subject: Home CPE choice In-Reply-To: References: <4BB3D2FF.7030608@knownelement.com> <4BB3D858.1010806@sunwave.net> Message-ID: <953DFC6A-A9E7-408C-BBA7-953CCC909D64@delong.com> Yeah, the one unfortunate ting in the J-series and SRX-series is that after 9.6 you have to put in a whole bunch of config to turn it back into a router. JunOS on these "services" routers now wants to behave like a netscreen until bludgeoned otherwise. The way to achieve this is not intuitively obvious, especially the forwarding-options mpls (which affects inet, not just mpls) and the flow stuff. Owen Here's a useful template for those that care: security { zones { security-zone trust { host-inbound-traffic { system-services { all; } protocols { all; bgp; ospf; router-discovery; } } interfaces { all; } } } alg { dns disable; ftp disable; h323 disable; mgcp disable; msrpc disable; sunrpc disable; real disable; rsh disable; rtsp disable; sccp disable; sip disable; sql disable; talk disable; tftp disable; pptp disable; } forwarding-options { family { inet6 { mode packet-based; } mpls { mode packet-based; } } } flow { allow-dns-reply; tcp-session { no-syn-check; no-syn-check-in-tunnel; no-sequence-check; } } } On Mar 31, 2010, at 4:23 PM, Iain Morris wrote: > Juniper's SSG5 and SRX100 are nice options for home. I've enjoyed an SSG5 > for awhile now. SRX100 for junos. SSG5's pop up on ebay occasionally for a > few $100. > > -Iain > > On Wed, Mar 31, 2010 at 4:18 PM, Marty Anstey wrote: > >> >>> >>> Hopefully this e-mail is considered operational content :) >>> >>> >>> The recent thread on the new linkys kit and ipv6 support got me >>> thinking about CPE choice. >>> >>> What good off the shelf solutions are out there? Should one buy the >>> high end d-link/linksys/netgear products? I've had bad experiences >>> with those (netgear in particular). >>> >>> Should one get a "real" cisco router? The 877 or something? Maybe an >>> ASA or the new small business targeted ISR (can't recall the model >>> number off hand right now). There is mikrotik but I'm not so sure >>> about the operating system. >>> >>> Is there a market for a new breed of CPE running OpenWRT or pfsense on >>> hardware with enough CPU/RAM to not fall over? >>> >>> Granted that won't cost $79.00 at best buy. However it seems to me >>> that decent CPE is going to run a couple hundred dollars in order to >>> have sufficient ram/cpu. >>> >>> My current home router is a cisco 1841. I keep my 6mbps DSL line >>> pretty much saturated all the time. Often times my wife will be >>> watching Hulu in the living room, I'll be streaming music and running >>> torrents (granted I have tuned my Azures client fairly well) all at >>> the same time and it's a good experience. Running that kind of >>> traffic load through my linksys would cause it to need a reboot once >>> or more a day. >>> >>> What are folks here running in SOHO environments that doesn't require >>> too frequent oil changes :) >>> >>> >> I run FreeBSD on a PIII; I can easily saturate my 15mbit cable >> connection without it breaking a sweat. I also have a couple Cisco >> 2610's, one of which is my ipv6 tunnel endpoint. >> >> -M >> >> >> >> >> > > > -- > -- - > Iain Morris > iain.t.morris at gmail.com From owen at delong.com Thu Apr 1 01:09:51 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 31 Mar 2010 23:09:51 -0700 Subject: Home CPE choice In-Reply-To: <0016e6541f9eb90c65048323c5a6@google.com> References: <0016e6541f9eb90c65048323c5a6@google.com> Message-ID: Having significant experience with all three products, I will strongly suggest going with the SRX-100 if at all possible. It's real JunOS, even if it does take a bit of bludgeoning to get it to stop impersonating a netscreen security model. It's the same price the NS5GTs used to sell for ~$5-600 (512MB/1G) and has a great deal more to offer (like fully functional routing protocols and JunOS configuration environment). Most of the NS5GTs I ever deployed in always-on environments didn't last more than about 3-4 years. The SSG-5s I've dealt with haven't started dying yet, but, most of them are only about 2 years old. Owen On Mar 31, 2010, at 7:39 PM, jonesnco at gmail.com wrote: > Netscreen 5GTs will also do IPv6 with some ScreenOS 5.4 code revs (5.4.0r10.0 for sure). Those pop up on Ebay for $60ish and make respectable home CPE devices. Not quite the horsepower of the SSG5 but they seem to hold up reasonably well. > > Dan Jones > >> Juniper's SSG5 and SRX100 are nice options for home. I've enjoyed an SSG5 >> for awhile now. SRX100 for junos. SSG5's pop up on ebay occasionally for a >> few $100. > >> -Iain > >> On Wed, Mar 31, 2010 at 4:18 PM, Marty Anstey wrote: > > >> > >> > Hopefully this e-mail is considered operational content :) >> > >> > >> > The recent thread on the new linkys kit and ipv6 support got me >> > thinking about CPE choice. >> > >> > What good off the shelf solutions are out there? Should one buy the >> > high end d-link/linksys/netgear products? I've had bad experiences >> > with those (netgear in particular). >> > >> > Should one get a "real" cisco router? The 877 or something? Maybe an >> > ASA or the new small business targeted ISR (can't recall the model >> > number off hand right now). There is mikrotik but I'm not so sure >> > about the operating system. >> > >> > Is there a market for a new breed of CPE running OpenWRT or pfsense on >> > hardware with enough CPU/RAM to not fall over? >> > >> > Granted that won't cost $79.00 at best buy. However it seems to me >> > that decent CPE is going to run a couple hundred dollars in order to >> > have sufficient ram/cpu. >> > >> > My current home router is a cisco 1841. I keep my 6mbps DSL line >> > pretty much saturated all the time. Often times my wife will be >> > watching Hulu in the living room, I'll be streaming music and running >> > torrents (granted I have tuned my Azures client fairly well) all at >> > the same time and it's a good experience. Running that kind of >> > traffic load through my linksys would cause it to need a reboot once >> > or more a day. >> > >> > What are folks here running in SOHO environments that doesn't require >> > too frequent oil changes :) >> > >> > >> I run FreeBSD on a PIII; I can easily saturate my 15mbit cable >> connection without it breaking a sweat. I also have a couple Cisco >> 2610's, one of which is my ipv6 tunnel endpoint. > >> -M > > > > > > > > -- > -- - > Iain Morris > iain.t.morris at gmail.com From owen at delong.com Thu Apr 1 01:16:49 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 31 Mar 2010 23:16:49 -0700 Subject: New Linksys CPE, IPv6 ? In-Reply-To: References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> Message-ID: > > > Until there are common sites that are only accessible via IPv6 -- thus > unavailable to "unevolved" ISP customers, ISP won't be investing > anything in IPv6 deployment. That's not to say ISPs aren't > experimenting with it -- some are, simply that they are not putting > any heavy engineering resources behind it. > I beg to differ. I know several ISPs that have been quietly putting quite a bit of engineering resource behind IPv6. The public announcement of residential IPv6 trials by Comcast was not the beginning of a serious commitment to IPv6 by Comcast, but, rather more towards the middle. Comcast has had substantial engineering resources on IPv6 for several years now. Will IPv6-only content be common soon? Probably not for at least another 5 years. Will IPv6-only eye-balls with severely degraded IPv4 customer experiences be common sooner? You bet. That one is unavoidable as there simply won't be IPv4 address space to use for some significant fraction of those customers. Owen From owen at delong.com Thu Apr 1 01:07:05 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 31 Mar 2010 23:07:05 -0700 Subject: 100% want IPv6 - Was: New Linksys CPE, IPv6 ? In-Reply-To: <4BB41871.8050608@zill.net> References: <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> <4BB4109E.90006@zill.net> <20100401032232.GB5032@dan.olp.net> <4BB41871.8050608@zill.net> Message-ID: On Mar 31, 2010, at 8:52 PM, Patrick Giagnocavo wrote: > Dan White wrote: > >>>> Are you willing to gamble your business on your expectations? Business >>>> models will develop that will take advantage of global addressing to end >>>> devices. The Next Big (Nth) Thing will. Do you feel that you have a >>>> perfect >>>> Crystal Ball, or do you want to start hedging your bets now? >>> >>> ^^ Doubt. >> >> http://www.iana.org/assignments/ipv4-address-space/ >> > > > We have just (anecdotally, empirically) established earlier in this > thread, that anything smaller than a mid-sized business, can't even > *GET* IPv6 easily (at least in the USA); much less care about it. > Huh??? I missed that somewhere. The previous paragraph is: Falsehood Uncertainty Doubt Contrary evidence: whois -h whois.arin.net 2620:0:930::/48 -- ARIN Direct Assignment Multihomed Household Qualified under stricter policy than is now in effect. http://www.tunnelbroker.net (yes, I work there, but, you don't have to work there to get a /48 for free). > Talking about a "crystal ball", in my view, is just a lot of hand-waving > that means "I don't have a real-world example to point to". > http://www.delong.com Real world web site multi-homed, dual-stacked, and running just fine. > Talking about "the Next Big Thing" means that somehow, the NBT will be > present without any residential or small business broadband users > partaking in it. Sounds like a pretty small piece of the pie for the NBT... > Again, conclusions not in evidence. It's easy for anyone who wants it to get IPv6 and IPv6 connectivity. Sure, native IPv6 is a little harder to get, but, overall, I'm doing OK with tunnels of various forms and native will be coming along shortly in many many more places. Owen From michael.holstein at csuohio.edu Thu Apr 1 11:36:17 2010 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Thu, 01 Apr 2010 12:36:17 -0400 Subject: Raised floor, Solid floor... or carpet? In-Reply-To: References: Message-ID: <4BB4CB81.6010702@csuohio.edu> > Adding to the recent debate over raised v's solid floor, seem there's > another option that wasn't discussed... > > http://www.iphouse.com/ > Nice to see smaller companies take the time to put up a good April fool's joke as well. From Bryan.Welch at arrisi.com Thu Apr 1 11:25:55 2010 From: Bryan.Welch at arrisi.com (Welch, Bryan) Date: Thu, 1 Apr 2010 09:25:55 -0700 Subject: Raised floor, Solid floor... or carpet? In-Reply-To: References: Message-ID: LoL.... Best April fools I've seen un quite a while! Thanks for sharing Bryan On Apr 1, 2010, at 9:04 AM, "Scott Howard" wrote: > Adding to the recent debate over raised v's solid floor, seem there's > another option that wasn't discussed... > > http://www.iphouse.com/ > > Scott. From jack at crepinc.com Thu Apr 1 11:42:22 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Thu, 1 Apr 2010 12:42:22 -0400 Subject: Raised floor, Solid floor... or carpet? In-Reply-To: References: Message-ID: "Our schedule for replacing the carpet was accelerated due to an approaching forced service contract expiration on our Roombas. The carpet pile was just getting to be too short for the Roombas to be efficient in their routes, and they would sometimes choke." Shear brilliance. That must be rather surprising to people used to standard facilities, seeing a hoard of Roombas stalking you... -Jack Carrozzo On Thu, Apr 1, 2010 at 11:55 AM, Scott Howard wrote: > Adding to the recent debate over raised v's solid floor, seem there's > another option that wasn't discussed... > > http://www.iphouse.com/ > > ?Scott. > From jack at crepinc.com Thu Apr 1 11:43:21 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Thu, 1 Apr 2010 12:43:21 -0400 Subject: Raised floor, Solid floor... or carpet? In-Reply-To: <4BB4CB81.6010702@csuohio.edu> References: <4BB4CB81.6010702@csuohio.edu> Message-ID: >> Nice to see smaller companies take the time to put up a good April >> fool's joke as well. ...Wow I got totally owned. Retreating to my corner, -Jack Carrozzo On Thu, Apr 1, 2010 at 12:36 PM, Michael Holstein wrote: > >> Adding to the recent debate over raised v's solid floor, seem there's >> another option that wasn't discussed... >> >> http://www.iphouse.com/ >> > > Nice to see smaller companies take the time to put up a good April > fool's joke as well. > > From brandon.kim at brandontek.com Thu Apr 1 11:46:54 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Thu, 1 Apr 2010 12:46:54 -0400 Subject: Raised floor, Solid floor... or carpet? In-Reply-To: References: Message-ID: Some questions: What about dust? Wouldn't the carpet hold down more dust then a regular floor, and at some point, the dust could kick back up and go right back into the servers? What about maintenance of the floor? (sweep/brooming wise) Isn't it easier to use something like iRobot on a flat floor than a carpeted one? I don't know the exact coding standards, but would it not be better to use those sound proof materials in the corner and walls around the datacenter? Wouldn't a carpet be bad for possible fires/flames or sparks? > Date: Thu, 1 Apr 2010 08:55:20 -0700 > Subject: Raised floor, Solid floor... or carpet? > From: scott at doc.net.au > To: nanog at nanog.org > > Adding to the recent debate over raised v's solid floor, seem there's > another option that wasn't discussed... > > http://www.iphouse.com/ > > Scott. From charles at knownelement.com Thu Apr 1 11:51:53 2010 From: charles at knownelement.com (Charles N Wyble) Date: Thu, 01 Apr 2010 09:51:53 -0700 Subject: Home CPE choice - summary Message-ID: <4BB4CF29.9090301@knownelement.com> Thank you everyone for your replies! :) It's been great having an operational type discussion. Here is my summary of the thread: Software: Linux: Vyatta IPCop Astaro BSD: pfSense m0n0wall (I didn't know this was the base for pfSense until I started researching it today) Appliances: Juniper. I have taken a Juniper course and have the Oreilly book, but I'm a Cisco guy pretty much through and through. Cisco 871 (I see these pop up on craigslist a fair amount. I suppose I'll pick one up and add it to my lab) Fritz!box (not available in the US) :( << I would love to get my hands on one of these. Hardware: Alix/Gumstix/Sokeris Various full desktop systems I got some great hardware sizing advice offline which referenced http://www.pfsense.org/index.php?option=com_content&task=view&id=52&Itemid=49 My choice: pfSense on a Dell Optiplex (dual core, 1 gig of ram). I think this should be more then sufficient for performing WAN duties and routing on a stick for my 3548 switch. I currently have an 1841 performing those duties and really like it. However I need it for my cisco cert studies. :) I was originally going to deploy pfSense in a KVM VM, but it appears BSD paravirtualization support may not be up to the level that Linux is at. If anyone has experience with this, please let me know. I have everything else deployed in virtual machines, but after reading a bit it seems that pfSense in a VM would consume a lot of CPU resources even doing moderate amounts of traffic (10 mbps). I don't want to starve out my other virtual machines. From egon at egon.cc Thu Apr 1 11:54:56 2010 From: egon at egon.cc (James Downs) Date: Thu, 1 Apr 2010 09:54:56 -0700 Subject: Raised floor, Solid floor... or carpet? In-Reply-To: References: Message-ID: <6A81B055-2E73-4FF2-BE9F-2C45D1875920@egon.cc> On Apr 1, 2010, at 9:46 AM, Brandon Kim wrote: > Wouldn't a carpet be bad for possible fires/flames or sparks? Looks like they got 2, now... -j From david.freedman at uk.clara.net Thu Apr 1 12:06:07 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Thu, 01 Apr 2010 18:06:07 +0100 Subject: Raised floor, Solid floor... or carpet? In-Reply-To: <4BB4CB81.6010702@csuohio.edu> References: <4BB4CB81.6010702@csuohio.edu> Message-ID: > Nice to see smaller companies take the time to put up a good April > fool's joke as well. > > Carpeted datacenters are no joke, check out Telehouse in London Docklands, the existing two buildings have been *fully carpeted* in both the corridors and data floors for some time (but as carpeted tiles, not a continual carpet, a bit like this: http://www.allcarpets.com.au/images/carpettiles.jpg) Dave. From brandon.kim at brandontek.com Thu Apr 1 12:15:19 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Thu, 1 Apr 2010 13:15:19 -0400 Subject: Raised floor, Solid floor... or carpet? In-Reply-To: References: , <4BB4CB81.6010702@csuohio.edu>, Message-ID: hahaha I fell for it HOOK LINE AND SINKER!!! DAMN YOU GUYS!!!! > Date: Thu, 1 Apr 2010 12:43:21 -0400 > Subject: Re: Raised floor, Solid floor... or carpet? > From: jack at crepinc.com > To: michael.holstein at csuohio.edu > CC: nanog at nanog.org > > >> Nice to see smaller companies take the time to put up a good April > >> fool's joke as well. > > ....Wow I got totally owned. > > Retreating to my corner, > > -Jack Carrozzo > > On Thu, Apr 1, 2010 at 12:36 PM, Michael Holstein > wrote: > > > >> Adding to the recent debate over raised v's solid floor, seem there's > >> another option that wasn't discussed... > >> > >> http://www.iphouse.com/ > >> > > > > Nice to see smaller companies take the time to put up a good April > > fool's joke as well. > > > > > From Valdis.Kletnieks at vt.edu Thu Apr 1 12:40:17 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 01 Apr 2010 13:40:17 -0400 Subject: 100% want IPv6 - Was: New Linksys CPE, IPv6 ? In-Reply-To: Your message of "Wed, 31 Mar 2010 23:18:54 EDT." <4BB4109E.90006@zill.net> References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> <4BB4109E.90006@zill.net> Message-ID: <13934.1270143617@localhost> On Wed, 31 Mar 2010 23:18:54 EDT, Patrick Giagnocavo said: > > However, there will be a time when a significant number of > > customers will not be able to access your content. > > ^^ Uncertainty . > > > What percentage of sales are you willing to eat? > > ^^ Fear . > > Are you willing to gamble your business on your expectations? Business > > models will develop that will take advantage of global addressing to end > > devices. The Next Big (Nth) Thing will. Do you feel that you have a perfect > > Crystal Ball, or do you want to start hedging your bets now? > > ^^ Doubt. So tell me Patrick - if you're not doing anything about it while it's still FUD, that leaves 2 questions: 1) How long will it take for you to design, test, and deploy once it's no longer FUD? 2) Will your business survive the ensuing pain waiting for deploy to complete? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From leo.vegoda at icann.org Thu Apr 1 13:00:48 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 1 Apr 2010 11:00:48 -0700 Subject: 192.0.0.0/24 In-Reply-To: References: <20100330061725.GA81284@metron.com> Message-ID: <5BC1B8BE-202C-4F2A-9667-CFF131B81C10@icann.org> On 30 Mar 2010, at 8:24, Leo Vegoda wrote: On 29 Mar 2010, at 11:17, Lou Katz wrote: > >> We recently were told to contact a client (via ftp) at 192.0.0.201. IANA lists this as >> Special Use, but refers to "RFC 3330 for additional information. http://www.rfc-editor.org/rfc/rfc3330.txt". >> This RFC says that it might be assigned in the future. > > RFC 3330 was obsoleted with the publication of RFC 5735. I thought I'd updated all the references we made to RFC 3330 but if I've missed one I'd be grateful if you could point me to it. I have now updated the registration for 192.0.0.0/24 in the ARIN whois database with more current references. Regards, Leo From mhernand1 at comcast.net Thu Apr 1 13:03:09 2010 From: mhernand1 at comcast.net (manolo hernandez) Date: Thu, 01 Apr 2010 14:03:09 -0400 Subject: Raised floor, Solid floor... or carpet? In-Reply-To: References: , <4BB4CB81.6010702@csuohio.edu>, Message-ID: <4BB4DFDD.5090205@comcast.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/1/10 1:15 PM, Brandon Kim wrote: > > hahaha I fell for it HOOK LINE AND SINKER!!! > > DAMN YOU GUYS!!!! > > > > > >> Date: Thu, 1 Apr 2010 12:43:21 -0400 >> Subject: Re: Raised floor, Solid floor... or carpet? >> From: jack at crepinc.com >> To: michael.holstein at csuohio.edu >> CC: nanog at nanog.org >> >>>> Nice to see smaller companies take the time to put up a good April >>>> fool's joke as well. >> >> ....Wow I got totally owned. >> >> Retreating to my corner, >> >> -Jack Carrozzo >> >> On Thu, Apr 1, 2010 at 12:36 PM, Michael Holstein >> wrote: >>> >>>> Adding to the recent debate over raised v's solid floor, seem there's >>>> another option that wasn't discussed... >>>> >>>> http://www.iphouse.com/ >>>> >>> >>> Nice to see smaller companies take the time to put up a good April >>> fool's joke as well. >>> >>> >> > Its an april fools joke for them. Dare I say that I have actually seen DCs with carpeting. My jaw dropped but it does exist. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLtN/cAAoJEOcnyWxdB1IrBoQH/1gTCRTcqCzsEVLxkxvuRKrb hdMT2YdoEe6L2iw1mbq4Gie1OrPIQdS5WwyraVqhlyL8BfSJ64bxWXj+FnqvK7fd 4ZTrbtWbS9yaPm/IO2CrD6FsVzrAH31czYQkpliJpJ9/V3PpfXFz+Bflq9STYhQR /bAGFbivqhWooGV+pL2dYjej84kTaGfmPxhic8nuiNgGY8b57lusutTtx7CXbsUK 9dQk4o2GUHAYtmQdXe4p6/MyWobsfUxOlEz8O1zGciN8tEBasbf0Vp/QodSUCVAi 3HnDeBOd9UwJO4qViGkZUiUvvMi5V9IcloHOIc7TC6ky9bRDuxedyQrSB76vlKk= =maX4 -----END PGP SIGNATURE----- From telmnstr at 757.org Thu Apr 1 13:36:56 2010 From: telmnstr at 757.org (telmnstr at 757.org) Date: Thu, 1 Apr 2010 14:36:56 -0400 (EDT) Subject: Raised floor, Solid floor... or carpet? In-Reply-To: <4BB4DFDD.5090205@comcast.net> References: , <4BB4CB81.6010702@csuohio.edu>, <4BB4DFDD.5090205@comcast.net> Message-ID: > Its an april fools joke for them. Dare I say that I have actually seen > DCs with carpeting. My jaw dropped but it does exist. We had carpeted floor tiles in a data center where I used to work. It was bound to the raised floor panels, and I was told it had anti static properties. Never noticed a static issue, but the room had proper air handlers with humidity control. The room was still loud, I'm not sure what dampening attributes it had for noise reduction. After a while the tiles start to wear a bit on the edges I suppose, but they had been in place for 5 years I believe and it looked fine (other than where liquid spills occoured on a distant side where people had some cubicles.) The puller to lift floor tiles had evil teeth, not suction cups. It could bite. - Ethan O'Toole From nonobvious at gmail.com Thu Apr 1 14:19:14 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Thu, 1 Apr 2010 12:19:14 -0700 Subject: 100% want IPv6 - Was: New Linksys CPE, IPv6 ? In-Reply-To: <201004011200.o31C0QLN095311@aurora.sol.net> References: <20100401032232.GB5032@dan.olp.net> <201004011200.o31C0QLN095311@aurora.sol.net> Message-ID: On Thu, Apr 1, 2010 at 5:00 AM, Joe Greco wrote: > And on that note, I enclose the following, which was rejected by the RFC > Editor, but seems relevant to this discussion, so here's the draft. Well of course it was rejected - using 257/8 sets the Evil Bit - you need to make that block Reserved. It may still have some applications as an augmentation to 127/8, so 257.0.0.1 is the address of your Evil Twin. From jgreco at ns.sol.net Thu Apr 1 15:43:03 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 1 Apr 2010 14:43:03 -0600 (CST) Subject: Raised floor, Solid floor... or carpet? In-Reply-To: from "telmnstr@757.org" at Apr 01, 2010 02:36:56 PM Message-ID: <201004012043.o31Kh3Ck016777@aurora.sol.net> > > Its an april fools joke for them. Dare I say that I have actually seen > > DCs with carpeting. My jaw dropped but it does exist. > > We had carpeted floor tiles in a data center where I used to work. It was > bound to the raised floor panels, and I was told it had anti static > properties. Never noticed a static issue, but the room had proper air > handlers with humidity control. Anti-static properties are obtained easily enough but sometimes the material requires periodic re-treating; the normal industrial chemical products like Staticide and Stat-trol are sometimes a little "stinky" and not always something you want to spray unless you can let it dry overnite. Since the floor tile does not have to be covered in tile and can have metal directly below the carpet, I would imagine that the anti-static properties would be halfway decent even with minimal treatments. Those who do not care for the stench of stinky chemicals seem to favor treating with Downy (yes, really, no Apr1). Especially in the earlier days of the Internet, where small ISP's set up shops in existing space, it seemed quite common to find them spraying a water/Downy mix on the carpets periodically, which left a characteristically odd "boy are my clothes ever so soft today" smell, and really did a number on static. What amazes me these days is how common it is to go someplace where the cubies are in "dry" conditions with carpets, and you see people hauling gear and cards back and forth while you can feel the static. You can get regular anti-static carpeting for office spaces too, though the problem with anything carrying the label "anti-static" tends to be expense. The meaning of the term also varies, ranging from static reduction to static suppression to static elimination. Ah, here we go: http://staticsmart.com/esd-static-control-products/access_floors.php ... 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 kilobit at gmail.com Thu Apr 1 16:03:14 2010 From: kilobit at gmail.com (bas) Date: Thu, 1 Apr 2010 23:03:14 +0200 Subject: Raised floor, Solid floor... or carpet? In-Reply-To: <201004012043.o31Kh3Ck016777@aurora.sol.net> References: <201004012043.o31Kh3Ck016777@aurora.sol.net> Message-ID: The old carpeting pics of iphouse looks like the one NIKHEF still has in Amsterdam. It is one of AMS-IX' locations. Telehouse North in London also has wonderfull carpeting... Bas From gbonser at seven.com Thu Apr 1 16:25:38 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 1 Apr 2010 14:25:38 -0700 Subject: New Linksys CPE, IPv6 ? In-Reply-To: References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org><4BB3B651.1020607@csuohio.edu><4BB3E363.6000708@foobar.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6BEF@RWC-EX1.corp.seven.com> > I beg to differ. I know several ISPs that have been quietly putting > quite > a bit of engineering resource behind IPv6. The public announcement > of residential IPv6 trials by Comcast was not the beginning of a > serious > commitment to IPv6 by Comcast, but, rather more towards the middle. > Comcast has had substantial engineering resources on IPv6 for > several years now. None of my transit providers currently offer native ipv6 where we are located. One recent vendor said they could tunnel 6 over 4 but any network address blocks assigned to that network would change at some point in the future. In other words, we could do v6 over 4 now but we would have to renumber later. What I heard at a recent (within the past six months) conference was that "there is no customer demand for v6" so it isn't on the immediate needs list. He said they had a lot of inquiries about v6, but to date not having native v6 wasn't a deal breaker with anyone. So my instincts tell me that until not being native v6 capable IS a deal breaker with potential clients, it isn't really going to go on the front burner. Many companies operate on the "it isn't a problem until it is a problem" model. George From sthaug at nethelp.no Thu Apr 1 16:35:32 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 01 Apr 2010 23:35:32 +0200 (CEST) Subject: New Linksys CPE, IPv6 ? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6BEF@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE08FE6BEF@RWC-EX1.corp.seven.com> Message-ID: <20100401.233532.74740368.sthaug@nethelp.no> > What I heard at a recent (within the past six months) conference was > that "there is no customer demand for v6" so it isn't on the immediate > needs list. He said they had a lot of inquiries about v6, but to date > not having native v6 wasn't a deal breaker with anyone. Last time we renegotiated transit contracts, we specified IPv6 as an absolute requirement. *Native* IPv6 was an added plus. As it turned out, two of our chosen transit providers could deliver native IPv6 from day one, and the third a few months later. Native IPv6 availability was one of several factors used to make the decision between transit providers. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jgreco at ns.sol.net Thu Apr 1 17:41:34 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 1 Apr 2010 16:41:34 -0600 (CST) Subject: Important: IPv4 Future Allocation Concept RFC Message-ID: <201004012241.o31MfZVk020791@aurora.sol.net> Someone suggested this be posted more visibly. ... 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. Network Working Group Joe Greco Request for Comments: [nnnn] sol.net Network Services Category: Experimental April 1, 2010 Expires March 2011 IPv4 Future Allocation Is Limited Unless Registries Expand Status of this Memo Distribution of this memo is unlimited. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The momentum of the currently deployed IPv4 network has resulted in a slower transition to IPv6 than expected, and IPv4 address reserves may soon be exhausted. This memo defines an additional class of IPv4 space which may be deployed as an interim solution. Greco, Joe Expires March 2011 FORMFEED[Page 1] Internet Draft IPv4 Class F Space April 1, 2010 Table of Contents 1. Introduction ....................................................2 2. Classful Addressing .............................................2 2.1. Expansion via Classful Addressing ..........................3 2.2. Impact on existing infrastructure ..........................3 2.3. Negative aspects to extending IPv4 lifetime ................4 2.4. Positive aspects to extending IPv4 lifetime ................4 2.5. Adjusted estimated IPv4 depletion date .....................4 2.6. Impact on IPv6 adoption ....................................4 3. Security Considerations .........................................5 4. IANA Considerations .............................................5 5. References ......................................................5 5.1. Informative References .....................................5 5.2. Acknowledgements ...........................................5 1. Introduction The current Internet addressing scheme has been reasonably successful at providing an Internet capable of providing network services to users. However, because of massive growth and the increasing number of networks being connected to the Internet, an ongoing shortage of network numbers has brought us close to the point where assignable IPv4 prefixes are exhausted. To combat this, the Internet is currently undergoing a major transition to IPv6. Despite the looming exhaustion of IPv4 space [IPv4_Report], IPv6 adoption rates have been slower than expected. Policy suggestions to extend the availability of IPv4 have ranged from reclamation of unused legacy IPv4 delegations [ICANN_feb08] to the use of carrier-grade NAT to place most customers of service providers on RFC1918 space [Nishitani]. We propose a different solution to the problem. RFC 1365 [RFC1365] and RFC 1375 [RFC1375] suggest some possible methods for implementing additional address classes. While classful addressing is now considered obsolete, the use of class to refer to a particular portion of the IPv4 address space is still useful for that purpose. Allocations within this space are expected to conform to existing CIDR allocation guidelines. By allocating an additional class, we gain a substantial amount of IP space. Greco, Joe Expires March 2011 FORMFEED[Page 2] Internet Draft IPv4 Class F Space April 1, 2010 2. Classful Addressing Classful addressing was introduced in RFC 791 [RFC791], providing Class A, B, and C spaces. RFC 1700 [RFC1700] defines Class D and E, and we derive the resulting table: Leading Network Class Bits Bits Range ------ ------- ------- ----- A 0 8 .0.n.n.n-127.n.n.n B 10 16 128.n.n.n-191.n.n.n C 110 24 192.n.n.n-223.n.n.n D 1110 undef 224.n.n.n-239.n.n.n E 1111 undef 240.n.n.n-255.n.n.n 2.1. Expansion via Classful Addressing While classful routing is generally no longer relevant, it provides us with a useful clue about how to proceed. The prepending of a new leading bit provides access to additional IP space, and so it would seem to be a reasonable short-term fix to define a new class, Class F, giving us: Leading Network Class Bits Bits Range ------ ------- ------- ----- A 0 8 0.n.n.n-127.n.n.n B 10 16 128.n.n.n-191.n.n.n C 110 24 192.n.n.n-223.n.n.n D 1110 undef 224.n.n.n-239.n.n.n E 1111 undef 240.n.n.n-255.n.n.n F 10000 undef 256.n.n.n-511.n.n.n This theoretically offers up to a few hundred more /8 assignments that IANA would delegate to registries as an interim solution. 2.2. Impact on existing infrastructure Currently deployed equipment may not be able to cope with an expanded range within the first octet. In particular, a router might fail to observe the additional leading bit. Such a scenario would effectively map network 257/8 into 1/8 on that device. Such a limitation can be carefully worked around through an allocation strategy that avoids currently occupied space in the Class A through C spaces. For example, 1/8 and 5/8 are currently IANA reserved space, 7/8 is assigned to DoD, and other various networks are unrouted or unoccupied as well. This suggests that 261/8 and 263/8 would be good targets for immediate allocation. Greco, Joe Expires March 2011 FORMFEED[Page 3] Internet Draft IPv4 Class F Space April 1, 2010 2.3. Negative aspects to extending IPv4 lifetime IPv4 lifetime estimates have frequently been incorrect. This has been one factor that had led to sluggish momentum in adopting IPv6, and has not generated sufficient urgency to move from IPv4 to IPv6. Artificially extending IPv4's available space with this proposal would be likely to slow IPv6 adoption rates, at least somewhat, as many decision makers would interpret the expansion of the IPv4 free pool as a compelling reason to avoid unnecessary near-term investment in migration to IPv6. 2.4. Positive aspects to extending IPv4 lifetime The cost of upgrading or replacing many networking devices globally is extremely high. A quick survey of contemporary networking devices suggests that even many current devices are incapable of supporting IPv6. The world is clearly not entirely ready for IPv6, and therefore IPv4 can be expected to be a requirement for many more years. Further, IPv6 renders it almost impossible to memorize IP addresses, which places undue burden on network engineers and analysts. Setting up a newly configured device virtually demands a cut-and-paste capable interface under IPv6. Finally, IPv6 is designed to waste a few billion v4 Internets worth of IP addresses for every autoconfigured ethernet. There are virtually endless IP addresses that will never be used, and the untapped potential wasted by IPv6 is depressing. IPv4, on the other hand, will ultimately be pushed to its technical limits, with triple- NAT becoming commonplace as service providers seek to optimize available space. This will be very exciting and will also help to keep network engineers gainfully employed. 2.5. Adjusted estimated IPv4 depletion date The current RIR allocation rate is approximately 12 /8's per year. This rate has grown slowly over time, and is estimated to be at least 20 /8's within five years. Extrapolation using conservative estimates suggests that Class F space would be exhausted around April 1st, 2020. 2.6. Impact on IPv6 adoption There has been much concern expressed about the slow adoption rate of IPv6. In a situation where IPv4 space was nearly depleted, the slow rate would be of great concern. However, by implementing Class F space as outlined in this document, it should be clear that depletion Greco, Joe Expires March 2011 FORMFEED[Page 4] Internet Draft IPv4 Class F Space April 1, 2010 need not be imminent, and in 2020, when there are finally 5,000 routes in the IPv6 table and Class F space is depleted, another clever solution will need to be devised. 3. Security Considerations There are no security considerations relevant to this document. 4. IANA Considerations No actions are required from IANA as result of the publication of this document. Implementation of the proposal contained herein may require some action, however. 5. References 5.1. Informative References [IPv4_Report] Huston, G., "IPv4 Address Report", 2009, . [ICANN_feb08] ICANN, "ICANN Recovers Large Block of Internet Address Space", February 2008, . [Nishitani] Nishitani, T., Yamagata, I., et. al., "Common Functions of Large Scale NAT", draft-nishitani-cgn-03. [RFC791] Information Sciences Institute, USC, "DARPA Internet Program Protocol Specification", RFC 791, September 1981. [RFC1365] Siyan, K., "An IP Address Extension Proposal", RFC 1365, September 1992. [RFC1375] Robinson, P., "Suggestion for New Classes of IP Addresses", RFC 1375, October 1992. [RFC1700] Reynolds, J. and Postel, J., "Assigned Numbers", RFC 1700, October 1994. 5.2. Acknowledgements The author would like to offer a special note of thanks to Robert E. Seastrom for pointing out that this would be Class F space. Greco, Joe Expires March 2011 FORMFEED[Page 5] Internet Draft IPv4 Class F Space April 1, 2010 Authors' Addresses Joe Greco sol.net Network Services P.O. Box 16 Milwaukee, WI 53201-0016 Phone: +1-888-830-2216 URI: http://www.sol.net/~jgreco EMail: rfc-apr1 at 4ac18e35.biz.jgreco.net Greco, Joe Expires March 2011 FORMFEED[Page 6] Internet Draft IPv4 Class F Space April 1, 2010 Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr at ietf.org. Greco, Joe Expires March 2011 FORMFEED[Page 7] From tmagill at providecommerce.com Thu Apr 1 18:02:03 2010 From: tmagill at providecommerce.com (Thomas Magill) Date: Thu, 1 Apr 2010 16:02:03 -0700 Subject: Important: IPv4 Future Allocation Concept RFC In-Reply-To: <201004012241.o31MfZVk020791@aurora.sol.net> References: <201004012241.o31MfZVk020791@aurora.sol.net> Message-ID: That is the best thing I've seen today. Kudos to whoever wrote that. :) -----Original Message----- From: Joe Greco [mailto:jgreco at ns.sol.net] Sent: Thursday, April 01, 2010 3:42 PM To: nanog at nanog.org Subject: Important: IPv4 Future Allocation Concept RFC Someone suggested this be posted more visibly. ... 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. Network Working Group Joe Greco Request for Comments: [nnnn] sol.net Network Services Category: Experimental April 1, 2010 Expires March 2011 IPv4 Future Allocation Is Limited Unless Registries Expand Status of this Memo Distribution of this memo is unlimited. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The momentum of the currently deployed IPv4 network has resulted in a slower transition to IPv6 than expected, and IPv4 address reserves may soon be exhausted. This memo defines an additional class of IPv4 space which may be deployed as an interim solution. Greco, Joe Expires March 2011 FORMFEED[Page 1] Internet Draft IPv4 Class F Space April 1, 2010 Table of Contents 1. Introduction ....................................................2 2. Classful Addressing .............................................2 2.1. Expansion via Classful Addressing ..........................3 2.2. Impact on existing infrastructure ..........................3 2.3. Negative aspects to extending IPv4 lifetime ................4 2.4. Positive aspects to extending IPv4 lifetime ................4 2.5. Adjusted estimated IPv4 depletion date .....................4 2.6. Impact on IPv6 adoption ....................................4 3. Security Considerations .........................................5 4. IANA Considerations .............................................5 5. References ......................................................5 5.1. Informative References .....................................5 5.2. Acknowledgements ...........................................5 1. Introduction The current Internet addressing scheme has been reasonably successful at providing an Internet capable of providing network services to users. However, because of massive growth and the increasing number of networks being connected to the Internet, an ongoing shortage of network numbers has brought us close to the point where assignable IPv4 prefixes are exhausted. To combat this, the Internet is currently undergoing a major transition to IPv6. Despite the looming exhaustion of IPv4 space [IPv4_Report], IPv6 adoption rates have been slower than expected. Policy suggestions to extend the availability of IPv4 have ranged from reclamation of unused legacy IPv4 delegations [ICANN_feb08] to the use of carrier-grade NAT to place most customers of service providers on RFC1918 space [Nishitani]. We propose a different solution to the problem. RFC 1365 [RFC1365] and RFC 1375 [RFC1375] suggest some possible methods for implementing additional address classes. While classful addressing is now considered obsolete, the use of class to refer to a particular portion of the IPv4 address space is still useful for that purpose. Allocations within this space are expected to conform to existing CIDR allocation guidelines. By allocating an additional class, we gain a substantial amount of IP space. Greco, Joe Expires March 2011 FORMFEED[Page 2] Internet Draft IPv4 Class F Space April 1, 2010 2. Classful Addressing Classful addressing was introduced in RFC 791 [RFC791], providing Class A, B, and C spaces. RFC 1700 [RFC1700] defines Class D and E, and we derive the resulting table: Leading Network Class Bits Bits Range ------ ------- ------- ----- A 0 8 .0.n.n.n-127.n.n.n B 10 16 128.n.n.n-191.n.n.n C 110 24 192.n.n.n-223.n.n.n D 1110 undef 224.n.n.n-239.n.n.n E 1111 undef 240.n.n.n-255.n.n.n 2.1. Expansion via Classful Addressing While classful routing is generally no longer relevant, it provides us with a useful clue about how to proceed. The prepending of a new leading bit provides access to additional IP space, and so it would seem to be a reasonable short-term fix to define a new class, Class F, giving us: Leading Network Class Bits Bits Range ------ ------- ------- ----- A 0 8 0.n.n.n-127.n.n.n B 10 16 128.n.n.n-191.n.n.n C 110 24 192.n.n.n-223.n.n.n D 1110 undef 224.n.n.n-239.n.n.n E 1111 undef 240.n.n.n-255.n.n.n F 10000 undef 256.n.n.n-511.n.n.n This theoretically offers up to a few hundred more /8 assignments that IANA would delegate to registries as an interim solution. 2.2. Impact on existing infrastructure Currently deployed equipment may not be able to cope with an expanded range within the first octet. In particular, a router might fail to observe the additional leading bit. Such a scenario would effectively map network 257/8 into 1/8 on that device. Such a limitation can be carefully worked around through an allocation strategy that avoids currently occupied space in the Class A through C spaces. For example, 1/8 and 5/8 are currently IANA reserved space, 7/8 is assigned to DoD, and other various networks are unrouted or unoccupied as well. This suggests that 261/8 and 263/8 would be good targets for immediate allocation. Greco, Joe Expires March 2011 FORMFEED[Page 3] Internet Draft IPv4 Class F Space April 1, 2010 2.3. Negative aspects to extending IPv4 lifetime IPv4 lifetime estimates have frequently been incorrect. This has been one factor that had led to sluggish momentum in adopting IPv6, and has not generated sufficient urgency to move from IPv4 to IPv6. Artificially extending IPv4's available space with this proposal would be likely to slow IPv6 adoption rates, at least somewhat, as many decision makers would interpret the expansion of the IPv4 free pool as a compelling reason to avoid unnecessary near-term investment in migration to IPv6. 2.4. Positive aspects to extending IPv4 lifetime The cost of upgrading or replacing many networking devices globally is extremely high. A quick survey of contemporary networking devices suggests that even many current devices are incapable of supporting IPv6. The world is clearly not entirely ready for IPv6, and therefore IPv4 can be expected to be a requirement for many more years. Further, IPv6 renders it almost impossible to memorize IP addresses, which places undue burden on network engineers and analysts. Setting up a newly configured device virtually demands a cut-and-paste capable interface under IPv6. Finally, IPv6 is designed to waste a few billion v4 Internets worth of IP addresses for every autoconfigured ethernet. There are virtually endless IP addresses that will never be used, and the untapped potential wasted by IPv6 is depressing. IPv4, on the other hand, will ultimately be pushed to its technical limits, with triple- NAT becoming commonplace as service providers seek to optimize available space. This will be very exciting and will also help to keep network engineers gainfully employed. 2.5. Adjusted estimated IPv4 depletion date The current RIR allocation rate is approximately 12 /8's per year. This rate has grown slowly over time, and is estimated to be at least 20 /8's within five years. Extrapolation using conservative estimates suggests that Class F space would be exhausted around April 1st, 2020. 2.6. Impact on IPv6 adoption There has been much concern expressed about the slow adoption rate of IPv6. In a situation where IPv4 space was nearly depleted, the slow rate would be of great concern. However, by implementing Class F space as outlined in this document, it should be clear that depletion Greco, Joe Expires March 2011 FORMFEED[Page 4] Internet Draft IPv4 Class F Space April 1, 2010 need not be imminent, and in 2020, when there are finally 5,000 routes in the IPv6 table and Class F space is depleted, another clever solution will need to be devised. 3. Security Considerations There are no security considerations relevant to this document. 4. IANA Considerations No actions are required from IANA as result of the publication of this document. Implementation of the proposal contained herein may require some action, however. 5. References 5.1. Informative References [IPv4_Report] Huston, G., "IPv4 Address Report", 2009, . [ICANN_feb08] ICANN, "ICANN Recovers Large Block of Internet Address Space", February 2008, . [Nishitani] Nishitani, T., Yamagata, I., et. al., "Common Functions of Large Scale NAT", draft-nishitani-cgn-03. [RFC791] Information Sciences Institute, USC, "DARPA Internet Program Protocol Specification", RFC 791, September 1981. [RFC1365] Siyan, K., "An IP Address Extension Proposal", RFC 1365, September 1992. [RFC1375] Robinson, P., "Suggestion for New Classes of IP Addresses", RFC 1375, October 1992. [RFC1700] Reynolds, J. and Postel, J., "Assigned Numbers", RFC 1700, October 1994. 5.2. Acknowledgements The author would like to offer a special note of thanks to Robert E. Seastrom for pointing out that this would be Class F space. Greco, Joe Expires March 2011 FORMFEED[Page 5] Internet Draft IPv4 Class F Space April 1, 2010 Authors' Addresses Joe Greco sol.net Network Services P.O. Box 16 Milwaukee, WI 53201-0016 Phone: +1-888-830-2216 URI: http://www.sol.net/~jgreco EMail: rfc-apr1 at 4ac18e35.biz.jgreco.net Greco, Joe Expires March 2011 FORMFEED[Page 6] Internet Draft IPv4 Class F Space April 1, 2010 Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr at ietf.org. Greco, Joe Expires March 2011 FORMFEED[Page 7] From tony at lava.net Thu Apr 1 18:05:11 2010 From: tony at lava.net (Antonio Querubin) Date: Thu, 1 Apr 2010 13:05:11 -1000 (HST) Subject: Important: IPv4 Future Allocation Concept RFC In-Reply-To: <201004012241.o31MfZVk020791@aurora.sol.net> References: <201004012241.o31MfZVk020791@aurora.sol.net> Message-ID: On Thu, 1 Apr 2010, Joe Greco wrote: > Someone suggested this be posted more visibly. Sooo, uh, timely :) Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From mooregr at greenms.com Thu Apr 1 18:26:20 2010 From: mooregr at greenms.com (Greg D. Moore) Date: Thu, 01 Apr 2010 19:26:20 -0400 Subject: Important: IPv4 Future Allocation Concept RFC In-Reply-To: <201004012241.o31MfZVk020791@aurora.sol.net> References: <201004012241.o31MfZVk020791@aurora.sol.net> Message-ID: <20100401232457.7D5771B402E@relay32.relay.iad.mlsrvr.com> At 06:41 PM 4/1/2010, Joe Greco wrote: Ok, this is weird. I had suggested almost exactly this same scheme to someone else earlier today. When did you put the bug in my office? Greg D. Moore President mooregr at greenms.com Ask me about lily, an RPI based chat system: http://lilycore.sourceforge.net/ Help honor our WWII Veterans: http://www.honorflight.org/ From dlc at lampinc.com Thu Apr 1 18:25:42 2010 From: dlc at lampinc.com (Dale Carstensen) Date: Thu, 01 Apr 2010 17:25:42 -0600 Subject: 100% want IPv6 - Was: New Linksys CPE, IPv6 ? In-Reply-To: References: <4BB3AB96.8050409@bogus.com> <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> Message-ID: <20100401232540.B248338D600@lampinc.com> >Date: Thu, 1 Apr 2010 07:58:22 -0500 >To: Dan White >cc: NANOG >From: Jorge Amodio >Subject: Re: 100% want IPv6 - Was: New Linksys CPE, IPv6 ? >Just to play with, I purchased a soekris net5501 board (very nice >board for that price) and planning to start playing with it using >FreeBSD. I took a look at the RouterBoard but the firmware license is >too restrictive and there is no much hacking (well there is always a >way to hack) you can do, but they are dirty cheap. > >Cheers >Jorge You can cross-compile openwrt for RouterBoard (check which models, though), and that would mean no license fee for the software. Maybe that voids some warranty, but if warrantys for sub-US$100 equipment are really worth anything, what would anybody offer me for several dozen mostly Linksys with some D-Link, Netgear and at least one each of Dynix and Belkin SOHO routers? Also, the Mikrotik RouterOS license is bundled with the hardware purchase, too, so it might be years before you'd need to spend another US$45 to update that to a new version, if you want to run RouterOS instead of something else. Dale From jimb at jsbc.cc Thu Apr 1 19:11:33 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Thu, 01 Apr 2010 17:11:33 -0700 Subject: Important: IPv4 Future Allocation Concept RFC In-Reply-To: <201004012241.o31MfZVk020791@aurora.sol.net> References: <201004012241.o31MfZVk020791@aurora.sol.net> Message-ID: <4BB53635.1070508@jsbc.cc> On 4/1/2010 15:41, Joe Greco wrote: > Someone suggested this be posted more visibly. > > ... JG > LOL -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5570 bytes Desc: S/MIME Cryptographic Signature URL: From ops.lists at gmail.com Thu Apr 1 21:54:05 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 2 Apr 2010 08:24:05 +0530 Subject: FTC / Nexband In-Reply-To: <201004011454.o31Esw27034942@drugs.dv.isc.org> References: <78bfcf051003300603u10d0a4f9r1b094280c4bd32a2@mail.gmail.com> <20100330130917.GA32495@vacation.karoshi.com.> <201004011454.o31Esw27034942@drugs.dv.isc.org> Message-ID: On Thu, Apr 1, 2010 at 8:24 PM, Mark Andrews wrote: > You only need to add PTR records for the addresses in use. > Not really the way most automated dns provisioning systems work today .. and where would they be without $GENERATE in bind? :) -- Suresh Ramasubramanian (ops.lists at gmail.com) From gspoofer at spoofer.com Thu Apr 1 22:34:30 2010 From: gspoofer at spoofer.com (John Doe) Date: Thu, 1 Apr 2010 20:34:30 -0700 Subject: Top 50 Bad Hosts & Networks 2009 Message-ID: <20100401203430.96D409C6@resin15.mta.everyone.net> http://hostexploit.com/index.php?option=com_content&view=article&id=201 &Itemid=106 __________________________________________________________________ Get your own *free* email address like this one from www.OwnEmail.com From swmike at swm.pp.se Thu Apr 1 22:51:35 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 2 Apr 2010 05:51:35 +0200 (CEST) Subject: Top 50 Bad Hosts & Networks 2009 In-Reply-To: <20100401203430.96D409C6@resin15.mta.everyone.net> References: <20100401203430.96D409C6@resin15.mta.everyone.net> Message-ID: On Thu, 1 Apr 2010, John Doe wrote: > http://hostexploit.com/index.php?option=com_content&view=article&id=201 > &Itemid=106 AS23456 will just continue to grow I guess, but considering the quite few networks with 32bit ASN I guesss it might be an advantage for some abusing networks to actually get this as some tracking tools doesn't seem to support it and it's thus harder to find the responsible network. -- Mikael Abrahamsson email: swmike at swm.pp.se From leo.vegoda at icann.org Thu Apr 1 23:16:05 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 1 Apr 2010 21:16:05 -0700 Subject: Note change in IANA registry URLs (was: Re: 100% want IPv6 - Was: New Linksys CPE, IPv6 ?) In-Reply-To: <20100401032232.GB5032@dan.olp.net> References: <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> <4BB4109E.90006@zill.net> <20100401032232.GB5032@dan.olp.net> Message-ID: On Mar 31, 2010, at 8:22 PM, Dan White wrote: [?] > http://www.iana.org/assignments/ipv4-address-space/ I think it's worth pointing out again that the URLs for IANA registries have changed and the old URLs, like the one above, will be going away from next week. Anyone automatically parsing the registries should make sure they adjust their scripts before then. Full details can be found in the announcement: http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=50520&tid=1270181265 and the URL for all registries can always be found from: http://www.iana.org/protocols/ Regards, Leo From mansaxel at besserwisser.org Thu Apr 1 23:32:54 2010 From: mansaxel at besserwisser.org (Mans Nilsson) Date: Fri, 2 Apr 2010 06:32:54 +0200 Subject: New Linksys CPE, IPv6 ? In-Reply-To: <20100401.233532.74740368.sthaug@nethelp.no> References: <5A6D953473350C4B9995546AFE9939EE08FE6BEF@RWC-EX1.corp.seven.com> <20100401.233532.74740368.sthaug@nethelp.no> Message-ID: <20100402043254.GB14109@besserwisser.org> Subject: Re: New Linksys CPE, IPv6 ? Date: Thu, Apr 01, 2010 at 11:35:32PM +0200 Quoting sthaug at nethelp.no (sthaug at nethelp.no): > > What I heard at a recent (within the past six months) conference was > > that "there is no customer demand for v6" so it isn't on the immediate > > needs list. He said they had a lot of inquiries about v6, but to date > > not having native v6 wasn't a deal breaker with anyone. > > Last time we renegotiated transit contracts, we specified IPv6 as an > absolute requirement. *Native* IPv6 was an added plus. We went further and required native. At 10GE interconnect speed, one is in the recently-upgraded core or metro access layer of most providers. These parts of the network have been ready (if not set up) for v6 for at least 5 years now. Did not pose a problem. All I need to do now is to set up the peering ;-) Had I been looking for a FE transit I'd had much more issues with v6 connectivity. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 INSIDE, I have the same personality disorder as LUCY RICARDO!! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From owen at delong.com Thu Apr 1 10:39:10 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Apr 2010 08:39:10 -0700 Subject: 100% want IPv6 - Was: New Linksys CPE, IPv6 ? In-Reply-To: References: <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> <4BB4109E.90006@zill.net> <20100401032232.GB5032@dan.olp.net> <4BB41871.8050608@zill.net> <4BB41D70.7000409@bogus.com> Message-ID: <252D7CB5-7D7F-4A14-B483-433979CBE241@delong.com> On Apr 1, 2010, at 8:13 AM, david raistrick wrote: > On Wed, 31 Mar 2010, Joel Jaeggli wrote: > >> On 03/31/2010 08:52 PM, Patrick Giagnocavo wrote: >>> We have just (anecdotally, empirically) established earlier in this >>> thread, that anything smaller than a mid-sized business, can't even >>> *GET* IPv6 easily (at least in the USA); much less care about it. >> >> fwiw, that last time I was at a company that needed a prefix, we wrote >> up an addressing plan, applied, received an assignment, payed our money >> and were done. if a pool of public addresses are a resource you need to > > > But were you able to get transit that let you use the address space? > > I'm sure it's getting better, but as recently as 2 years ago it was near impossible to get for most areas (and most providers, and most colo facilities). > Worst case, it's easy with a free tunnel now, and, in most cases, better solutions are readily available. Owen From robert at ripe.net Fri Apr 2 04:42:25 2010 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 02 Apr 2010 11:42:25 +0200 Subject: Note change in IANA registry URLs In-Reply-To: References: <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> <4BB4109E.90006@zill.net> <20100401032232.GB5032@dan.olp.net> Message-ID: <4BB5BC01.1080005@ripe.net> On 2010.04.02. 6:16, Leo Vegoda wrote: > On Mar 31, 2010, at 8:22 PM, Dan White wrote: > > [?] > >> http://www.iana.org/assignments/ipv4-address-space/ > > I think it's worth pointing out again that the URLs for IANA registries > have changed and the old URLs, like the one above, will be going away > from next week. Anyone automatically parsing the registries should make > sure they adjust their scripts before then. I don't know what good reasons you might have to pull down the current URLs. Please keep them working. Recommended reading: http://www.w3.org/Provider/Style/URI Robert From bortzmeyer at nic.fr Fri Apr 2 04:53:17 2010 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 2 Apr 2010 11:53:17 +0200 Subject: Note change in IANA registry URLs In-Reply-To: <4BB5BC01.1080005@ripe.net> References: <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> <4BB4109E.90006@zill.net> <20100401032232.GB5032@dan.olp.net> <4BB5BC01.1080005@ripe.net> Message-ID: <20100402095317.GA23768@nic.fr> On Fri, Apr 02, 2010 at 11:42:25AM +0200, Robert Kisteleki wrote a message of 20 lines which said: > I don't know what good reasons you might have to pull down the current > URLs. Please keep them working. I strongly agree and, by the way, it seems this was partially mentioned in the original announcement: > The old URLs will contain information for the location of the new > versions available (TXT, XML and XHTML). From rs at seastrom.com Fri Apr 2 07:09:29 2010 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 02 Apr 2010 08:09:29 -0400 Subject: Books for the NOC guys... Message-ID: <86wrwqukcm.fsf@seastrom.com> This morning I went digging for a book to recommend that someone in our NOC read in order to understand at a high level how Internet infrastructure works (bgp, igps, etc) and discovered that the old standbys (Huitema, Halabi, Perlman) have all not been updated in a decade or so. On the one hand, they're all still quite relevant since there hasn't been anything really earth-shattering in that department, but they are all going to be lean to nonexistent on stuff like IPv6 and NLRI negotiation. So, what are you having your up-and-coming NOC staff read? Thanks, -r From rdobbins at arbor.net Fri Apr 2 07:21:54 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 2 Apr 2010 12:21:54 +0000 Subject: Books for the NOC guys... In-Reply-To: <86wrwqukcm.fsf@seastrom.com> References: <86wrwqukcm.fsf@seastrom.com> Message-ID: <6BCFC63D-88D6-4FA1-BBB1-E51C4E04EDFA@arbor.net> On Apr 2, 2010, at 7:09 PM, Robert E. Seastrom wrote: > So, what are you having your up-and-coming NOC staff read? ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From wavetossed at googlemail.com Fri Apr 2 07:48:48 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Fri, 2 Apr 2010 13:48:48 +0100 Subject: Books for the NOC guys... In-Reply-To: <86wrwqukcm.fsf@seastrom.com> References: <86wrwqukcm.fsf@seastrom.com> Message-ID: > So, what are you having your up-and-coming NOC staff read? In an attempt to wean them off of unmanageable PERL scripts There are tons of tutorials and articles on the web, often with links to other useful stuff And let's not forget all of the NANOG presentations. Sometimes the slides are quite good on their own but if not, the audio is there too. I would encourage them to download PDFs, videos and websites for future reference and to share with colleagues. Also, set up a wiki, and ask them all to record any useful bits of info there and to track Recent Changes every week or so to see what colleagues are sharing. --Michael Dillon From mailinglists at expresswebsystems.com Fri Apr 2 08:02:37 2010 From: mailinglists at expresswebsystems.com (Express Web Systems) Date: Fri, 2 Apr 2010 08:02:37 -0500 Subject: Books for the NOC guys... In-Reply-To: <86wrwqukcm.fsf@seastrom.com> References: <86wrwqukcm.fsf@seastrom.com> Message-ID: <00fc01cad264$c578a0a0$5069e1e0$@com> > So, what are you having your up-and-coming NOC staff read? While not specifically a NOC book, we find that it lays a great foundation to build from (if, perhaps, a bit basic in certain areas): Network Warrior by Gary A. Donahue http://www.amazon.com/Network-Warrior-Everything-need-wasnt/dp/0596101511/ This is a great book with an easy to read style. Tom Walsh From jtk at cymru.com Fri Apr 2 08:37:13 2010 From: jtk at cymru.com (John Kristoff) Date: Fri, 2 Apr 2010 08:37:13 -0500 Subject: Books for the NOC guys... In-Reply-To: <86wrwqukcm.fsf@seastrom.com> References: <86wrwqukcm.fsf@seastrom.com> Message-ID: <20100402083713.268a3973@t61p> On Fri, 02 Apr 2010 08:09:29 -0400 "Robert E. Seastrom" wrote: > This morning I went digging for a book to recommend that someone in > our NOC read in order to understand at a high level how Internet > infrastructure works (bgp, igps, etc) and discovered that the old > standbys (Huitema, Halabi, Perlman) have all not been updated in a > decade or so. [...] > So, what are you having your up-and-coming NOC staff read? That is an excellent question Rob. I still recommend and prefer to use Radia's book when I teach networking classes. There are lots of books that regurgitate the specs or spend a fair amount of time on the core algorithms and mechanisms, but few go into the "why" and "what if" like she does that makes it so exceptional and particularly relevant from an operations perspective. I often will play a clip or two from past meetings like NANOG and discuss that in class to make up for the lack of reference and discussion material elsewhere. Perhaps point them at a few of your favorite presentations on a particular operationally relevant topic you want them to know more about? John From Valdis.Kletnieks at vt.edu Fri Apr 2 08:39:42 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 02 Apr 2010 09:39:42 -0400 Subject: Books for the NOC guys... In-Reply-To: Your message of "Fri, 02 Apr 2010 13:48:48 BST." References: <86wrwqukcm.fsf@seastrom.com> Message-ID: <28028.1270215582@localhost> On Fri, 02 Apr 2010 13:48:48 BST, Michael Dillon said: > > So, what are you having your up-and-coming NOC staff read? > > In an attempt to wean them off of unmanageable PERL scripts There is not, and there never will be, a useful programming language that makes it the least bit difficult to write totally abominable creeping-horror unmaintainable code in. The ability of a programmer to write totally obtuse code is entirely orthogonal to the choice of implementation language. Some people just don't have good taste, and will produce train wrecks in any language. Remember that it's possible to write Fortran-IV code in any language. :) Unless you teach them stuff like "Document the sources and expected types of input data", "add useful comments that explain your choice of algorithms rather than "a++; /* Add one to A */", and "If the language supports operator overloading, don't be a bozo and abuse it", the code will be unmaintainable. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From LarrySheldon at cox.net Fri Apr 2 08:46:22 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 02 Apr 2010 08:46:22 -0500 Subject: Books for the NOC guys... In-Reply-To: <28028.1270215582@localhost> References: <86wrwqukcm.fsf@seastrom.com> <28028.1270215582@localhost> Message-ID: <4BB5F52E.3010001@cox.net> On 4/2/2010 08:39, Valdis.Kletnieks at vt.edu wrote: > On Fri, 02 Apr 2010 13:48:48 BST, Michael Dillon said: >>> So, what are you having your up-and-coming NOC staff read? >> >> In an attempt to wean them off of unmanageable PERL scripts > > There is not, and there never will be, a useful programming language that > makes it the least bit difficult to write totally abominable creeping-horror > unmaintainable code in. > > The ability of a programmer to write totally obtuse code is entirely > orthogonal to the choice of implementation language. Some people just don't > have good taste, and will produce train wrecks in any language. Remember that > it's possible to write Fortran-IV code in any language. :) > > Unless you teach them stuff like "Document the sources and expected types of > input data", "add useful comments that explain your choice of algorithms rather > than "a++; /* Add one to A */", and "If the language supports operator > overloading, don't be a bozo and abuse it", the code will be unmaintainable. "Teach them". Train them. Have standards. Enforce them (pay according to compliance). What a concept! We did that using Autocoder and COBOL. What next? "Manage" them? Is that even legal? -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From scott at sberkman.net Fri Apr 2 08:50:38 2010 From: scott at sberkman.net (Scott Berkman) Date: Fri, 2 Apr 2010 09:50:38 -0400 Subject: Books for the NOC guys... In-Reply-To: <4BB5F52E.3010001@cox.net> References: <86wrwqukcm.fsf@seastrom.com> <28028.1270215582@localhost> <4BB5F52E.3010001@cox.net> Message-ID: <01ad01cad26b$7aa110b0$6fe33210$@net> I just show them this: http://warriorsofthe.net/ -Scott -----Original Message----- From: Larry Sheldon [mailto:LarrySheldon at cox.net] Sent: Friday, April 02, 2010 9:46 AM To: nanog at nanog.org Subject: Re: Books for the NOC guys... On 4/2/2010 08:39, Valdis.Kletnieks at vt.edu wrote: > On Fri, 02 Apr 2010 13:48:48 BST, Michael Dillon said: >>> So, what are you having your up-and-coming NOC staff read? >> >> In an attempt to wean them off of unmanageable PERL scripts > > There is not, and there never will be, a useful programming language that > makes it the least bit difficult to write totally abominable creeping-horror > unmaintainable code in. > > The ability of a programmer to write totally obtuse code is entirely > orthogonal to the choice of implementation language. Some people just don't > have good taste, and will produce train wrecks in any language. Remember that > it's possible to write Fortran-IV code in any language. :) > > Unless you teach them stuff like "Document the sources and expected types of > input data", "add useful comments that explain your choice of algorithms rather > than "a++; /* Add one to A */", and "If the language supports operator > overloading, don't be a bozo and abuse it", the code will be unmaintainable. "Teach them". Train them. Have standards. Enforce them (pay according to compliance). What a concept! We did that using Autocoder and COBOL. What next? "Manage" them? Is that even legal? -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From bdfleming at kanren.net Fri Apr 2 09:01:09 2010 From: bdfleming at kanren.net (Brad Fleming) Date: Fri, 2 Apr 2010 09:01:09 -0500 Subject: Books for the NOC guys... In-Reply-To: <86wrwqukcm.fsf@seastrom.com> References: <86wrwqukcm.fsf@seastrom.com> Message-ID: <140377EB-4E17-499A-BB11-BA195CE730AA@kanren.net> On Apr 2, 2010, at 7:09 AM, Robert E. Seastrom wrote: > > This morning I went digging for a book to recommend that someone in > our NOC read in order to understand at a high level how Internet > infrastructure works (bgp, igps, etc) and discovered that the old > standbys (Huitema, Halabi, Perlman) have all not been updated in a > decade or so. > > On the one hand, they're all still quite relevant since there hasn't > been anything really earth-shattering in that department, but they are > all going to be lean to nonexistent on stuff like IPv6 and NLRI > negotiation. > > So, what are you having your up-and-coming NOC staff read? > > Thanks, > > -r > It kind of depends on what you want from your NOC folk and (at least a little bit) which "level" NOC people need the resource. In addition to the ones already listed, we encourage Tier 1 and Tier 2 people to read and understand these two books: T1: A Survival Guide http://www.amazon.com/T1-Survival-Guide-Matthew-Gast/dp/0596001274/ref=sr_1_1?ie=UTF8&s=books&qid=1270216284&sr=8-1 Network Maintenance and Troubleshooting Guide http://www.amazon.com/Network-Maintenance-Troubleshooting-Guide-Solutions/dp/0321647416/ref=sr_1_1?ie=UTF8&s=books&qid=1270216655&sr=1-1 We find these are both pretty solid resources, especially for our Tier 1 folks. Since much of what they eventually deal with are Layer 1 problems, having resources that focus on Layer 1 helps get their mind moving that direction. If we have a routing problem, that generally needs to get bumped up anyway since it means somethings misconfigured or a routing protocol is acting up. -- Brad Fleming From jimi.thompson at gmail.com Fri Apr 2 09:20:05 2010 From: jimi.thompson at gmail.com (Jimi Thompson) Date: Fri, 02 Apr 2010 09:20:05 -0500 Subject: Finding content in your job title In-Reply-To: Message-ID: On 3/31/10 8:14 PM, "Jorge Amodio" wrote: >> I agree with the misuse of the term "Engineer" in IT. I think it should only >> be used for the "official" protected title of civil engineer. Which I >> believe is a very respectable job. Sad but true, in IT too many people have >> some form of engineer in their job title but are almost totally clueless. > > [ X-Operational_Content = 0 ] > > Can't resist. > > When I read your message it brought back to my memory a nice guy that > used to work for me eons ago, very clever, smart and hands-on, he had > a Bachelor's Degree in Psychology. > > One day, we had some sort of outage and I found him in the "computer > room" sitting in front of one of the racks with some routing gear, I > still have that image in my memory he looked like he was doing some > sort of group therapy with the routers, I couldn't resist and told him > "Hey Joey, Freud won't help you, get your butt off of the chair and > follow the default procedure, power cycle the damn beast". > > There were also several folks with various degrees in Physics, experts > on blowing up stuff. > > Again, IMHO, in this field a title may help or may provide others a > relative idea where you fit in a large organization, or help the HR > folks know how much to put on your paycheck or what kind of > benefits/perks go associated with that level, but I still believe that > substance is more important. > > Regards > Jorge > COOK > Chief Old Operations Knucklehead > HAH! My self chosen job title is Chief Pest, Annoyer of Developers, and Destroyer of Misconceptions. All in all, it's fairly accurate. Among other things I manage a team of developers, I often have to disabuse management of some silly idea or other, and frequently have to play gladfly to enable change. From lowen at pari.edu Fri Apr 2 09:29:10 2010 From: lowen at pari.edu (Lamar Owen) Date: Fri, 2 Apr 2010 10:29:10 -0400 Subject: Raised floor, Solid floor... or carpet? In-Reply-To: References: Message-ID: <201004021029.10766.lowen@pari.edu> On Thursday 01 April 2010 02:36:56 pm telmnstr at 757.org wrote: > > Its an april fools joke for them. Dare I say that I have actually seen > > DCs with carpeting. My jaw dropped but it does exist. > We had carpeted floor tiles in a data center where I used to work. It was > bound to the raised floor panels, and I was told it had anti static > properties. Never noticed a static issue, but the room had proper air > handlers with humidity control. We here at PARI have 30,000 square feet of carpeted raised floor. 18,000 square feet of that is two levels of one whole wing of one of the main buildings, with recessed subfloors so there are no ramps or steps; the transition from normal to raised is seamless. A large portion of the other 12,000 square feet is, pardon the usage, 'puke yellow' in color. The 18,000 sq feet is a nice gray color. All have static draining foil and/or wires woven in the carpet for static control. Thankfully no zinc whiskers on any of ours. (I'm posting this on April 2 specifically so that statement won't be misunderstood). > The puller to lift floor tiles had evil teeth, not suction cups. It could > bite. Again, I'm posting this on April 2 specifically so that this won't be taken as a joke, but, PARI being in the sticks, so to speak, that is, right in the middle of the Pisgah National Forest, I've often carried a puller with me outside when going to the pickup at night, along with my flashlight (we're an observatory; there are no outside lights on at night). We have seen bobcats, coyotes, eastern cougars (rare, but around), black bears, and wild hogs; rumor has it that there are wolves within 50 miles. I've often thought one of the pullers would be a fantastic close quarters defensive non-fatal weapon.....but haven't had to use one yet. I have, however, had a puller slip and get my knee before.... From lists at quux.de Fri Apr 2 10:10:41 2010 From: lists at quux.de (Jens Link) Date: Fri, 02 Apr 2010 17:10:41 +0200 Subject: Books for the NOC guys... In-Reply-To: <86wrwqukcm.fsf@seastrom.com> (Robert E. Seastrom's message of "Fri\, 02 Apr 2010 08\:09\:29 -0400") References: <86wrwqukcm.fsf@seastrom.com> Message-ID: <87sk7dnb4e.fsf@bowmore.quux.de> "Robert E. Seastrom" writes: > So, what are you having your up-and-coming NOC staff read? I think it's quite good and covers many "modern" topics. One drawback: It mentions ethereal and not wireshark. At the time of writing ethereal must have been dead for about 2 years. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From lear at cisco.com Fri Apr 2 10:36:53 2010 From: lear at cisco.com (Eliot Lear) Date: Fri, 02 Apr 2010 17:36:53 +0200 Subject: Books for the NOC guys... In-Reply-To: <86wrwqukcm.fsf@seastrom.com> References: <86wrwqukcm.fsf@seastrom.com> Message-ID: <4BB60F15.10504@cisco.com> On 4/2/10 2:09 PM, Robert E. Seastrom wrote: > So, what are you having your up-and-coming NOC staff read? Practice of System and Network Administration by Limoncelli, Hogan, and Challup. I may be biased, being married to Hogan. Eliot From lowen at pari.edu Fri Apr 2 10:51:08 2010 From: lowen at pari.edu (Lamar Owen) Date: Fri, 2 Apr 2010 11:51:08 -0400 Subject: Raised floor, Solid floor... or carpet? In-Reply-To: <201004021029.10766.lowen@pari.edu> References: Message-ID: <201004021151.08941.lowen@pari.edu> On Friday 02 April 2010 10:29:10 am Lamar Owen wrote: > A large portion of the other 12,000 square feet is, pardon the usage, 'puke > yellow' in color. The 18,000 sq feet is a nice gray color. All have > static draining foil and/or wires woven in the carpet for static control. A couple of pictures (links are each on one line): http://www.pari.edu/about_pari/pari-photos/archived-photos/volunteers/friends- of-pari-volunteer-weekend-march-28-2009/IMG_5156.JPG/view http://www.pari.edu/about_pari/pari-photos/archived-photos/volunteers/friends- of-pari-volunteer-weekend-march-28-2009/IMG_5153.JPG/view These were taken last year on the day a group of volunteers helped pull 60+ shielded Cat6 ethernet drops from the data center to the multimedia room; this was done to reduce RFI to the radio telescopes. From ops.lists at gmail.com Fri Apr 2 10:52:23 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 2 Apr 2010 21:22:23 +0530 Subject: Books for the NOC guys... In-Reply-To: <4BB60F15.10504@cisco.com> References: <86wrwqukcm.fsf@seastrom.com> <4BB60F15.10504@cisco.com> Message-ID: The Limoncelli etc book is brilliant. There's phil smith and barry greene's old "Cisco ISP Essentials" too. Very good if somewhat outdated And then there's this if you just want security - http://www.amazon.com/Router-Security-Strategies-Securing-Network/dp/1587053365/ref=sr_1_1?ie=UTF8&s=books&qid=1270223489&sr=1-1 On Fri, Apr 2, 2010 at 9:06 PM, Eliot Lear wrote: > ?On 4/2/10 2:09 PM, Robert E. Seastrom wrote: >> >> So, what are you having your up-and-coming NOC staff read? > > Practice of System and Network Administration by Limoncelli, Hogan, and > Challup. ?I may be biased, being married to Hogan. -- Suresh Ramasubramanian (ops.lists at gmail.com) From owen at delong.com Thu Apr 1 18:20:15 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Apr 2010 16:20:15 -0700 Subject: New Linksys CPE, IPv6 ? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6BEF@RWC-EX1.corp.seven.com> References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org><4BB3B651.1020607@csuohio.edu><4BB3E363.6000708@foobar.org> <5A6D953473350C4B9995546AFE9939EE08FE6BEF@RWC-EX1.corp.seven.com> Message-ID: <86E0C9B1-2538-449A-B2C9-5303EA8CA683@delong.com> On Apr 1, 2010, at 2:25 PM, George Bonser wrote: > > > >> I beg to differ. I know several ISPs that have been quietly putting >> quite >> a bit of engineering resource behind IPv6. The public announcement >> of residential IPv6 trials by Comcast was not the beginning of a >> serious >> commitment to IPv6 by Comcast, but, rather more towards the middle. >> Comcast has had substantial engineering resources on IPv6 for >> several years now. > > None of my transit providers currently offer native ipv6 where we are > located. One recent vendor said they could tunnel 6 over 4 but any > network address blocks assigned to that network would change at some > point in the future. In other words, we could do v6 over 4 now but we > would have to renumber later. > You can get a permanent IPv6 address from the tunnel brokers at Hurricane or SIXXS. You can get an IPv6 PI Block from an RIR and route that via BGP over an HE tunnel. (Some people get upset when I say this and don't mention I work for HE. I work for HE because I think the above free services are cool and I like what they're doing with IPv6.) > What I heard at a recent (within the past six months) conference was > that "there is no customer demand for v6" so it isn't on the immediate > needs list. He said they had a lot of inquiries about v6, but to date > not having native v6 wasn't a deal breaker with anyone. > I watched a vendor at one conference tell 20 people in a row that each one of them was the only one asking for IPv6. I mentioned to him that he should have his short-term memory loss checked out by a physician. At first he was confused. When I pointed out what I had just seen him do, he went from confused to embarrassed and admitted that it was the party line from his marketing department and they knew IPv6 was important, but, didn't have a story to tell yet, so, they were trying to spin for delay. > So my instincts tell me that until not being native v6 capable IS a deal > breaker with potential clients, it isn't really going to go on the front > burner. Many companies operate on the "it isn't a problem until it is a > problem" model. > It _IS_ a deal breaker for some potential clients. It _WILL_ be a deal breaker for an increasingly large number of clients over the next couple of years. I suspect that it will be less than 2 years before you see every client insisting that they need IPv6 capability RIGHT NOW. Owen From sparctacus at gmail.com Fri Apr 2 11:07:41 2010 From: sparctacus at gmail.com (Bryan Irvine) Date: Fri, 2 Apr 2010 09:07:41 -0700 Subject: Books for the NOC guys... In-Reply-To: <00fc01cad264$c578a0a0$5069e1e0$@com> References: <86wrwqukcm.fsf@seastrom.com> <00fc01cad264$c578a0a0$5069e1e0$@com> Message-ID: On Fri, Apr 2, 2010 at 6:02 AM, Express Web Systems wrote: >> So, what are you having your up-and-coming NOC staff read? > > While not specifically a NOC book, we find that it lays a great foundation > to build from (if, perhaps, a bit basic in certain areas): > > Network Warrior by Gary A. Donahue > > http://www.amazon.com/Network-Warrior-Everything-need-wasnt/dp/0596101511/ > > This is a great book with an easy to read style. > +1 Network Warrior. -B From drc at virtualized.org Fri Apr 2 11:16:10 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 2 Apr 2010 06:16:10 -1000 Subject: Note change in IANA registry URLs In-Reply-To: <4BB5BC01.1080005@ripe.net> References: <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> <4BB4109E.90006@zill.net> <20100401032232.GB5032@dan.olp.net> <4BB5BC01.1080005@ripe.net> Message-ID: <0D22ABE6-40A7-4616-A58D-D6AC7D3171CA@virtualized.org> On Apr 1, 2010, at 11:42 PM, Robert Kisteleki wrote: > I don't know what good reasons you might have to pull down the current URLs. Because the content has changed from arbitrary ASCII text files into more easily parseable XML and backporting to those arbitrary ASCII text files has proven too error prone and labor intensive. Regards, -drc From jhorstman at adknowledge.com Fri Apr 2 11:25:12 2010 From: jhorstman at adknowledge.com (Justin Horstman) Date: Fri, 2 Apr 2010 11:25:12 -0500 Subject: Finding content in your job title In-Reply-To: References: Message-ID: -----Original Message----- From: Jimi Thompson [mailto:jimi.thompson at gmail.com] Sent: Friday, April 02, 2010 9:20 AM To: Jorge Amodio; Jeroen van Aart Cc: nanog at nanog.org Subject: Re: Finding content in your job title On 3/31/10 8:14 PM, "Jorge Amodio" wrote: >> I agree with the misuse of the term "Engineer" in IT. I think it >> should only be used for the "official" protected title of civil >> engineer. Which I believe is a very respectable job. Sad but true, in >> IT too many people have some form of engineer in their job title but are almost totally clueless. > > [ X-Operational_Content = 0 ] > > Can't resist. > > When I read your message it brought back to my memory a nice guy that > used to work for me eons ago, very clever, smart and hands-on, he had > a Bachelor's Degree in Psychology. > > One day, we had some sort of outage and I found him in the "computer > room" sitting in front of one of the racks with some routing gear, I > still have that image in my memory he looked like he was doing some > sort of group therapy with the routers, I couldn't resist and told him > "Hey Joey, Freud won't help you, get your butt off of the chair and > follow the default procedure, power cycle the damn beast". > > There were also several folks with various degrees in Physics, experts > on blowing up stuff. > > Again, IMHO, in this field a title may help or may provide others a > relative idea where you fit in a large organization, or help the HR > folks know how much to put on your paycheck or what kind of > benefits/perks go associated with that level, but I still believe that > substance is more important. > > Regards > Jorge > COOK > Chief Old Operations Knucklehead > >HAH! My self chosen job title is Chief Pest, Annoyer of Developers, and Destroyer of Misconceptions. All in all, it's fairly accurate. Among other things I manage a team of developers, I often have to disabuse management of some silly idea or other, and > frequently have to play gladfly to enable change. When I call a company and ask for an accountant, I get the companies accountant, when I ask for an account manager, that's what I get. That's what titles are, and that's why they are important. I know the type of person I need to talk to, but I don't know who it is I need to talk to. Its why standardization in titles is good, when I go digging through my pile of business cards looking for the Network Engineer/Architect at company X, I'll probably not notice a custom/weird title. It does not define you, it does not make you any less or more important, it does however answer the question of "Who is responsible for..." which I believe to be extremely valuable. Then again, I might be weird. ~J From leo.vegoda at icann.org Fri Apr 2 12:10:34 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 2 Apr 2010 10:10:34 -0700 Subject: Note change in IANA registry URLs In-Reply-To: <20100402095317.GA23768@nic.fr> References: <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> <4BB4109E.90006@zill.net> <20100401032232.GB5032@dan.olp.net> <4BB5BC01.1080005@ripe.net> <20100402095317.GA23768@nic.fr> Message-ID: On 2 Apr 2010, at 2:53, Stephane Bortzmeyer wrote: On Fri, Apr 02, 2010 at 11:42:25AM +0200, > Robert Kisteleki wrote > a message of 20 lines which said: > >> I don't know what good reasons you might have to pull down the current >> URLs. Please keep them working. > > I strongly agree and, by the way, it seems this was partially > mentioned in the original announcement: > >> The old URLs will contain information for the location of the new >> versions available (TXT, XML and XHTML). Yes, I was not as clear as I should have been. The URLs will continue to exist but the current content will go away and be replaced with a short file explaining where to find it. Regards, Leo From robert at ripe.net Fri Apr 2 12:13:59 2010 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 02 Apr 2010 19:13:59 +0200 Subject: Note change in IANA registry URLs In-Reply-To: <0D22ABE6-40A7-4616-A58D-D6AC7D3171CA@virtualized.org> References: <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> <4BB4109E.90006@zill.net> <20100401032232.GB5032@dan.olp.net> <4BB5BC01.1080005@ripe.net> <0D22ABE6-40A7-4616-A58D-D6AC7D3171CA@virtualized.org> Message-ID: <4BB625D7.2060901@ripe.net> On 2010.04.02. 18:16, David Conrad wrote: > On Apr 1, 2010, at 11:42 PM, Robert Kisteleki wrote: >> I don't know what good reasons you might have to pull down the current >> URLs. > > Because the content has changed from arbitrary ASCII text files into more > easily parseable XML and backporting to those arbitrary ASCII text files > has proven too error prone and labor intensive. > > Regards, -drc You're confusing two things: URL and content. According to the announcement, TXT files will be generated still. Why, again, must the URL change? Robert From lowen at pari.edu Fri Apr 2 12:13:30 2010 From: lowen at pari.edu (Lamar Owen) Date: Fri, 2 Apr 2010 13:13:30 -0400 Subject: Finding content in your job title In-Reply-To: References: Message-ID: <201004021313.31080.lowen@pari.edu> On Friday 02 April 2010 12:25:12 pm Justin Horstman wrote: > [Your title] does > however answer the question of "Who is responsible for..." which I believe > to be extremely valuable. > Then again, I might be weird. No, this is exactly how 'business at large' uses the idea of title. In some companies, Official Title is used to determine salary (or even whether you're an exempt employee or not). And the company's bylaws may invest particular responsibilities and privileges on particular people by title. Secretary, for instance, is a particular title used in bylaws for a particular purpose for an officer of the company. When troubleshooting an operational issue, which do you prefer: traceroutes with useful interface names (so you can locate them) or cutesy names? Would you prefer (for your eyes, of course; you do run split DNS, right?) POS1/0 on a 7206 used for PE in the data center be called pos1-0.dc1-7206- pe.example.com, or bhp.example.com (BHP=Big Honking Pipe)? I know, you might prefer bhp.example.com for other people's eyes, but suppose you didn't name it that, you're new on the job, the guy who named it is not available, and you are having problems. Then which is your preference? I guess what you want your title to be depends on what your role actually is in the company, and whether someone outside (or someone inside who doesn't know you) can find you when they need to using the company's directory or a second or third-hand business card (yes, I've done that too, make a photocopy or e-copy of a business card, and then pass it along to a third-party (after getting card holder's permission to do so) as a contact). Or when putting a card under the acrylic sheeting on the tables in a local restaurant (I've actually made useful connections reading the business cards on corkboards and under the Plexiglas at restaurants before). We have standardized abuse, postmaster, and webmaster e-mail aliases, too, and that works when you see a slow brute-forcer originating from somewhere, or someone has blackholed someone and their BGP announcements leak, or whatever. It's nice to get to the right person when you don't know the person, don't know the company, and don't have time to get 'into' the culture. So, I guess that your title should at least semi-adequately give your role to someone who is completely clueless about your role. From lowen at pari.edu Fri Apr 2 12:30:55 2010 From: lowen at pari.edu (Lamar Owen) Date: Fri, 2 Apr 2010 13:30:55 -0400 Subject: Books for the NOC guys... In-Reply-To: <4BB60F15.10504@cisco.com> References: <86wrwqukcm.fsf@seastrom.com> Message-ID: <201004021330.55184.lowen@pari.edu> On Friday 02 April 2010 11:36:53 am Eliot Lear wrote: > Practice of System and Network Administration by Limoncelli, Hogan, and > Challup. I may be biased, being married to Hogan. +1 on PSNA. I like it as much for its non-technical content as for its technical content (a similar book, by Limncelli, "Time Management for System Administrators" is also on my shelf, with great non-technical content, and should be a must-read for any technical personnel, IMO). +1 also on Network Warrior, although not for everything. I also have 'Cisco Network Professional's Advanced Internetworking Guide' by Patrick J. Conlan, published by Sybex. Comes with the full text on CD in PDF form, too. The URL is pretty long, so use the search on sybex.com to find it. Here's the ToC: 1. Enterprise Network Design. 2. Switching. 3. Spanning Tree Protocol (STP). 4. Routing Concepts and Distance Vector Routing Protocols. 5. Advanced Distance Vector Protocols. 6. Link State Routing Protocols. 7. Exterior Routing Protocols. 8. Multicast. 9. IP Version 6. 10. Redundancy Protocols. 11. WAN and Teleworker Connections. 12. Virtual Private Networks (VPN). 13. Device Security. 14. Switch Security. 15. Cisco IOS Firewall. 16. Cisco IOS IPS. 17. Voice. 18. DiffServ Quality of Service (QOS). 19. Wireless Devices and Topologies. 20. Wireless Management and Security. Which pretty much, I think, covers the bases asked about in the OP. The copyright is May 2009, so it's not too bad out of date. From nick at foobar.org Fri Apr 2 12:43:29 2010 From: nick at foobar.org (Nick Hilliard) Date: Fri, 02 Apr 2010 18:43:29 +0100 Subject: Books for the NOC guys... In-Reply-To: <28028.1270215582@localhost> References: <86wrwqukcm.fsf@seastrom.com> <28028.1270215582@localhost> Message-ID: <4BB62CC1.3010204@foobar.org> On 02/04/2010 14:39, Valdis.Kletnieks at vt.edu wrote: > On Fri, 02 Apr 2010 13:48:48 BST, Michael Dillon said: >>> So, what are you having your up-and-coming NOC staff read? >> >> In an attempt to wean them off of unmanageable PERL scripts > > There is not, and there never will be, a useful programming language that > makes it the least bit difficult to write totally abominable creeping-horror > unmaintainable code in. +n "Whatever language you write in, your task as a programmer is to do the best you can with the tools at hand. A good programmer can overcome a poor language or a clumsy operating system, but even a great programming environment will not rescue a bad programmer". (Kernighan and Pike) Although language zealots are loth to admit it, certain languages are better suited to some things than to others. Perl's syntactical support for text processing are second to none, but for web stuff, it's hideous. PHP stinks on the command line and text processing, yet its web integration makes it a good candidate for small web projects. Shell scripts are designed specifically for command line tool management, pipes and all that sort of thing, and just because other languages support popen() and system, that doesn't necessarily make them good choices for stuff which involves unix scripting. I write readable and maintainable code in all three. Java elicits strong reactions. No doubt, you can use Java plumbing libraries to scale to impressively large systems. On the other hand, Cisco Configuration Professional (the new SDM) provides an excellent example of how badly you can screw up a good idea by using the wrong tool - I'm not interesting in using or recommending a desktop tool which takes 2 minutes to start on a fast computer. You can write unimaginably awful code in python and ruby, and irrtoolset's code is a prime example of what you can do with c++. Yet, we all acknowledge that python, ruby and c++ are high quality languages. In short: less zealotry, more pragmatism and a realisation that each language has its own strengths and weaknesses. Bad code is bad code in any language. Nick From bill at herrin.us Fri Apr 2 12:44:27 2010 From: bill at herrin.us (William Herrin) Date: Fri, 2 Apr 2010 13:44:27 -0400 Subject: Important: IPv4 Future Allocation Concept RFC In-Reply-To: <201004012241.o31MfZVk020791@aurora.sol.net> References: <201004012241.o31MfZVk020791@aurora.sol.net> Message-ID: On Thu, Apr 1, 2010 at 6:41 PM, Joe Greco wrote: > Someone suggested this be posted more visibly. Joe, Been there, done that: http://bill.herrin.us/network/ipxl.html Maybe the humor was too subtle... -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mike at mtcc.com Fri Apr 2 12:47:52 2010 From: mike at mtcc.com (Michael Thomas) Date: Fri, 02 Apr 2010 10:47:52 -0700 Subject: Books for the NOC guys... In-Reply-To: <4BB62CC1.3010204@foobar.org> References: <86wrwqukcm.fsf@seastrom.com> <28028.1270215582@localhost> <4BB62CC1.3010204@foobar.org> Message-ID: <4BB62DC8.4030400@mtcc.com> On 04/02/2010 10:43 AM, Nick Hilliard wrote: > > In short: less zealotry, more pragmatism and a realisation that each > language has its own strengths and weaknesses. Bad code is bad code in any > language. All true, but I'd still say there's a special rung in hell for bad perl. Mike From cmadams at hiwaay.net Fri Apr 2 12:53:44 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 2 Apr 2010 12:53:44 -0500 Subject: Books for the NOC guys... In-Reply-To: <4BB62DC8.4030400@mtcc.com> References: <86wrwqukcm.fsf@seastrom.com> <28028.1270215582@localhost> <4BB62CC1.3010204@foobar.org> <4BB62DC8.4030400@mtcc.com> Message-ID: <20100402175344.GC1510190@hiwaay.net> Once upon a time, Michael Thomas said: > All true, but I'd still say there's a special rung in hell for bad perl. Ehh, bad perl is still more readable than good APL. At least I can reformat the perl! :-) -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From hcb at netcases.net Fri Apr 2 13:00:50 2010 From: hcb at netcases.net (Howard C. Berkowitz) Date: Fri, 2 Apr 2010 14:00:50 -0400 Subject: Books for the NOC guys... In-Reply-To: <86wrwqukcm.fsf@seastrom.com> References: <86wrwqukcm.fsf@seastrom.com> Message-ID: <000001cad28e$7020d7b0$6601a8c0@HDESK1> Well, speaking as one who wrote an ISP-specific, although not NOC-specific book about a decade ago, it doesn't seem as if there is a commercial motivation to update them. For the record, it's _Building Service Provider Networks_ (Wiley, 2001), and I'm proud of it. Nevertheless, I'm not opposed to trying to create updated open-source guidance. I do a good deal of work with http://en.citizendium.org, a real-name Wiki that is trying to reach critical mass. Anybody interested in collaborating? I'd actually started more on RPSL and peering than first-tier ops, but hadn't done anything more for lack of activity there. Certainly, I could port some of my NANOG tutorials, not that I have the PPT for many but just the PDF. > -----Original Message----- > From: Robert E. Seastrom [mailto:rs at seastrom.com] > Sent: Friday, April 02, 2010 8:09 AM > To: nanog at nanog.org > Subject: Books for the NOC guys... > > > This morning I went digging for a book to recommend that someone in > our NOC read in order to understand at a high level how Internet > infrastructure works (bgp, igps, etc) and discovered that the old > standbys (Huitema, Halabi, Perlman) have all not been updated in a > decade or so. > > On the one hand, they're all still quite relevant since there hasn't > been anything really earth-shattering in that department, but they are > all going to be lean to nonexistent on stuff like IPv6 and NLRI negotiation. > > So, what are you having your up-and-coming NOC staff read? > > Thanks, > > -r > From sparctacus at gmail.com Fri Apr 2 13:02:53 2010 From: sparctacus at gmail.com (Bryan Irvine) Date: Fri, 2 Apr 2010 11:02:53 -0700 Subject: Books for the NOC guys... In-Reply-To: <20100402175344.GC1510190@hiwaay.net> References: <86wrwqukcm.fsf@seastrom.com> <28028.1270215582@localhost> <4BB62CC1.3010204@foobar.org> <4BB62DC8.4030400@mtcc.com> <20100402175344.GC1510190@hiwaay.net> Message-ID: On Fri, Apr 2, 2010 at 10:53 AM, Chris Adams wrote: > Once upon a time, Michael Thomas said: >> All true, but I'd still say there's a special rung in hell for bad perl. > > Ehh, bad perl is still more readable than good APL. ?At least I can > reformat the perl! :-) In my experience bad perl usually consists of using system() a lot to run shell commands and read the input. Creative well-written perl, now there's something unreadable and unmaintainable! :-) -B From ray.sanders at villagevoicemedia.com Fri Apr 2 13:21:28 2010 From: ray.sanders at villagevoicemedia.com (Ray Sanders) Date: Fri, 02 Apr 2010 11:21:28 -0700 Subject: Books for the NOC guys... In-Reply-To: <4BB62DC8.4030400@mtcc.com> References: <86wrwqukcm.fsf@seastrom.com> <28028.1270215582@localhost> <4BB62CC1.3010204@foobar.org> <4BB62DC8.4030400@mtcc.com> Message-ID: <4BB635A8.3030009@villagevoicemedia.com> It's the same level reserved for child molesters and people who talk at the theater... Michael Thomas wrote: > On 04/02/2010 10:43 AM, Nick Hilliard wrote: >> >> In short: less zealotry, more pragmatism and a realisation that each >> language has its own strengths and weaknesses. Bad code is bad code >> in any >> language. > > All true, but I'd still say there's a special rung in hell for bad perl. > > Mike > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.800 / Virus Database: 271.1.1/2785 - Release Date: 04/01/10 23:32:00 > > -- -"Prediction is very difficult, especially about the future." -Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 From netfortius at gmail.com Fri Apr 2 13:43:56 2010 From: netfortius at gmail.com (Stefan) Date: Fri, 2 Apr 2010 14:43:56 -0400 Subject: Books for the NOC guys... In-Reply-To: <00fc01cad264$c578a0a0$5069e1e0$@com> References: <86wrwqukcm.fsf@seastrom.com> <00fc01cad264$c578a0a0$5069e1e0$@com> Message-ID: Aside from the ones already mentioned, troubleshooting books are a great asset, also. Here are some of my favorites: http://www.amazon.com/Network-Analysis-Troubleshooting-Scott-Haugdahl/dp/0201433192/ http://www.amazon.com/Troubleshooting-Campus-Networks-Practical-Protocols/dp/0471210137/ http://www.amazon.com/Network-Maintenance-Troubleshooting-Guide-Solutions/dp/0321647416/ <- just ordered the 2nd edition, after having browsed it at a friend ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius On Fri, Apr 2, 2010 at 9:02 AM, Express Web Systems wrote: >> So, what are you having your up-and-coming NOC staff read? > > While not specifically a NOC book, we find that it lays a great foundation > to build from (if, perhaps, a bit basic in certain areas): > > Network Warrior by Gary A. Donahue > > http://www.amazon.com/Network-Warrior-Everything-need-wasnt/dp/0596101511/ > > This is a great book with an easy to read style. > > Tom Walsh > > > From joelja at bogus.com Fri Apr 2 13:53:53 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 02 Apr 2010 11:53:53 -0700 Subject: Books for the NOC guys... In-Reply-To: <86wrwqukcm.fsf@seastrom.com> References: <86wrwqukcm.fsf@seastrom.com> Message-ID: <4BB63D41.5010108@bogus.com> While not the stevens book, "the illustrated network" isbn 978-0-12-374541-5 was a pretty good attempt to do a modern version of the same. any book that attempts to cover all layers of the stack is going to have it's limits, but it has saved my bacon a couple of times now... The author is normally a juniper press author and as a result the examples that aren't done on freebsd or linux systems are done on junos which is either a benifit or a drawback depending on your environment. disclaimer, I did review it for content/accuracy, but wasn't compensated for doing so. joel On 04/02/2010 05:09 AM, Robert E. Seastrom wrote: > > This morning I went digging for a book to recommend that someone in > our NOC read in order to understand at a high level how Internet > infrastructure works (bgp, igps, etc) and discovered that the old > standbys (Huitema, Halabi, Perlman) have all not been updated in a > decade or so. > > On the one hand, they're all still quite relevant since there hasn't > been anything really earth-shattering in that department, but they are > all going to be lean to nonexistent on stuff like IPv6 and NLRI negotiation. > > So, what are you having your up-and-coming NOC staff read? > > Thanks, > > -r > > > From cscora at apnic.net Fri Apr 2 14:14:48 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 3 Apr 2010 05:14:48 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201004021914.o32JEmsS011764@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. 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 03 Apr, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 316610 Prefixes after maximum aggregation: 146298 Deaggregation factor: 2.16 Unique aggregates announced to Internet: 154026 Total ASes present in the Internet Routing Table: 33705 Prefixes per ASN: 9.39 Origin-only ASes present in the Internet Routing Table: 29263 Origin ASes announcing only one prefix: 14300 Transit ASes present in the Internet Routing Table: 4442 Transit-only ASes present in the Internet Routing Table: 102 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (32374) 19 Prefixes from unregistered ASNs in the Routing Table: 1001 Unregistered ASNs in the Routing Table: 155 Number of 32-bit ASNs allocated by the RIRs: 506 Prefixes from 32-bit ASNs in the Routing Table: 522 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 231 Number of addresses announced to Internet: 2193892480 Equivalent to 130 /8s, 196 /16s and 36 /24s Percentage of available address space announced: 59.2 Percentage of allocated address space announced: 65.7 Percentage of available address space allocated: 90.0 Percentage of address space in use by end-sites: 82.0 Total number of prefixes smaller than registry allocations: 151724 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 75943 Total APNIC prefixes after maximum aggregation: 26376 APNIC Deaggregation factor: 2.88 Prefixes being announced from the APNIC address blocks: 72600 Unique aggregates announced from the APNIC address blocks: 31920 APNIC Region origin ASes present in the Internet Routing Table: 3990 APNIC Prefixes per ASN: 18.20 APNIC Region origin ASes announcing only one prefix: 1098 APNIC Region transit ASes present in the Internet Routing Table: 620 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 507205440 Equivalent to 30 /8s, 59 /16s and 87 /24s Percentage of available APNIC address space announced: 79.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, 27/8, 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 132528 Total ARIN prefixes after maximum aggregation: 68590 ARIN Deaggregation factor: 1.93 Prefixes being announced from the ARIN address blocks: 105688 Unique aggregates announced from the ARIN address blocks: 40308 ARIN Region origin ASes present in the Internet Routing Table: 13615 ARIN Prefixes per ASN: 7.76 ARIN Region origin ASes announcing only one prefix: 5276 ARIN Region transit ASes present in the Internet Routing Table: 1352 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 724817568 Equivalent to 43 /8s, 51 /16s and 214 /24s Percentage of available ARIN address space announced: 61.7 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: 72685 Total RIPE prefixes after maximum aggregation: 42455 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 65723 Unique aggregates announced from the RIPE address blocks: 43244 RIPE Region origin ASes present in the Internet Routing Table: 14309 RIPE Prefixes per ASN: 4.59 RIPE Region origin ASes announcing only one prefix: 7407 RIPE Region transit ASes present in the Internet Routing Table: 2131 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 420675232 Equivalent to 25 /8s, 18 /16s and 254 /24s Percentage of available RIPE address space announced: 78.4 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, 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, 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: 28065 Total LACNIC prefixes after maximum aggregation: 6638 LACNIC Deaggregation factor: 4.23 Prefixes being announced from the LACNIC address blocks: 26411 Unique aggregates announced from the LACNIC address blocks: 13676 LACNIC Region origin ASes present in the Internet Routing Table: 1259 LACNIC Prefixes per ASN: 20.98 LACNIC Region origin ASes announcing only one prefix: 418 LACNIC Region transit ASes present in the Internet Routing Table: 218 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 24 Number of LACNIC addresses announced to Internet: 71874816 Equivalent to 4 /8s, 72 /16s and 185 /24s Percentage of available LACNIC address space announced: 71.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6641 Total AfriNIC prefixes after maximum aggregation: 1789 AfriNIC Deaggregation factor: 3.71 Prefixes being announced from the AfriNIC address blocks: 4968 Unique aggregates announced from the AfriNIC address blocks: 1497 AfriNIC Region origin ASes present in the Internet Routing Table: 353 AfriNIC Prefixes per ASN: 14.07 AfriNIC Region origin ASes announcing only one prefix: 101 AfriNIC Region transit ASes present in the Internet Routing Table: 77 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 14979584 Equivalent to 0 /8s, 228 /16s and 146 /24s Percentage of available AfriNIC address space announced: 44.6 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 1837 8405 477 Korea Telecom (KIX) 17488 1307 134 130 Hathway IP Over Cable Interne 4755 1298 289 144 TATA Communications formerly 7545 1078 200 101 TPG Internet Pty Ltd 4134 1027 20317 397 CHINANET-BACKBONE 9583 996 74 498 Sify Limited 17974 982 281 17 PT TELEKOMUNIKASI INDONESIA 18101 879 433 32 Reliance Infocom Ltd Internet 24560 874 303 168 Bharti Airtel Ltd., Telemedia 4808 843 1584 213 CNCGROUP IP network: China169 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 4052 3842 310 bellsouth.net, inc. 4323 3827 1099 398 Time Warner Telecom 1785 1751 699 132 PaeTec Communications, Inc. 7018 1568 5757 998 AT&T WorldNet Services 20115 1528 1502 657 Charter Communications 2386 1326 618 936 AT&T Data Communications Serv 3356 1228 10952 423 Level 3 Communications, LLC 6478 1179 247 163 AT&T Worldnet Services 11492 1145 222 14 Cable One 22773 1139 2604 70 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 35805 612 56 6 United Telecom of Georgia 3292 448 1899 390 TDC Tele Danmark 30890 437 100 202 Evolva Telecom 702 421 1870 333 UUNET - Commercial IP service 8551 400 355 36 Bezeq International 8866 396 117 18 Bulgarian Telecommunication C 3320 363 7072 317 Deutsche Telekom AG 3301 356 1413 317 TeliaNet Sweden 3215 347 3206 103 France Telecom Transpac 12479 330 576 5 Uni2 Autonomous System 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 1537 2908 238 UniNet S.A. de C.V. 10620 1027 229 161 TVCABLE BOGOTA 28573 899 731 84 NET Servicos de Comunicao S.A 7303 700 367 101 Telecom Argentina Stet-France 22047 541 310 15 VTR PUNTO NET S.A. 18881 522 268 11 Global Village Telecom 6503 510 168 193 AVANTEL, S.A. 7738 477 922 30 Telecomunicacoes da Bahia S.A 3816 456 195 70 Empresa Nacional de Telecomun 14117 455 30 13 Telefonica del Sur S.A. 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 890 445 10 TEDATA 24863 704 144 41 LINKdotNET AS number 36992 552 120 162 Etisalat MISR 3741 274 853 233 The Internet Solution 33776 262 14 11 Starcomms Nigeria Limited 2018 215 230 111 Tertiary Education Network 6713 177 167 12 Itissalat Al-MAGHRIB 29571 171 19 9 Ci Telecom Autonomous system 24835 138 78 11 RAYA Telecom - Egypt 29975 133 506 14 Vodacom 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 4052 3842 310 bellsouth.net, inc. 4323 3827 1099 398 Time Warner Telecom 4766 1837 8405 477 Korea Telecom (KIX) 1785 1751 699 132 PaeTec Communications, Inc. 7018 1568 5757 998 AT&T WorldNet Services 8151 1537 2908 238 UniNet S.A. de C.V. 20115 1528 1502 657 Charter Communications 2386 1326 618 936 AT&T Data Communications Serv 17488 1307 134 130 Hathway IP Over Cable Interne 4755 1298 289 144 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3827 3429 Time Warner Telecom 1785 1751 1619 PaeTec Communications, Inc. 4766 1837 1360 Korea Telecom (KIX) 8151 1537 1299 UniNet S.A. de C.V. 17488 1307 1177 Hathway IP Over Cable Interne 4755 1298 1154 TATA Communications formerly 11492 1145 1131 Cable One 22773 1139 1069 Cox Communications, Inc. 18566 1059 1049 Covad Communications 6478 1179 1016 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 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 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 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.190.64.0/22 28683 Office des Postes et telecomm 41.202.96.0/19 29571 Ci Telecom Autonomous system 41.220.144.0/20 36918 ORASCOM TELECOM ALGERIE VSAT 41.220.159.0/24 36918 ORASCOM TELECOM ALGERIE VSAT 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.24.0/22 25747 VSC Satellite Co 41.223.92.0/22 36936 >>UNKNOWN<< 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:66 /12:192 /13:391 /14:678 /15:1244 /16:11007 /17:5201 /18:8834 /19:18242 /20:22291 /21:22337 /22:29026 /23:28774 /24:165365 /25:948 /26:1197 /27:606 /28:133 /29:9 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2616 4052 bellsouth.net, inc. 4323 2348 3827 Time Warner Telecom 4766 1475 1837 Korea Telecom (KIX) 1785 1213 1751 PaeTec Communications, Inc. 17488 1061 1307 Hathway IP Over Cable Interne 11492 1056 1145 Cable One 18566 1040 1059 Covad Communications 7018 942 1568 AT&T WorldNet Services 10620 933 1027 TVCABLE BOGOTA 9583 848 996 Sify Limited Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:13 8:254 12:2003 13:10 15:23 16:3 17:8 20:26 24:1381 27:22 32:48 33:12 38:658 40:100 41:1963 44:3 46:1 47:26 52:6 55:6 56:2 57:24 58:675 59:578 60:431 61:1097 62:1036 63:1970 64:3818 65:2361 66:4167 67:1815 68:1044 69:2801 70:696 71:238 72:1860 73:2 74:2150 75:244 76:314 77:839 78:600 79:417 80:991 81:777 82:454 83:452 84:690 85:1042 86:385 87:682 88:351 89:1551 90:82 91:2709 92:443 93:1099 94:1392 95:550 96:234 97:298 98:526 99:26 109:441 110:296 111:469 112:244 113:256 114:386 115:605 116:1029 117:626 118:415 119:959 120:147 121:854 122:1388 123:868 124:1070 125:1293 128:207 129:203 130:160 131:558 132:250 133:17 134:197 135:44 136:223 137:171 138:257 139:94 140:478 141:136 142:374 143:357 144:428 145:52 146:424 147:167 148:584 149:227 150:150 151:168 152:260 153:169 154:2 155:326 156:182 157:324 158:102 159:359 160:315 161:177 162:268 163:168 164:410 165:522 166:505 167:401 168:797 169:157 170:736 171:48 172:2 173:608 174:620 175:61 178:42 180:363 182:25 183:241 184:28 186:344 187:266 188:1220 189:715 190:3606 192:5719 193:4628 194:3358 195:2782 196:1168 198:3545 199:3387 200:5280 201:1481 202:7917 203:8283 204:4071 205:2291 206:2520 207:3017 208:3889 209:3446 210:2524 211:1217 212:1714 213:1683 214:587 215:72 216:4471 217:1505 218:482 219:424 220:1089 221:381 222:313 End of report From wavetossed at googlemail.com Fri Apr 2 15:08:03 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Fri, 2 Apr 2010 21:08:03 +0100 Subject: Books for the NOC guys... In-Reply-To: <4BB62DC8.4030400@mtcc.com> References: <86wrwqukcm.fsf@seastrom.com> <28028.1270215582@localhost> <4BB62CC1.3010204@foobar.org> <4BB62DC8.4030400@mtcc.com> Message-ID: >> In short: less zealotry, more pragmatism and a realisation that each >> language has its own strengths and weaknesses. ?Bad code is bad code in >> any >> language. > > All true, but I'd still say there's a special rung in hell for bad perl. And it is exacerbated by the huge volume of bad PERL books out there and the fact that entry level NOC monkeys often get the idea that PERL is cool and therefore learn it as their first and only language without a lot of critical thinking. Also, please note that the original request was for books, or in other words documents containing guidance. I supplied the name of such a document providing guidance using Python. If someone wanted to play the game and trump me, then they would quote the title of another book, or at least a substantial website tutorial, that uses another programming language. --Michael Dillon From smb at cs.columbia.edu Fri Apr 2 15:10:29 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 2 Apr 2010 16:10:29 -0400 Subject: Books for the NOC guys... In-Reply-To: <20100402175344.GC1510190@hiwaay.net> References: <86wrwqukcm.fsf@seastrom.com> <28028.1270215582@localhost> <4BB62CC1.3010204@foobar.org> <4BB62DC8.4030400@mtcc.com> <20100402175344.GC1510190@hiwaay.net> Message-ID: <5AA9C15C-F9C8-4802-AAEA-AD82D3622941@cs.columbia.edu> On Apr 2, 2010, at 1:53 44PM, Chris Adams wrote: > Once upon a time, Michael Thomas said: >> All true, but I'd still say there's a special rung in hell for bad perl. > > Ehh, bad perl is still more readable than good APL. At least I can > reformat the perl! :-) > -- Oh, I don't know about that -- you an often reformat APL, too. Just because something can be written in one line doesn't mean it should be! And bad APL -- well, that's produced either by people who are trying to be too clever, or who haven't grokked APL's array-as-a-whole philosophy, and try to use its (very poor) looping or conditional control flow primitives. --Steve Bellovin, http://www.cs.columbia.edu/~smb From nonobvious at gmail.com Fri Apr 2 15:12:17 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Fri, 2 Apr 2010 13:12:17 -0700 Subject: Books for the NOC guys... In-Reply-To: <4BB60F15.10504@cisco.com> References: <86wrwqukcm.fsf@seastrom.com> <4BB60F15.10504@cisco.com> Message-ID: On Fri, Apr 2, 2010 at 8:36 AM, Eliot Lear wrote: > ?On 4/2/10 2:09 PM, Robert E. Seastrom wrote: >> >> So, what are you having your up-and-coming NOC staff read? > > Practice of System and Network Administration by Limoncelli, Hogan, and > Challup. ?I may be biased, being married to Hogan. Chalup with one L (though of course she didn't have that name when you and I first met her...) -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From jeroen at mompl.net Fri Apr 2 16:01:45 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 02 Apr 2010 14:01:45 -0700 Subject: legacy /8 Message-ID: <4BB65B39.8010902@mompl.net> I am curious. Once we're nearing exhausting all IPv4 space will there ever come a time to ask/demand/force returning all these legacy /8 allocations? I think I understand the difficulty in that, but then running out of IPs is also a difficult issue. :-) For some reason I sooner see all IPv4 space being exhausted than IPv6 being actually implemented globally. Greetings, Jeroen From msa at latt.net Fri Apr 2 16:06:31 2010 From: msa at latt.net (Majdi S. Abbas) Date: Fri, 2 Apr 2010 14:06:31 -0700 Subject: legacy /8 In-Reply-To: <4BB65B39.8010902@mompl.net> References: <4BB65B39.8010902@mompl.net> Message-ID: <20100402210631.GA21373@puck.nether.net> On Fri, Apr 02, 2010 at 02:01:45PM -0700, Jeroen van Aart wrote: > I am curious. Once we're nearing exhausting all IPv4 space will > there ever come a time to ask/demand/force returning all these > legacy /8 allocations? I think I understand the difficulty in that, > but then running out of IPs is also a difficult issue. :-) > > For some reason I sooner see all IPv4 space being exhausted than > IPv6 being actually implemented globally. Because it's no more than a delaying action. Even presuming you get people to cooperate (and they really, have no incentive to because they don't necessarily have any agreement covering the space with the RIRs) rather than fire up their legal department.... A couple of /8s doesn't last long enough to really make a dent in the pain. You might buy yourself a few months at most. It might actually do more harm than good, by convincing people that they can still get v4 space rather than worry about what they are going to do in the future. --msa From charles at knownelement.com Fri Apr 2 16:08:46 2010 From: charles at knownelement.com (Charles N Wyble) Date: Fri, 02 Apr 2010 14:08:46 -0700 Subject: legacy /8 In-Reply-To: <4BB65B39.8010902@mompl.net> References: <4BB65B39.8010902@mompl.net> Message-ID: <4BB65CDE.90406@knownelement.com> Hmmm... it is 2pm on a Friday afternoon. I guess it's the appropriate time for this thread. *grabs popcorn and sits back to watch the fun* From lowen at pari.edu Fri Apr 2 16:08:35 2010 From: lowen at pari.edu (Lamar Owen) Date: Fri, 2 Apr 2010 17:08:35 -0400 Subject: Books for the NOC guys... In-Reply-To: References: <86wrwqukcm.fsf@seastrom.com> Message-ID: <201004021708.35944.lowen@pari.edu> On Friday 02 April 2010 04:08:03 pm Michael Dillon wrote: > If someone wanted to play the game and trump me, then they would > quote the title of another book, or at least a substantial website > tutorial, that uses another programming language. I wish I could reply to this yesterday.... Then, I would have simply pointed to http://www.catb.org/~esr/intercal/intercal.ps.gz and let that hang out there for a while. One of the finest examples of a write-only language. Or, better yet, I could point you to a non-April 1st CGI programming example: http://www.fcc.gov/mb/audio/bickel/archive/colorit-fortran-get-cgi-example.txt Please at least look at that last link even if you already know better than to read the PostScript document at the first link. Look at where the CGI example came from, and consider doing something like rancid in either of those two languages. There is worse out there than perl. Also consider that the second link was originally written for VAX/VMS. I've personally used expect (and the tcl underpinnings) for a number of years, but I wouldn't call it very readable. If you want to force people to write things that are readable, choose COBOL. See http://theamericanprogrammer.com/books/books.cobol.shtml for a list of pertinent books. Having said all that, I'll agree with Michael on using Python, as it is very readable even when you try to obfuscate it, thanks in no small part to the whole 'indentation is significant' design decision. From deleskie at gmail.com Fri Apr 2 16:14:33 2010 From: deleskie at gmail.com (jim deleskie) Date: Fri, 2 Apr 2010 18:14:33 -0300 Subject: legacy /8 In-Reply-To: <4BB65CDE.90406@knownelement.com> References: <4BB65B39.8010902@mompl.net> <4BB65CDE.90406@knownelement.com> Message-ID: Must resist urge to bash v6... must start weekend... must turn off computer for my own good..... On Fri, Apr 2, 2010 at 6:08 PM, Charles N Wyble wrote: > Hmmm... it is 2pm on a Friday afternoon. I guess it's the appropriate time > for this thread. > > *grabs popcorn and sits back to watch the fun* > > > > > From cgrundemann at gmail.com Fri Apr 2 16:16:28 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 2 Apr 2010 15:16:28 -0600 Subject: legacy /8 In-Reply-To: <4BB65B39.8010902@mompl.net> References: <4BB65B39.8010902@mompl.net> Message-ID: On Fri, Apr 2, 2010 at 15:01, Jeroen van Aart wrote: > I am curious. Once we're nearing exhausting all IPv4 space will there ever > come a time to ask/demand/force returning all these legacy /8 allocations? Legacy vs RIR allocated/assigned space is not a proper distinction, in-use vs not-in-use is a much better defining line for this debate. Folks have been asked to return unused space for quite some time now, see https://tools.ietf.org/html/rfc1917. Unless/until governments get involved, there is no one to demand or force the return of any space. If that happens, we likely all lose. > Greetings, > Jeroen -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From LarrySheldon at cox.net Fri Apr 2 16:17:13 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 02 Apr 2010 16:17:13 -0500 Subject: legacy /8 In-Reply-To: <4BB65CDE.90406@knownelement.com> References: <4BB65B39.8010902@mompl.net> <4BB65CDE.90406@knownelement.com> Message-ID: <4BB65ED9.5090404@cox.net> On 4/2/2010 16:08, Charles N Wyble wrote: > Hmmm... it is 2pm on a Friday afternoon. I guess it's the appropriate > time for this thread. > > *grabs popcorn and sits back to watch the fun* While it is true that this is likely to be one of the less productive windmill jousts. I used to work for a holder of a /16 and strongly believe that they (because of NAT-for-security and other reasons) actually using a small fraction of the /16, and that that is being used is largely miss-managed. Ob. declaration--I was fired from that organization for being too old. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From cidr-report at potaroo.net Fri Apr 2 17:00:02 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 Apr 2010 22:00:02 GMT Subject: BGP Update Report Message-ID: <201004022200.o32M02Wt062892@wattle.apnic.net> BGP Update Report Interval: 25-Mar-10 -to- 01-Apr-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS30890 43018 4.0% 95.6 -- EVOLVA Evolva Telecom s.r.l. 2 - AS8452 14685 1.4% 22.5 -- TEDATA TEDATA 3 - AS9829 12720 1.2% 20.4 -- BSNL-NIB National Internet Backbone 4 - AS33475 11273 1.0% 48.0 -- RSN-1 - RockSolid Network, Inc. 5 - AS7643 11138 1.0% 36.4 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 6 - AS28477 10394 1.0% 1154.9 -- Universidad Autonoma del Esstado de Morelos 7 - AS35805 9516 0.9% 15.5 -- UTG-AS United Telecom AS 8 - AS12479 8925 0.8% 207.6 -- UNI2-AS Uni2 - Lince telecomunicaciones 9 - AS26025 8497 0.8% 8497.0 -- COC - City of Calgary 10 - AS16569 8082 0.8% 8082.0 -- ASN-CITY-OF-CALGARY - City of Calgary 11 - AS1785 5828 0.5% 3.5 -- AS-PAETEC-NET - PaeTec Communications, Inc. 12 - AS5800 5751 0.5% 29.5 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 13 - AS8151 5649 0.5% 6.0 -- Uninet S.A. de C.V. 14 - AS27066 5520 0.5% 22.2 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 15 - AS33776 5402 0.5% 20.6 -- STARCOMMS-ASN 16 - AS17974 5303 0.5% 9.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 17 - AS11139 5060 0.5% 10.4 -- CWRIN CW BARBADOS 18 - AS20115 4962 0.5% 7.1 -- CHARTER-NET-HKY-NC - Charter Communications 19 - AS6713 4925 0.5% 41.4 -- IAM-AS 20 - AS4847 4661 0.4% 66.6 -- CNIX-AP China Networks Inter-Exchange TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS26025 8497 0.8% 8497.0 -- COC - City of Calgary 2 - AS16569 8082 0.8% 8082.0 -- ASN-CITY-OF-CALGARY - City of Calgary 3 - AS42214 2868 0.3% 2868.0 -- IWC-AS SC International Work Company SRL 4 - AS28477 10394 1.0% 1154.9 -- Universidad Autonoma del Esstado de Morelos 5 - AS5691 2250 0.2% 1125.0 -- MITRE-AS-5 - The MITRE Corporation 6 - AS22395 596 0.1% 596.0 -- GHCO-INTERNAP - Goldenberg Hehmeyer 7 - AS32794 1120 0.1% 560.0 -- ICFG - International Church of the Foursquare Gospel 8 - AS3 518 0.1% 18.0 -- LASERCRAFT Ural Electronics Factory Ltd. 9 - AS53353 920 0.1% 460.0 -- PROGRAMMERSAS1234 - Programmers Investment Corp 10 - AS35291 781 0.1% 390.5 -- ICOMM-AS SC Internet Communication Systems SRL 11 - AS38820 382 0.0% 382.0 -- THAIDEVINSURANCE-CSLOXINFO-AS-TH CSLOXINFO Project for Thai Development Insurance 12 - AS45960 359 0.0% 359.0 -- YTLCOMMS-AS-AP YTL COMMUNICATIONS SDN BHD 13 - AS10445 2132 0.2% 355.3 -- HTG - Huntleigh Telcom 14 - AS28052 345 0.0% 345.0 -- Arte Radiotelevisivo Argentino 15 - AS11613 332 0.0% 332.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 16 - AS19647 4550 0.4% 303.3 -- HPOD20001 - Hewlett-Packard Operation Division 17 - AS25969 3359 0.3% 279.9 -- SLU - St. Louis University 18 - AS21135 521 0.1% 260.5 -- MTT-AS MTT AS (Russia) 19 - AS37932 230 0.0% 230.0 -- RMUTI-AS-AP Rajamangala University of Technology Isan 20 - AS9475 230 0.0% 230.0 -- WU-TH-AP Walailuk University TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 200.13.36.0/24 10306 0.9% AS28477 -- Universidad Autonoma del Esstado de Morelos 2 - 208.98.231.0/24 8497 0.7% AS26025 -- COC - City of Calgary 3 - 208.98.230.0/24 8082 0.7% AS16569 -- ASN-CITY-OF-CALGARY - City of Calgary 4 - 85.60.194.0/23 2909 0.2% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 5 - 89.42.72.0/21 2868 0.2% AS42214 -- IWC-AS SC International Work Company SRL 6 - 206.184.16.0/24 2826 0.2% AS174 -- COGENT Cogent/PSI 7 - 222.255.186.0/25 2702 0.2% AS7643 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 8 - 203.162.118.128/ 2677 0.2% AS7643 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 11 - 85.60.192.0/23 2269 0.2% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 12 - 192.12.120.0/24 2245 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 13 - 93.81.216.0/22 2018 0.2% AS8402 -- CORBINA-AS Corbina Telecom 14 - 85.204.64.0/23 1831 0.2% AS6746 -- ASTRAL UPC Romania Srl, Romania 15 - 143.138.107.0/24 1805 0.1% AS747 -- TAEGU-AS - Headquarters, USAISC 16 - 165.134.1.0/24 1665 0.1% AS25969 -- SLU - St. Louis University 17 - 165.134.200.0/21 1665 0.1% AS25969 -- SLU - St. Louis University 18 - 85.60.208.0/21 1364 0.1% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 19 - 85.60.208.0/22 1356 0.1% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 20 - 90.150.0.0/24 1271 0.1% AS35400 -- MFIST Interregoinal Organization Network Technologies 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 james.cutler at consultant.com Fri Apr 2 17:01:18 2010 From: james.cutler at consultant.com (Cutler James R) Date: Fri, 2 Apr 2010 18:01:18 -0400 Subject: legacy /8 In-Reply-To: <4BB65B39.8010902@mompl.net> References: <4BB65B39.8010902@mompl.net> Message-ID: <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> I also just got a fresh box of popcorn. I will sit by and wait for Jeroen to do a business analysis and tell me the return on investment. (Assuming that he can find any legal grounds for demanding return of legacy /8 allocations.) All of the analysis results I have seen mention figuratively beating oneself [..painfully..] with combat boots. Running out of IP addresses is not a soon realized scenario for IPv6. If an organization runs out of IP addresses, the difficulty is with top management, not the network or address space. I think this is a many-iterated discussion, also know by some as a "rathole". On Apr 2, 2010, at 5:01 PM, Jeroen van Aart wrote: > I am curious. Once we're nearing exhausting all IPv4 space will there ever come a time to ask/demand/force returning all these legacy /8 allocations? I think I understand the difficulty in that, but then running out of IPs is also a difficult issue. :-) > > For some reason I sooner see all IPv4 space being exhausted than IPv6 being actually implemented globally. > > Greetings, > Jeroen > James R. Cutler james.cutler at consultant.com From cidr-report at potaroo.net Fri Apr 2 17:00:01 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 Apr 2010 22:00:01 GMT Subject: The Cidr Report Message-ID: <201004022200.o32M01tm062884@wattle.apnic.net> This report has been generated at Fri Apr 2 21:11:30 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 26-03-10 318754 195266 27-03-10 318878 195578 28-03-10 318925 195640 29-03-10 318973 195849 30-03-10 319150 195752 31-03-10 318826 196124 01-04-10 319366 196113 02-04-10 319323 196230 AS Summary 34044 Number of ASes in routing system 14531 Number of ASes announcing only one prefix 4414 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 96812544 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'). --- 02Apr10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 319114 196172 122942 38.5% All ASes AS6389 4055 315 3740 92.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4414 1309 3105 70.3% TWTC - tw telecom holdings, inc. AS4766 1837 492 1345 73.2% KIXS-AS-KR Korea Telecom AS4755 1298 195 1103 85.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1139 75 1064 93.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS1785 1751 706 1045 59.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS18566 1059 33 1026 96.9% COVAD - Covad Communications Co. AS17488 1307 340 967 74.0% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1537 623 914 59.5% Uninet S.A. de C.V. AS7545 1097 240 857 78.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS10620 1027 184 843 82.1% Telmex Colombia S.A. AS19262 1087 246 841 77.4% VZGNI-TRANSIT - Verizon Internet Services Inc. AS6478 1179 428 751 63.7% ATT-INTERNET3 - AT&T WorldNet Services AS18101 759 53 706 93.0% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS24560 873 240 633 72.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS5668 808 192 616 76.2% AS-5668 - CenturyTel Internet Holdings, Inc. AS4808 843 243 600 71.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 678 84 594 87.6% MPX-AS Microplex PTY LTD AS4134 1027 435 592 57.6% CHINANET-BACKBONE No.31,Jin-rong Street AS7303 700 109 591 84.4% Telecom Argentina S.A. AS7018 1568 1000 568 36.2% ATT-INTERNET4 - AT&T WorldNet Services AS8452 890 346 544 61.1% TEDATA TEDATA AS17908 772 234 538 69.7% TCISL Tata Communications AS3356 1228 699 529 43.1% LEVEL3 Level 3 Communications AS35805 612 96 516 84.3% UTG-AS United Telecom AS AS4780 654 155 499 76.3% SEEDNET Digital United Inc. AS22047 541 47 494 91.3% VTR BANDA ANCHA S.A. AS17676 572 84 488 85.3% GIGAINFRA Softbank BB Corp. AS9443 555 74 481 86.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7738 477 30 447 93.7% Telecomunicacoes da Bahia S.A. Total 36344 9307 27037 74.4% Top 30 total Possible Bogus Routes 2.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.190.64.0/22 AS28683 BENINTELECOM 41.202.96.0/19 AS29571 CITelecom-AS 41.220.144.0/20 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 41.220.159.0/24 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.24.0/22 AS25747 VSC-SATELLITE-CO - VSC Satellite Co. 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 AS26452 BRING-AS - BringCom, Inc. 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.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales Telesat S.A. 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 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 78.41.80.0/24 AS29158 DE-IP69 Tux-Service 78.41.81.0/24 AS29158 DE-IP69 Tux-Service 78.41.82.0/24 AS29158 DE-IP69 Tux-Service 78.41.83.0/24 AS29158 DE-IP69 Tux-Service 78.41.84.0/24 AS29158 DE-IP69 Tux-Service 78.41.86.0/24 AS29158 DE-IP69 Tux-Service 78.41.87.0/24 AS29158 DE-IP69 Tux-Service 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 80.250.32.0/22 AS21452 SKANNET-IBADAN SKANNET IP Network 80.250.32.0/23 AS21452 SKANNET-IBADAN SKANNET IP Network 80.250.34.0/23 AS21452 SKANNET-IBADAN SKANNET IP Network 110.34.40.0/22 AS24399 ABN-PEERING-AS-AP Asia Broadcast Networks Peering 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. 117.104.168.0/22 AS37976 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 119.42.144.0/21 AS45753 NETSEC-HK Unit 1205-1207 119.42.144.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.145.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.146.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.147.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.148.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.149.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.150.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.151.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.160.200.0/23 AS45122 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 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 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.45.0/24 AS2905 TICSA-ASN 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.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS 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.29.40.0/22 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 196.32.96.0/20 AS33787 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.254.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 196.216.4.0/22 AS23889 MAURITIUS-TELECOM-AS-AP 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services 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.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 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 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.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - 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.52.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company 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.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.77.138.0/23 AS24487 202.79.224.0/21 AS9519 VERTELNET Vertical Telecoms Pty Ltd 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.89.8.0/22 AS6648 BAYAN-TELECOMMUNICATIONS Bayan Telecommunications, Inc. 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.146.184.0/23 AS24487 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.166.166.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 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.179.154.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.124.96.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.124.100.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.124.104.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.160.130.0/23 AS24487 203.215.52.0/22 AS18101 RIL-IDC Reliance Infocom Ltd Internet Data Centre, 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.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.128.104.0/21 AS11709 VIC - VIRTUAL INTERACTIVE CENTER 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 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.66.152.0/24 AS18499 208.66.153.0/24 AS18499 208.66.154.0/24 AS18499 208.66.155.0/24 AS18499 208.66.156.0/24 AS18499 208.66.157.0/24 AS18499 208.66.158.0/24 AS18499 208.66.159.0/24 AS18499 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.87.208.0/24 AS31997 209.87.209.0/24 AS31997 209.87.210.0/24 AS31997 209.87.211.0/24 AS31997 209.87.212.0/22 AS31997 209.87.216.0/24 AS31997 209.87.217.0/24 AS31997 209.87.218.0/24 AS31997 209.87.219.0/24 AS31997 209.87.220.0/24 AS31997 209.87.221.0/24 AS31997 209.87.222.0/24 AS31997 209.87.223.0/24 AS31997 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.177.160.0/24 AS18499 209.177.161.0/24 AS18499 209.177.162.0/24 AS18499 209.177.163.0/24 AS18499 209.177.164.0/24 AS18499 209.177.165.0/24 AS18499 209.177.166.0/24 AS18499 209.177.167.0/24 AS18499 209.177.168.0/24 AS18499 209.177.169.0/24 AS18499 209.177.170.0/24 AS18499 209.177.171.0/24 AS18499 209.177.172.0/24 AS18499 209.177.173.0/24 AS18499 209.177.174.0/24 AS18499 209.177.175.0/24 AS18499 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.144.240.0/23 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.243.0/24 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.244.0/22 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, 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 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 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 owen at delong.com Fri Apr 2 17:13:16 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Apr 2010 15:13:16 -0700 Subject: legacy /8 In-Reply-To: <4BB65B39.8010902@mompl.net> References: <4BB65B39.8010902@mompl.net> Message-ID: Sigh... Guess you missed the last several go-arounds of Running out of IPv4 will create some hardships. That cannot be avoided. Even if we were to reclaim the supposed unused legacy /8s, we'd still only extend the date of IPv4 runout by a few months. The amount of effort required to reclaim those few IPv4 addresses would vastly exceed the return on that effort. Far better for that effort to be directed towards the addition of IPv6 capabilities to existing IPv4 deployments so as to minimize the impact of IPv4 exhaustion. Owen On Apr 2, 2010, at 2:01 PM, Jeroen van Aart wrote: > I am curious. Once we're nearing exhausting all IPv4 space will there ever come a time to ask/demand/force returning all these legacy /8 allocations? I think I understand the difficulty in that, but then running out of IPs is also a difficult issue. :-) > > For some reason I sooner see all IPv4 space being exhausted than IPv6 being actually implemented globally. > > Greetings, > Jeroen From owen at delong.com Fri Apr 2 17:14:33 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Apr 2010 15:14:33 -0700 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> Message-ID: <1FAC079B-29B8-4D51-BE44-F27B4A038E2D@delong.com> On Apr 2, 2010, at 2:16 PM, Chris Grundemann wrote: > On Fri, Apr 2, 2010 at 15:01, Jeroen van Aart wrote: >> I am curious. Once we're nearing exhausting all IPv4 space will there ever >> come a time to ask/demand/force returning all these legacy /8 allocations? > > > Legacy vs RIR allocated/assigned space is not a proper distinction, > in-use vs not-in-use is a much better defining line for this debate. > True, but... > Folks have been asked to return unused space for quite some time now, > see https://tools.ietf.org/html/rfc1917. > Also true. > Unless/until governments get involved, there is no one to demand or > force the return of any space. If that happens, we likely all lose. > This is where Legacy vs. RIR becomes meaningful. Legacy holders have no contractual obligation to return unused space. RIR recipients, on the other hand, do. Owen From joe at riversidecg.com Fri Apr 2 17:19:12 2010 From: joe at riversidecg.com (Joe Johnson) Date: Fri, 2 Apr 2010 17:19:12 -0500 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> Message-ID: <154EDE9026B3D54F883B20F2BBDCF87953A22981@exbe01.windows.riversidecg.com> Owen DeLong wrote: > The amount of effort required to reclaim those few IPv4 addresses would > vastly exceed the return on that effort. Far better for that effort to be > directed towards the addition of IPv6 capabilities to existing IPv4 > deployments so as to minimize the impact of IPv4 exhaustion. Maybe encourage people like Apple, Xerox, HP or Ford to migrate their operations completely to IPv6 and return their /8? j From msa at latt.net Fri Apr 2 17:20:45 2010 From: msa at latt.net (Majdi S. Abbas) Date: Fri, 2 Apr 2010 15:20:45 -0700 Subject: legacy /8 In-Reply-To: <154EDE9026B3D54F883B20F2BBDCF87953A22981@exbe01.windows.riversidecg.com> References: <4BB65B39.8010902@mompl.net> <154EDE9026B3D54F883B20F2BBDCF87953A22981@exbe01.windows.riversidecg.com> Message-ID: <20100402222045.GC21373@puck.nether.net> On Fri, Apr 02, 2010 at 05:19:12PM -0500, Joe Johnson wrote: > Maybe encourage people like Apple, Xerox, HP or Ford to migrate > their operations completely to IPv6 and return their /8? How are they going to completely migrate to v6 while there is a demand for v4 space (specifically, THEIR v4 space.)? As long as the beast is getting fed, there will be customers without v6, and they're not going to isolate themselves for the commercial benefit of an unrelated third party. And even if they did, it's only going to buy you a few months. --msa From jeroen at mompl.net Fri Apr 2 17:25:22 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 02 Apr 2010 15:25:22 -0700 Subject: legacy /8 In-Reply-To: <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> Message-ID: <4BB66ED2.6080304@mompl.net> Cutler James R wrote: > I also just got a fresh box of popcorn. I will sit by and wait I honestly am not trying to be a troll. It's just everytime I glance over the IANA IPv4 Address Space Registry I feel rather annoyed about all those /8s that were assigned back in the day without apparently realising we might run out. It was explained to me that many companies with /8s use it for their internal network and migrating to 10/8 instead is a major pain. > Running out of IP addresses is not a soon realized scenario for IPv6. If an organization runs out of IP addresses, the difficulty is with top management, not the network or address space. I also don't try to bash IPv6, I don't know enough about it yet to do that and I doubt I would. From a casual observer's point of view having that much more IP space to allocate can only be a good thing. But from the same observer's POV you can also reason it is taking very long to gain acceptance. Regards, Jeroen From 3356 at blargh.com Fri Apr 2 17:38:26 2010 From: 3356 at blargh.com (Andrew Gray) Date: Fri, 02 Apr 2010 15:38:26 -0700 Subject: legacy /8 In-Reply-To: <4BB66ED2.6080304@mompl.net> References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> Message-ID: Jeroen van Aart writes: > Cutler James R wrote: >> I also just got a fresh box of popcorn. I will sit by and wait > > I honestly am not trying to be a troll. It's just everytime I glance over > the IANA IPv4 Address Space Registry I feel rather annoyed about all those > /8s that were assigned back in the day without apparently realising we > might run out. > > It was explained to me that many companies with /8s use it for their > internal network and migrating to 10/8 instead is a major pain. You know, I've felt the same irritation before, but one thing I am wondering and perhaps some folks around here have been around long enough to know - what was the original thinking behind doing those /8s? I understand that they were A classes and assigned to large companies, etc. but was it just not believed there would be more than 126(-ish) of these entities at the time? Or was it thought we would move on to larger address space before we did? Or was it that things were just more free-flowing back in the day? Why were A classes even created? RFC 791 at least doesn't seem to provide much insight as to the 'whys'. - Andrew From lowen at pari.edu Fri Apr 2 17:41:32 2010 From: lowen at pari.edu (Lamar Owen) Date: Fri, 2 Apr 2010 18:41:32 -0400 Subject: legacy /8 In-Reply-To: <1FAC079B-29B8-4D51-BE44-F27B4A038E2D@delong.com> References: <4BB65B39.8010902@mompl.net> Message-ID: <201004021841.32573.lowen@pari.edu> On Friday 02 April 2010 06:14:33 pm Owen DeLong wrote: > This is where Legacy vs. RIR becomes meaningful. Legacy holders have > no contractual obligation to return unused space. RIR recipients, on the > other hand, do. Some legacy holders might, I imagine, be 'squatting' on that legacy space and are getting ready to 'sell' some to the highest bidder, generating who knows how much revenue, if their agreement allows them to do so. A few of those same legacy holders might even want to impede IPv6 uptake to make their /8 more valuable when the crunch comes. Perhaps I'm too paranoid. But I'm sure I'm not the first person to think of these possibilities (in my case, however, I have no legacy space, and wouldn't go that route even if I did). From matthew at matthew.at Fri Apr 2 17:43:31 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 02 Apr 2010 15:43:31 -0700 Subject: legacy /8 In-Reply-To: <4BB66ED2.6080304@mompl.net> References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> Message-ID: <4BB67313.1080809@matthew.at> Jeroen van Aart wrote: > Cutler James R wrote: >> I also just got a fresh box of popcorn. I will sit by and wait > > I honestly am not trying to be a troll. It's just everytime I glance > over the IANA IPv4 Address Space Registry I feel rather annoyed about > all those /8s that were assigned back in the day without apparently > realising we might run out. Yes. We should all jump up and down and complain about the early adopters who were present at the time and helped develop (and fund the development of) the Internet into something that pays most of our paychecks today. Or not. And of course some of the folks who got /8s early on have turned them back. Others have merged into entities who use a whole lot of the space. Matthew Kaufman From nanog2 at adns.net Fri Apr 2 17:48:44 2010 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Fri, 2 Apr 2010 17:48:44 -0500 Subject: legacy /8 References: <4BB65B39.8010902@mompl.net> <20100402210631.GA21373@puck.nether.net> Message-ID: <9D78CBC7F28F40C5AF04DD2C8A40B25B@TAKA> On the topic of IP4 exhaustion: 1/8, 2/8 and 5/8 have all been assigned in the last 3 months yet I don't see them being allocated out to customers (users) yet. Is this perhaps a bit of hoarding in advance of the complete depletion of /8's? ----- Original Message ----- From: "Majdi S. Abbas" To: "Jeroen van Aart" Cc: "NANOG list" Sent: Friday, April 02, 2010 4:06 PM Subject: Re: legacy /8 > On Fri, Apr 02, 2010 at 02:01:45PM -0700, Jeroen van Aart wrote: >> I am curious. Once we're nearing exhausting all IPv4 space will >> there ever come a time to ask/demand/force returning all these >> legacy /8 allocations? I think I understand the difficulty in that, >> but then running out of IPs is also a difficult issue. :-) >> >> For some reason I sooner see all IPv4 space being exhausted than >> IPv6 being actually implemented globally. > > Because it's no more than a delaying action. Even presuming > you get people to cooperate (and they really, have no incentive to > because they don't necessarily have any agreement covering the space > with the RIRs) rather than fire up their legal department.... > > A couple of /8s doesn't last long enough to really make a dent > in the pain. You might buy yourself a few months at most. > > It might actually do more harm than good, by convincing people > that they can still get v4 space rather than worry about what they > are going to do in the future. > > --msa > > From msa at latt.net Fri Apr 2 17:52:41 2010 From: msa at latt.net (Majdi S. Abbas) Date: Fri, 2 Apr 2010 15:52:41 -0700 Subject: legacy /8 In-Reply-To: <9D78CBC7F28F40C5AF04DD2C8A40B25B@TAKA> References: <4BB65B39.8010902@mompl.net> <20100402210631.GA21373@puck.nether.net> <9D78CBC7F28F40C5AF04DD2C8A40B25B@TAKA> Message-ID: <20100402225241.GD21373@puck.nether.net> On Fri, Apr 02, 2010 at 05:48:44PM -0500, John Palmer (NANOG Acct) wrote: > On the topic of IP4 exhaustion: 1/8, 2/8 and 5/8 have all been assigned in > the last 3 months yet I don't see them being allocated out to customers > (users) yet. > > Is this perhaps a bit of hoarding in advance of the complete depletion of > /8's? Doubt it. 1/8 is still being evaluated to determine just how usable portions of it are, thanks to silly people of the world that decided 1.1.1.x and the like were 1918 space. As for the others, the RIR requests it when they are running low, but certainly not exhausted, and as slow as people are to update their bogon filters, it sounds like general good practice not to assign out of a new /8 until pre-existing resources are exhausted. Can we put the tinfoil hats away and let this thread die now? --msa From owen at delong.com Fri Apr 2 10:59:29 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Apr 2010 08:59:29 -0700 Subject: Books for the NOC guys... In-Reply-To: <87sk7dnb4e.fsf@bowmore.quux.de> References: <86wrwqukcm.fsf@seastrom.com> <87sk7dnb4e.fsf@bowmore.quux.de> Message-ID: <536A6E4B-A958-49F6-AB68-41ED571CB390@delong.com> On Apr 2, 2010, at 8:10 AM, Jens Link wrote: > "Robert E. Seastrom" writes: > >> So, what are you having your up-and-coming NOC staff read? > > > > I think it's quite good and covers many "modern" topics. One drawback: > It mentions ethereal and not wireshark. At the time of writing ethereal > must have been dead for about 2 years. > Heh.. GUIs they come and GUIs they go... tcpdump works forever. Owen From owen at delong.com Fri Apr 2 17:28:11 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Apr 2010 15:28:11 -0700 Subject: New Linksys CPE, IPv6 ? In-Reply-To: <4BB6601E.3020109@jsbc.cc> References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org><4BB3B651.1020607@csuohio.edu><4BB3E363.6000708@foobar.org> <5A6D953473350C4B9995546AFE9939EE08FE6BEF@RWC-EX1.corp.seven.com> <86E0C9B1-2538-449A-B2C9-5303EA8CA683@delong.com> <4BB6601E.3020109@jsbc.cc> Message-ID: <5F6B2526-60E5-4040-98E0-AC3B785B3DF0@delong.com> I've gotten multiple emails about this... Yes, this is a known issue at the moment due to an upgrade put in place at DeLong. There is an open ticket with Juniper on why the 6in4 tunnels are not working on the SRX-100 and why traffic coming in through the alternate path is not being correctly processed. I hope to have my IPv6 services back on line shortly and I apologize for any inconvenience and the unfortunate timing. Owen On Apr 2, 2010, at 2:22 PM, Jim Burwell wrote: > FYI ... I can't get to delong.com's IPv6 space from my HE tunnel > provided IPv6 space (2001:470:8332::/48). When I traceroute using UDP > or ICMP or tcptrace it stops in HE's core. BGP issue? > > Last hop I see is: 10gigabitethernet1-1.core1.sjc2.ipv6.he.net > (2001:470:0:31::2) > > - Jim > > From owen at delong.com Fri Apr 2 17:46:55 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Apr 2010 15:46:55 -0700 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> Message-ID: <3135E5A4-A45F-44A3-A01D-A86F71988E45@delong.com> On Apr 2, 2010, at 3:38 PM, Andrew Gray wrote: > Jeroen van Aart writes: >> Cutler James R wrote: >>> I also just got a fresh box of popcorn. I will sit by and wait >> I honestly am not trying to be a troll. It's just everytime I glance over the IANA IPv4 Address Space Registry I feel rather annoyed about all those /8s that were assigned back in the day without apparently realising we might run out. It was explained to me that many companies with /8s use it for their internal network and migrating to 10/8 instead is a major pain. > > You know, I've felt the same irritation before, but one thing I am wondering and perhaps some folks around here have been around long enough to know - what was the original thinking behind doing those /8s? The original thinking was based on an environment where the Internet was expected to consist only of a few corporate entities providing services and products to research institutions and the government. There was no WWW, no browsers, and Windows couldn't even spell TCP/IP at the time. The expectation was that those /8s would be subnetted into vast arrays of "Class C" sized chunks and that subnets within a given /8 all had to be the same size (this used to be necessary to keep RIP happy and every machine participating in RIP routing had to have an /etc/netmasks (or equivalent) table that tracked "THE" subnet mask for each natural prefix). Sure, a /8 is a lot of addresses in today's world. However, back then, it was much like a /48 today. Just a way to give someone 65,500+ subnets (for any given X/8, then X.0/16, X.255/16, X.Y.0/24, X.Y.255/24 were unusable in these days). > I understand that they were A classes and assigned to large companies, etc. but was it just not believed there would be more than 126(-ish) of these entities at the time? Or was it thought we would move on to larger address space before we did? Or was it that things were just more free-flowing back in the day? Why were A classes even created? RFC 791 at least doesn't seem to provide much insight as to the 'whys'. > - Andrew It was thought that we would not have nearly so many people connected to the internet. It was expected that most things connecting to the internet would be minicomputers and mainframes. Owen From smb at cs.columbia.edu Fri Apr 2 18:03:07 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 2 Apr 2010 19:03:07 -0400 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> Message-ID: <199AEF8A-62E1-4DBB-85D3-86409AACB434@cs.columbia.edu> On Apr 2, 2010, at 6:38 26PM, Andrew Gray wrote: > Jeroen van Aart writes: >> Cutler James R wrote: >>> I also just got a fresh box of popcorn. I will sit by and wait >> I honestly am not trying to be a troll. It's just everytime I glance over the IANA IPv4 Address Space Registry I feel rather annoyed about all those /8s that were assigned back in the day without apparently realising we might run out. It was explained to me that many companies with /8s use it for their internal network and migrating to 10/8 instead is a major pain. > > You know, I've felt the same irritation before, but one thing I am wondering and perhaps some folks around here have been around long enough to know - what was the original thinking behind doing those /8s? > I understand that they were A classes and assigned to large companies, etc. but was it just not believed there would be more than 126(-ish) of these entities at the time? Or was it thought we would move on to larger address space before we did? Or was it that things were just more free-flowing back in the day? Why were A classes even created? RFC 791 at least doesn't seem to provide much insight as to the 'whys'. Many large companies found that class A nets weren't very useful. Multiple levels of subnetting didn't exist, which meant that you couldn't assign a /16 to a location and a /24 to each piece of thick yellow cable within the location, for example. AT&T got 12/8 moderately early. We realized we couldn't easily use it, and offered it back in exchange for the equivalent in class B space. Postel gave us the latter (135/8), but told us to keep 12/8 -- other people were discovering the same problem, so there was little demand for class A networks. (This was circa 1987, if memory serves, and possibly a year or two earlier.) --Steve Bellovin, http://www.cs.columbia.edu/~smb From wavetossed at googlemail.com Fri Apr 2 18:03:39 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Sat, 3 Apr 2010 00:03:39 +0100 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> Message-ID: > You know, I've felt the same irritation before, but one thing I am wondering > and perhaps some folks around here have been around long enough to know - > what was the original thinking behind doing those /8s? Read your network history. In the beginning all allocations were /8s, in fact the slash notation hadn't been invented yet. Network numbers were 8 bits and there was a 24 bit host id appended. Then someone realised that the net was growing really fast, so they invented class A, B and C addresses in which the network numbers were 8, 16 or 24 bits respectively. You could tell which class by looking at the first two bits of the address. In that time period only very big organizations got class A allocations. Mid-sized ones got class B and small ones got class C. In fact what happened was that some smaller organizations got multiple non-aggregatable class C blocks (and aggregation didn't exist anyway). Later on some clever folks invented VLSM for the routers which allowed network ops folks to invent CIDR. That was when people really got interested in justifying the size of an allocation, and working based on 3 months, or 6 months requirements. This is when ARIN was created so that the community had some input into how things were done. But nobody could really unroll the past, just clean up the bits where people were changing things around anyway. For instance this is how Stanford's /8 ended up being returned. Lots of folks believed that VLSM and CIDR were only stopgap measures so around the same time they invented IPv6. It was released into network operations around 10 years ago which is why most of your network equipment and servers already support it. But that's all water under the bridge. It's too late to do anything about IPv4. The ROI just isn't there any more, and it doesn't escape the need to invest in IPv6. The network industry has now reached consensus that IPv6 is the way forward, and you have to catch the wave, or you will drown in the undertow. --Michael Dillon From jis at MIT.EDU Fri Apr 2 18:06:17 2010 From: jis at MIT.EDU (Jeffrey I. Schiller) Date: Fri, 02 Apr 2010 19:06:17 -0400 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> Message-ID: <4BB67869.8040409@mit.edu> On 04/02/2010 06:38 PM, Andrew Gray wrote: > I understand that they were A classes and assigned to large > companies, etc. but was it just not believed there would be more than > 126(-ish) of these entities at the time? Or was it thought we would > move on to larger address space before we did? Or was it that things > were just more free-flowing back in the day? Why were A classes even > created? RFC 791 at least doesn't seem to provide much insight as to > the 'whys'. /8's were not given out to large companies. They were given out to *everyone*! In the beginning there was the ARPANET and it was considered a large network (it was certainly an expensive network!). The notion was that there would only be a small number of "large" networks, so 8 bits was enough to enumerate them. The original IP plan didn't have classes of networks at all. It was 8 bits of network and 24 bits of host-on-that-network. It was only after network numbers started to hit the early thirties that folks realized that there needed to be more networks and the "class-full" approach was invented. So most of the existing class A holders just happened to be the very early adopters (actually the original research and government organizations that were connected to the network). -Jeff -- ======================================================================== Jeffrey I. Schiller MIT Network Manager/Security Architect PCI Compliance Officer Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis at mit.edu http://jis.qyv.name ======================================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: OpenPGP digital signature URL: From nanog2 at adns.net Fri Apr 2 18:29:02 2010 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Fri, 2 Apr 2010 18:29:02 -0500 Subject: legacy /8 References: <4BB65B39.8010902@mompl.net> <20100402210631.GA21373@puck.nether.net> <9D78CBC7F28F40C5AF04DD2C8A40B25B@TAKA> <20100402225241.GD21373@puck.nether.net> Message-ID: <502AB654CA724523B8B377300EBE11A0@TAKA> ----- Original Message ----- From: "Majdi S. Abbas" To: "John Palmer (NANOG Acct)" Cc: "NANOG list" Sent: Friday, April 02, 2010 5:52 PM Subject: Re: legacy /8 > On Fri, Apr 02, 2010 at 05:48:44PM -0500, John Palmer (NANOG Acct) wrote: >> On the topic of IP4 exhaustion: 1/8, 2/8 and 5/8 have all been assigned in >> the last 3 months yet I don't see them being allocated out to customers >> (users) yet. >> >> Is this perhaps a bit of hoarding in advance of the complete depletion of >> /8's? > > Doubt it. 1/8 is still being evaluated to determine just how usable > portions of it are, thanks to silly people of the world that decided > 1.1.1.x and the like were 1918 space. > > As for the others, the RIR requests it when they are running low, > but certainly not exhausted, and as slow as people are to update their > bogon filters, it sounds like general good practice not to assign out of > a new /8 until pre-existing resources are exhausted. > Was looking for the "allocated" file on the ARIN website, but can't remember where it is. They used to have a file with one line per allocation that started like this "arin|US|ipv4". Is that still public somewhere? > Can we put the tinfoil hats away and let this thread die now? > > --msa > Good luck with that one :-> From drc at virtualized.org Fri Apr 2 18:30:35 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 2 Apr 2010 13:30:35 -1000 Subject: Note change in IANA registry URLs In-Reply-To: <4BB625D7.2060901@ripe.net> References: <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> <4BB4109E.90006@zill.net> <20100401032232.GB5032@dan.olp.net> <4BB5BC01.1080005@ripe.net> <0D22ABE6-40A7-4616-A58D-D6AC7D3171CA@virtualized.org> <4BB625D7.2060901@ripe.net> Message-ID: <58EFF4A8-6BF0-476D-BA36-1E754D4143AD@virtualized.org> On Apr 2, 2010, at 7:13 AM, Robert Kisteleki wrote: > You're confusing two things: URL and content. According to the announcement, TXT files will be generated still. Why, again, must the URL change? As Leo pointed out, a message will be displayed at the historical URL. Does this address your concerns? Regards, -drc From bruns at 2mbit.com Fri Apr 2 18:40:37 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 02 Apr 2010 17:40:37 -0600 Subject: legacy /8 In-Reply-To: <4BB65B39.8010902@mompl.net> References: <4BB65B39.8010902@mompl.net> Message-ID: <4BB68075.5050606@2mbit.com> On 4/2/10 3:01 PM, Jeroen van Aart wrote: > I am curious. Once we're nearing exhausting all IPv4 space will there > ever come a time to ask/demand/force returning all these legacy /8 > allocations? I think I understand the difficulty in that, but then > running out of IPs is also a difficult issue. :-) > > For some reason I sooner see all IPv4 space being exhausted than IPv6 > being actually implemented globally. > > Greetings, > Jeroen > I've got a rather stupidly simple and straightforward plan, since we're all throwing ideas out. Take back all the IP space from China and give them a single /20 and tell them to make do. They're already behind a great firewall, so they should have no problem using NAT with their citizens for easier restricting of freedoms, and for the actual services they need to run, they can assign a limited amount of static IP addresses for servers, and the rest NAT as well, and port forward for specific services. If they want to be an intranet, I say, lets help them achieve that goal. They get to play in their own sandbox, and we get some IP space back to buy us more time. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bzs at world.std.com Fri Apr 2 19:04:55 2010 From: bzs at world.std.com (Barry Shein) Date: Fri, 2 Apr 2010 20:04:55 -0400 Subject: legacy /8 In-Reply-To: <4BB66ED2.6080304@mompl.net> References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> Message-ID: <19382.34343.351127.681736@world.std.com> On April 2, 2010 at 15:25 jeroen at mompl.net (Jeroen van Aart) wrote: > > I honestly am not trying to be a troll. It's just everytime I glance > over the IANA IPv4 Address Space Registry I feel rather annoyed about > all those /8s that were assigned back in the day without apparently > realising we might run out. Aha! Someone else who believes the internet should model a justice system. -- -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 bmanning at vacation.karoshi.com Fri Apr 2 19:09:52 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 3 Apr 2010 00:09:52 +0000 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> Message-ID: <20100403000952.GA9888@vacation.karoshi.com.> On Fri, Apr 02, 2010 at 03:13:16PM -0700, Owen DeLong wrote: > Sigh... Guess you missed the last several go-arounds of > > Running out of IPv4 will create some hardships. That cannot be avoided. we won't run out, we won't exaust, we are -NOT- killing the last tuna. what we are doing is roughly what was anticipated in RFC 2050, we will get more efficent utilization of all the space. > Even if we were to reclaim the supposed unused legacy /8s, we'd still > only extend the date of IPv4 runout by a few months. wrong analogy. there won't be "green field" space - but there will still be lots to go around... for legacy style use (e.g. the Internet as we know it today) -- want to do something different? then use IPv6. > The amount of effort required to reclaim those few IPv4 addresses would > vastly exceed the return on that effort. Far better for that effort to be > directed towards the addition of IPv6 capabilities to existing IPv4 > deployments so as to minimize the impact of IPv4 exhaustion. here we disagree. Im all in favor of demonstrating 85% utilization of the IPv4 address pool before handing out new address space. --bill > > Owen > > On Apr 2, 2010, at 2:01 PM, Jeroen van Aart wrote: > > > I am curious. Once we're nearing exhausting all IPv4 space will there ever come a time to ask/demand/force returning all these legacy /8 allocations? I think I understand the difficulty in that, but then running out of IPs is also a difficult issue. :-) > > > > For some reason I sooner see all IPv4 space being exhausted than IPv6 being actually implemented globally. > > > > Greetings, > > Jeroen > > From bmanning at vacation.karoshi.com Fri Apr 2 19:14:14 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 3 Apr 2010 00:14:14 +0000 Subject: legacy /8 In-Reply-To: <4BB66ED2.6080304@mompl.net> References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> Message-ID: <20100403001414.GB9888@vacation.karoshi.com.> On Fri, Apr 02, 2010 at 03:25:22PM -0700, Jeroen van Aart wrote: > Cutler James R wrote: > >I also just got a fresh box of popcorn. I will sit by and wait > > I honestly am not trying to be a troll. It's just everytime I glance > over the IANA IPv4 Address Space Registry I feel rather annoyed about > all those /8s that were assigned back in the day without apparently > realising we might run out. its well to remember that when they got that space, the minimum allocation was a /8. you couldn't get anything smaller because "classful" addressing wasn;t invented yet. Only (much) later could you get "B" or "C" space... and after classful died in v4, we had CIDR. IPv6 as effectively reindroduced classful addressing. > Regards, > Jeroen --bill From bmanning at vacation.karoshi.com Fri Apr 2 19:20:58 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 3 Apr 2010 00:20:58 +0000 Subject: legacy /8 In-Reply-To: <3135E5A4-A45F-44A3-A01D-A86F71988E45@delong.com> References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> <3135E5A4-A45F-44A3-A01D-A86F71988E45@delong.com> Message-ID: <20100403002058.GC9888@vacation.karoshi.com.> On Fri, Apr 02, 2010 at 03:46:55PM -0700, Owen DeLong wrote: > > The expectation was that those /8s would be subnetted into vast arrays of "Class C" sized chunks and that subnets within a given /8 all had to be the same size (this used to be necessary to keep RIP happy and every machine participating in RIP routing had to have an /etc/netmasks (or equivalent) table that tracked "THE" subnet mask for each natural prefix). er, again, not true. the space was originally, net/host - the mantra was "bridge where you can, route when you must" - there were expected to be a few networks with millions of hosts within each broadcast domain. (anyone else remember the ARP storms of the 1970s/1980s?) routing came into its own later, along with classful addressing. > Owen > --bill From randy at psg.com Fri Apr 2 19:22:16 2010 From: randy at psg.com (Randy Bush) Date: Sat, 03 Apr 2010 09:22:16 +0900 Subject: legacy /8 In-Reply-To: <20100403000952.GA9888@vacation.karoshi.com.> References: <4BB65B39.8010902@mompl.net> Message-ID: ipv4 spae is not 'running out.' the rirs are running out of a free resource which they then rent to us. breaks my little black heart. even if, and that's an if, ipv6 takes off, ipv4 is gonna be around for a loooong while. when 95% of the world has end-to-end ipv6, do you think amazon et alia are gonna blow 5% of their market by decomissioning ipv4? we are gonna learn how to distribute and use ipv4 more efficiently. it's not that hard, we know how to do it. internet engineers have worked through and around a lot of problems, it's our job. making connectivity continue work for folk who, for whatever reason, delay migration from ipv4 is just part of our job. not to panic. the hard part is figuring out how the rirs make money off ipv4 holders redistributing it among themselves. if that becomes a non-goal, things get a lot simpler. randy From randy at psg.com Fri Apr 2 19:25:08 2010 From: randy at psg.com (Randy Bush) Date: Sat, 03 Apr 2010 09:25:08 +0900 Subject: legacy /8 In-Reply-To: <20100403001414.GB9888@vacation.karoshi.com.> References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> Message-ID: > IPv6 as effectively reindroduced classful addressing. but it's not gonna be a problem this time, right? after all, 32^h^h128^h^h^h64 bits is more than we will ever need, right? randy From bmanning at vacation.karoshi.com Fri Apr 2 19:32:28 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 3 Apr 2010 00:32:28 +0000 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> Message-ID: <20100403003228.GD9888@vacation.karoshi.com.> On Sat, Apr 03, 2010 at 09:25:08AM +0900, Randy Bush wrote: > > IPv6 as effectively reindroduced classful addressing. > > but it's not gonna be a problem this time, right? after all, > 32^h^h128^h^h^h64 bits is more than we will ever need, right? > > randy well... looking at a diet analogy, when .gt. 50% of your diet is HFCS and filler, its not real healthy. the way most folks are using IPv6, .gt. 50% of the bits are wasted as filler (got to love me some ::) so it seems like a lot, yet folks have already predicted the demise of IPv6 in the next 20years. (Klensin I think it was) --bill From deleskie at gmail.com Fri Apr 2 19:33:10 2010 From: deleskie at gmail.com (jim deleskie) Date: Fri, 2 Apr 2010 21:33:10 -0300 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> <20100403001414.GB9888@vacation.karoshi.com.> Message-ID: Just like 640k or memory :) On Fri, Apr 2, 2010 at 9:25 PM, Randy Bush wrote: >> IPv6 as effectively reindroduced classful addressing. > > but it's not gonna be a problem this time, right? ?after all, > 32^h^h128^h^h^h64 bits is more than we will ever need, right? > > randy > > From drc at virtualized.org Fri Apr 2 19:36:24 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 2 Apr 2010 14:36:24 -1000 Subject: legacy /8 In-Reply-To: <4BB68075.5050606@2mbit.com> References: <4BB65B39.8010902@mompl.net> <4BB68075.5050606@2mbit.com> Message-ID: <0E8F5308-A581-4970-B132-413009DD0E0B@virtualized.org> On Apr 2, 2010, at 1:40 PM, Brielle Bruns wrote: > Take back all the IP space from China and give them a single /20 and tell them to make do. At current consumption rates, that'd buy us another year or so. Then what? Regards, -drc From bruns at 2mbit.com Fri Apr 2 19:49:58 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 02 Apr 2010 18:49:58 -0600 Subject: legacy /8 In-Reply-To: <0E8F5308-A581-4970-B132-413009DD0E0B@virtualized.org> References: <4BB65B39.8010902@mompl.net> <4BB68075.5050606@2mbit.com> <0E8F5308-A581-4970-B132-413009DD0E0B@virtualized.org> Message-ID: <4BB690B6.80204@2mbit.com> On 4/2/10 6:36 PM, David Conrad wrote: > On Apr 2, 2010, at 1:40 PM, Brielle Bruns wrote: >> Take back all the IP space from China and give them a single /20 and tell them to make do. > > At current consumption rates, that'd buy us another year or so. Then what? > > Regards, > -drc > To quote: "we get some IP space back to buy us more time" Didn't say it was a solution, but we're all talking about buying more time for ipv6 transition. Its no worse then any other suggestion people have proposed. :) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From cabenth at gmail.com Fri Apr 2 19:58:04 2010 From: cabenth at gmail.com (eric clark) Date: Fri, 2 Apr 2010 17:58:04 -0700 Subject: Anyone observing latency and dropped packets at peering points in Seattle? Message-ID: I've been troubleshooting an issue all day. Traffic leaving our site, on Verizon public transport, destined for the Spokane area is routing to Qwest and hitting 400ms rapidly. The offending router seems to be a Verizon router (number 6 here). On top of that, we're seeing this via Level3 coming in from Spokane towards Seattle (targeting our Verizon IPs). 3. 116.atm2-0.xr2.sea4.alter.net 0.0% 8143 7.4 1.7 1.1 100.6 10.3 4. 0.so-6-0-0.xt2.sea1.alter.net 0.0% 8143 2.6 4.2 2.1 148.5 14.8 5. pos7-0.br1.sea1.alter.net 0.0% 8142 2.6 2.2 2.0 38.1 1.6 6. 204.255.169.30 0.0% 8142 431.3 405.0 320.2 469.8 22.2 7. sea-core-01.inet.qwest.net 0.0% 8142 430.5 407.3 324.0 541.3 24.2 8. spk-core-01.inet.qwest.net 0.0% 8142 440.4 414.0 324.9 470.6 22.2 9. spk-edge-04.inet.qwest.net 0.0% 8142 441.1 414.9 323.7 539.6 22.6 Testing on XO looks a lot different. 66.236.9.5.ptr.us.xo.net - 1 | 1034 | 1031 | 1 | 47 | 112 | 53 | | p6-0-0d0.mar1.seattle-wa.us.xo.net - 1 | 1033 | 1030 | 1 | 48 | 170 | 50 | | p4-2-0d0.rar1.seattle-wa.us.xo.net - 1 | 1033 | 1031 | 1 | 47 | 168 | 51 | | te-3-1-0.rar3.seattle-wa.us.xo.net - 0 | 1033 | 1033 | 2 | 46 | 170 | 54 | | 207.88.13.145.ptr.us.xo.net - 1 | 1033 | 1032 | 1 | 48 | 113 | 52 | | 216.156.100.18.ptr.us.xo.net - 0 | 1033 | 1033 | 2 | 49 | 297 | 50 | | agg1-sea-p10.bb.spectrumnet.us - 0 | 1033 | 1033 | 2 | 47 | 239 | 52 | |tierpoint-sea-1000m.demarc.spectrumnet.us - 1 | 1033 | 1032 | 9 | 54 | 249 | 56 | Any assistance would be appreciated, confirmation would be excellent, this is causing issues. Thank you E ps - I will turn off my MTR shortly, I don't use it much anymore. From jimb at jsbc.cc Fri Apr 2 20:00:00 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Fri, 02 Apr 2010 18:00:00 -0700 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> Message-ID: <4BB69310.7080205@jsbc.cc> On 4/2/2010 17:22, Randy Bush wrote: > ipv4 spae is not 'running out.' the rirs are running out of a free > resource which they then rent to us. breaks my little black heart. > > even if, and that's an if, ipv6 takes off, ipv4 is gonna be around for a > loooong while. when 95% of the world has end-to-end ipv6, do you think > amazon et alia are gonna blow 5% of their market by decomissioning ipv4? > > we are gonna learn how to distribute and use ipv4 more efficiently. > it's not that hard, we know how to do it. internet engineers have > worked through and around a lot of problems, it's our job. making > connectivity continue work for folk who, for whatever reason, delay > migration from ipv4 is just part of our job. not to panic. > > the hard part is figuring out how the rirs make money off ipv4 holders > redistributing it among themselves. if that becomes a non-goal, things > get a lot simpler. > So, jump through hoops to kludge up IPv4 so it continues to provide address space for new allocations through multiple levels of NAT (or whatever), and buy a bit more time, or jump through the hoops required to deploy IPv6 and eliminate the exhaustion problem? And also, if the IPv4 space is horse-traded among RIRs and customers as you allude to above, IPv6 will look even more attactive as the price and preciousness of IPv4 addresses increases. The idea isn't for IPv4 to be replaced (decommissioned). The idea is for IPv6 to be added, then things will slowly transition. IPv4 will be around for a long time indeed, but increasingly, new sites/services, and old sites/services will be adding IPv6 as a way to connect to them. Then at some point, IPv6 will become the "normal" way to connect, and IPv4 will be a the "legacy" way, with fewer and fewer using it. Also, reading your other post, if you don't understand the difference between 2^32 and 2^128, please start here: http://en.wikipedia.org/wiki/Exponential_growth Anyway, I see it as pretty much moot, since many major players (Comcast, Google, etc) are in the midst of major IPv6 deployments as we speak. Eventually you will have to jump on the bandwagon too. :-) - Jim From LarrySheldon at cox.net Fri Apr 2 20:20:46 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 02 Apr 2010 20:20:46 -0500 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> Message-ID: <4BB697EE.4000301@cox.net> On 4/2/2010 19:25, Randy Bush wrote: >> IPv6 as effectively reindroduced classful addressing. > > but it's not gonna be a problem this time, right? after all, > 32^h^h128^h^h^h64 bits is more than we will ever need, right? Just like last time. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From dwhite at olp.net Fri Apr 2 20:36:56 2010 From: dwhite at olp.net (Dan White) Date: Fri, 2 Apr 2010 20:36:56 -0500 Subject: legacy /8 In-Reply-To: <20100403000952.GA9888@vacation.karoshi.com.> References: <4BB65B39.8010902@mompl.net> <20100403000952.GA9888@vacation.karoshi.com.> Message-ID: <20100403013656.GB4788@dan.olp.net> On 03/04/10?00:09?+0000, bmanning at vacation.karoshi.com wrote: >On Fri, Apr 02, 2010 at 03:13:16PM -0700, Owen DeLong wrote: >> Sigh... Guess you missed the last several go-arounds of >> >> Running out of IPv4 will create some hardships. That cannot be avoided. > > we won't run out, we won't exaust, we are -NOT- killing the last tuna. > what we are doing is roughly what was anticipated in RFC 2050, we will > get more efficent utilization of all the space. That statement becomes less truthy when more realistic definitions of 'we' are used. I'd suggest that attempts to stretch v4 addresses is going to fall over on its side, for large segments of we. Address exchanges on the free market, and RIR reclamation will certainly be sufficient for other large segments. However, there will be a point in the next 3-5 years in which neither of these methods will be able to keep up with the tide of technological advancement. >> Even if we were to reclaim the supposed unused legacy /8s, we'd still >> only extend the date of IPv4 runout by a few months. > > wrong analogy. there won't be "green field" space - but there will > still be lots to go around... for legacy style use (e.g. the Internet > as we know it today) -- want to do something different? then use IPv6. I already feel like a dinosaur sitting in front of my desktop, with a keyboard. The Internet as we know it today only has 2-3 years of v4 address supply left. The more we stretch address usage, the more we create something that does not resemble the Internet as we know it today. >> The amount of effort required to reclaim those few IPv4 addresses would >> vastly exceed the return on that effort. Far better for that effort to be >> directed towards the addition of IPv6 capabilities to existing IPv4 >> deployments so as to minimize the impact of IPv4 exhaustion. > > here we disagree. Im all in favor of demonstrating 85% utilization > of the IPv4 address pool before handing out new address space. -- Dan White From james.cutler at consultant.com Fri Apr 2 21:11:00 2010 From: james.cutler at consultant.com (Cutler James R) Date: Fri, 2 Apr 2010 22:11:00 -0400 Subject: legacy /8 In-Reply-To: <3135E5A4-A45F-44A3-A01D-A86F71988E45@delong.com> References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> <3135E5A4-A45F-44A3-A01D-A86F71988E45@delong.com> Message-ID: <8A9ABFA0-2ACF-441B-9310-5000AB272F95@consultant.com> The last time I discussed IP Address needs with a company the builds automobiles, they wanted forty million addresses for robots, sensors, and the like for manufacturing. A single /8, were it available, would only yield about 20% of that requirement. On Apr 2, 2010, at 6:46 PM, Owen DeLong wrote: > Sure, a /8 is a lot of addresses in today's world. James R. Cutler james.cutler at consultant.com From gbonser at seven.com Fri Apr 2 21:13:09 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 2 Apr 2010 19:13:09 -0700 Subject: legacy /8 In-Reply-To: <4BB69310.7080205@jsbc.cc> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Jim Burwell [mailto:jimb at jsbc.cc] > Sent: Friday, April 02, 2010 6:00 PM > To: nanog at nanog.org > Subject: Re: legacy /8 > So, jump through hoops to kludge up IPv4 so it continues to provide > address space for new allocations through multiple levels of NAT (or > whatever), and buy a bit more time, or jump through the hoops required > to deploy IPv6 and eliminate the exhaustion problem? And also, if the > IPv4 space is horse-traded among RIRs and customers as you allude to > above, IPv6 will look even more attactive as the price and preciousness > of IPv4 addresses increases. No problem, everyone tunnels v4 in v4 and the "outer" ip address is your 32-bit ASN and you get an entire /0 of "legacy" ip space inside your ASN. Just need to get rid of BGP and go to some sort of label switching with the border routers having an ASN to upstream label table and there ya go. Oh, and probably create an AA RR in DNS that is in ASN:x.x.x.x format. Increase the MTU a little and whammo! There ya go! Done. :) From deleskie at gmail.com Fri Apr 2 21:17:28 2010 From: deleskie at gmail.com (jim deleskie) Date: Fri, 2 Apr 2010 23:17:28 -0300 Subject: legacy /8 In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> Message-ID: I'm old but maybe not old nuff to know if this was discussed before or not, but I've been asking people last few months why we don't just do something like this. don't even need to get rid of BGP, just add some extension, we see ok to add extensions to BGP to do other things, this makes at least if not more sence. -jim On Fri, Apr 2, 2010 at 11:13 PM, George Bonser wrote: > > >> -----Original Message----- >> From: Jim Burwell [mailto:jimb at jsbc.cc] >> Sent: Friday, April 02, 2010 6:00 PM >> To: nanog at nanog.org >> Subject: Re: legacy /8 > > >> So, jump through hoops to kludge up IPv4 so it continues to provide >> address space for new allocations through multiple levels of NAT (or >> whatever), and buy a bit more time, or jump through the hoops required >> to deploy IPv6 and eliminate the exhaustion problem? ?And also, if the >> IPv4 space is horse-traded among RIRs and customers as you allude to >> above, IPv6 will look even more attactive as the price and > preciousness >> of IPv4 addresses increases. > > No problem, ?everyone tunnels v4 in v4 and the "outer" ip address is > your 32-bit ASN and you get an entire /0 of "legacy" ip space inside > your ASN. ?Just need to get rid of BGP and go to some sort of label > switching with the border routers having an ASN to upstream label table > and there ya go. Oh, and probably create an AA RR in DNS that is in > ASN:x.x.x.x format. ?Increase the MTU a little and whammo! ?There ya go! > Done. > > :) > > > From nanog2 at adns.net Fri Apr 2 21:29:20 2010 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Fri, 2 Apr 2010 21:29:20 -0500 Subject: legacy /8 References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc><5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> Message-ID: Is someone volunteering to work on an RFC? Or, has someone done so for this already? ----- Original Message ----- From: "jim deleskie" To: Sent: Friday, April 02, 2010 9:17 PM Subject: Re: legacy /8 I'm old but maybe not old nuff to know if this was discussed before or not, but I've been asking people last few months why we don't just do something like this. don't even need to get rid of BGP, just add some extension, we see ok to add extensions to BGP to do other things, this makes at least if not more sence. -jim On Fri, Apr 2, 2010 at 11:13 PM, George Bonser wrote: > > >> -----Original Message----- >> From: Jim Burwell [mailto:jimb at jsbc.cc] >> Sent: Friday, April 02, 2010 6:00 PM >> To: nanog at nanog.org >> Subject: Re: legacy /8 > > >> So, jump through hoops to kludge up IPv4 so it continues to provide >> address space for new allocations through multiple levels of NAT (or >> whatever), and buy a bit more time, or jump through the hoops required >> to deploy IPv6 and eliminate the exhaustion problem? And also, if the >> IPv4 space is horse-traded among RIRs and customers as you allude to >> above, IPv6 will look even more attactive as the price and > preciousness >> of IPv4 addresses increases. > > No problem, everyone tunnels v4 in v4 and the "outer" ip address is > your 32-bit ASN and you get an entire /0 of "legacy" ip space inside > your ASN. Just need to get rid of BGP and go to some sort of label > switching with the border routers having an ASN to upstream label table > and there ya go. Oh, and probably create an AA RR in DNS that is in > ASN:x.x.x.x format. Increase the MTU a little and whammo! There ya go! > Done. > > :) > > > From swmike at swm.pp.se Fri Apr 2 21:31:13 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 3 Apr 2010 04:31:13 +0200 (CEST) Subject: legacy /8 In-Reply-To: <154EDE9026B3D54F883B20F2BBDCF87953A22981@exbe01.windows.riversidecg.com> References: <4BB65B39.8010902@mompl.net> <154EDE9026B3D54F883B20F2BBDCF87953A22981@exbe01.windows.riversidecg.com> Message-ID: On Fri, 2 Apr 2010, Joe Johnson wrote: > Maybe encourage people like Apple, Xerox, HP or Ford to migrate their > operations completely to IPv6 and return their /8? Perhaps 45.0.0.0/8 can start, that shouldn't be too hard to migrate out of? :P -- Mikael Abrahamsson email: swmike at swm.pp.se From gbonser at seven.com Fri Apr 2 21:37:14 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 2 Apr 2010 19:37:14 -0700 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc><5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6C6B@RWC-EX1.corp.seven.com> > -----Original Message----- > From: jim deleskie > Sent: Friday, April 02, 2010 7:17 PM > To: nanog at nanog.org > Subject: Re: legacy /8 > > I'm old but maybe not old nuff to know if this was discussed before or > not, but I've been asking people last few months why we don't just do > something like this. don't even need to get rid of BGP, just add some > extension, we see ok to add extensions to BGP to do other things, this > makes at least if not more sence. > > > -jim > We wouldn't really need to get rid of BGP, it would just be that there would be potentially one route per ASN with no (or very little) aggregation. Some form of label switching where you map ASNs to peers might just be a little more efficient as you would only see the number of labels that you have peers. If the vendors are prepared to grow their capabilities along with the number of ASNs assigned, then there is no problem. Currently that would not be a problem. There are only 56,218 allocated 16-bit ASNs and 5120 allocated 32-bit ASNs for a current total of only about 61,000-ish "routes". Any peering router in use today that takes full routes would be able to handle this in its sleep. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Apr 2 21:42:20 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 3 Apr 2010 13:12:20 +1030 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> Message-ID: <20100403131220.5dce0bbc@opy.nosense.org> On Fri, 02 Apr 2010 15:38:26 -0700 Andrew Gray <3356 at blargh.com> wrote: > Jeroen van Aart writes: > > > Cutler James R wrote: > >> I also just got a fresh box of popcorn. I will sit by and wait > > > > I honestly am not trying to be a troll. It's just everytime I glance over > > the IANA IPv4 Address Space Registry I feel rather annoyed about all those > > /8s that were assigned back in the day without apparently realising we > > might run out. > > > > It was explained to me that many companies with /8s use it for their > > internal network and migrating to 10/8 instead is a major pain. > > You know, I've felt the same irritation before, but one thing I am wondering > and perhaps some folks around here have been around long enough to know - > what was the original thinking behind doing those /8s? > > I understand that they were A classes and assigned to large companies, etc. > but was it just not believed there would be more than 126(-ish) of these > entities at the time? Or was it thought we would move on to larger address > space before we did? Or was it that things were just more free-flowing back > in the day? Why were A classes even created? RFC 791 at least doesn't seem > to provide much insight as to the 'whys'. > That's because RFC791 is a long way from the original design assumptions of the Internet Protocols. "A Protocol for Packet Network Intercommunication", Vinton G. Cerf and Robert E. Kahn, 1974, says - "The choice for network identification (8 bits) allows up to 256 distinct networks. This size seems sufficient for the foreseeable future." That view seems to have persisted up until at least RFC761, January 1980, which still specified the single 8 bit network, 24 bit node address format. RFC791, September 1981, introduces classes. So somewhere within that period it was recognised that 256 networks wasn't going to be enough. I'm not sure why the 32 bit address size was persisted with at that point - maybe it was because there would be significant performance loss in handling addresses greater than what was probably the most common host word size at the time. If you start looking into the history of IPv4 addressing, and arguably why it is so hard to understand and teach compared to other protocols such as Novell's IPX, Appletalk etc., everything that has been added to allow increasing the use of IP (classes, subnets, classless) while avoiding increasing the address size past 32 bits is a series of very neat hacks. IPv4 is a 1970s protocol that has had to cope with dramatic and unforeseen success. It's not a state of the art protocol any more, and shouldn't be used as an example of how things should be done today (As a minimum, I think later protocols like Novell's IPX and Appletalk are far better candidates). It is, however, a testament to how successfully something can be hacked over time to continue to work far, far beyond it's original design parameters and assumptions. (IMO, if you want to understand the design philosophies of IPv6 you're better off studying IPX and Appletalk than using your IPv4 knowledge. I think IPv6 is a much closer relative to those protocols than it is to IPv4. For example, router anycast addresses was implemented and used in Appletalk.) Possibly Vint Cerf might be willing to clear up some of these questions about the origins of IPv4 addressing. Regards, Mark. From Valdis.Kletnieks at vt.edu Fri Apr 2 21:47:46 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 02 Apr 2010 22:47:46 -0400 Subject: legacy /8 In-Reply-To: Your message of "Fri, 02 Apr 2010 18:49:58 MDT." <4BB690B6.80204@2mbit.com> References: <4BB65B39.8010902@mompl.net> <4BB68075.5050606@2mbit.com> <0E8F5308-A581-4970-B132-413009DD0E0B@virtualized.org> <4BB690B6.80204@2mbit.com> Message-ID: <10291.1270262866@localhost> On Fri, 02 Apr 2010 18:49:58 MDT, Brielle Bruns said: > "we get some IP space back to buy us more time" > > Didn't say it was a solution, but we're all talking about buying more > time for ipv6 transition. Its no worse then any other suggestion people > have proposed. :) They've had plenty of time to plan ahead for this one. I'm having a really hard time finding any sympathy for any organization that is just now waking up to the fact that they need to do something. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gbonser at seven.com Fri Apr 2 21:53:14 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 2 Apr 2010 19:53:14 -0700 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net><4BB69310.7080205@jsbc.cc><5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> > -----Original Message----- > From: John Palmer (NANOG Acct) [mailto:nanog2 at adns.net] > Sent: Friday, April 02, 2010 7:29 PM > To: nanog at nanog.org > Subject: Re: legacy /8 > > Is someone volunteering to work on an RFC? Or, has someone done so for > this already? I have never heard of anything along that line. It is just something that has wandered through my mind from time to time wondering why nobody had ever done such a thing as it seems so easy. All you need is to increase the standard transit MTU a little bit so your encapsulation doesn't result in a bunch of additional packet fragmentation due to the encap overhead and create the new DNS AA RR and that would be about all that is required. If your network is an end user, you just announce one route ... your ASN ... to your transit providers and any peers. A transit operation announces their ASN and any they are collecting from peers. They hard part is getting all the end nodes to use IPIP tunneling as their primary protocol by default. It is doable but that is the hard part. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Apr 2 21:53:23 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 3 Apr 2010 13:23:23 +1030 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> Message-ID: <20100403132323.2dc0eade@opy.nosense.org> On Fri, 2 Apr 2010 21:29:20 -0500 "John Palmer \(NANOG Acct\)" wrote: > Is someone volunteering to work on an RFC? Or, has someone done so for this already? > Probably similar to this (and others that remove end-site knowledge from the Internet core) - The Locator Identifier Separation Protocol (LISP) http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_11-1/111_lisp.html > ----- Original Message ----- > From: "jim deleskie" > To: > Sent: Friday, April 02, 2010 9:17 PM > Subject: Re: legacy /8 > > > I'm old but maybe not old nuff to know if this was discussed before or > not, but I've been asking people last few months why we don't just do > something like this. don't even need to get rid of BGP, just add some > extension, we see ok to add extensions to BGP to do other things, this > makes at least if not more sence. > > > -jim > > On Fri, Apr 2, 2010 at 11:13 PM, George Bonser wrote: > > > > > >> -----Original Message----- > >> From: Jim Burwell [mailto:jimb at jsbc.cc] > >> Sent: Friday, April 02, 2010 6:00 PM > >> To: nanog at nanog.org > >> Subject: Re: legacy /8 > > > > > >> So, jump through hoops to kludge up IPv4 so it continues to provide > >> address space for new allocations through multiple levels of NAT (or > >> whatever), and buy a bit more time, or jump through the hoops required > >> to deploy IPv6 and eliminate the exhaustion problem? And also, if the > >> IPv4 space is horse-traded among RIRs and customers as you allude to > >> above, IPv6 will look even more attactive as the price and > > preciousness > >> of IPv4 addresses increases. > > > > No problem, everyone tunnels v4 in v4 and the "outer" ip address is > > your 32-bit ASN and you get an entire /0 of "legacy" ip space inside > > your ASN. Just need to get rid of BGP and go to some sort of label > > switching with the border routers having an ASN to upstream label table > > and there ya go. Oh, and probably create an AA RR in DNS that is in > > ASN:x.x.x.x format. Increase the MTU a little and whammo! There ya go! > > Done. > > > > :) > > > > > > > > > > From randy at psg.com Fri Apr 2 23:23:20 2010 From: randy at psg.com (Randy Bush) Date: Sat, 03 Apr 2010 13:23:20 +0900 Subject: legacy /8 In-Reply-To: <4BB69310.7080205@jsbc.cc> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> Message-ID: > Anyway, I see it as pretty much moot, since many major players (Comcast, > Google, etc) are in the midst of major IPv6 deployments as we speak. > Eventually you will have to jump on the bandwagon too. :-) clue0: the isp for which i work deployed ipv6 in the '90s. we were the world's first commercial ipv6 isp deployment. clue1: not only can i do the math, but i can remember history randy From gbonser at seven.com Sat Apr 3 00:06:24 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 2 Apr 2010 22:06:24 -0700 Subject: legacy /8 In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> References: <4BB65B39.8010902@mompl.net><4BB69310.7080205@jsbc.cc><5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> > -----Original Message----- > From: George Bonser [mailto:gbonser at seven.com] > Sent: Friday, April 02, 2010 7:53 PM > To: John Palmer (NANOG Acct); nanog at nanog.org > Subject: RE: legacy /8 > > They hard part is getting all the end nodes to use IPIP tunneling as > their primary protocol by default. It is doable but that is the hard > part. > > Actually, both methods could exist side by side. If a standard packet arrives, the destination AS is looked up using conventional routing information, it is encapsulated and sent to the destination AS. In other words, a standard packet is assumed to be a legacy address space packet. An encapsulated packet handled in the new way. But you know, the fact that the network techies has not exactly spent the past 10 years busting down the doors for v6 should tell people something really important. That they are willing to wait until the wolf is at the door to switch means something that needs to be paid your attention. v6 could well be the protocol that broke the Internet because it is sort of like replacing a Jeep with a bus built by Rube Goldberg. That adoption is so low at this point really says that it has failed. From bmanning at vacation.karoshi.com Sat Apr 3 00:09:04 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 3 Apr 2010 05:09:04 +0000 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> Message-ID: <20100403050904.GA12283@vacation.karoshi.com.> i had a bet w/ some folks when RFC 1918 came into existance. I postulated that it might be better for the "Internet" if the RFC 1918 space was used to address the "public" Internet and the rest of the space be used inside folks walled gardens... circa 1996 or so. --bill On Fri, Apr 02, 2010 at 11:17:28PM -0300, jim deleskie wrote: > I'm old but maybe not old nuff to know if this was discussed before or > not, but I've been asking people last few months why we don't just do > something like this. don't even need to get rid of BGP, just add some > extension, we see ok to add extensions to BGP to do other things, this > makes at least if not more sence. > > > -jim > > On Fri, Apr 2, 2010 at 11:13 PM, George Bonser wrote: > > > > > >> -----Original Message----- > >> From: Jim Burwell [mailto:jimb at jsbc.cc] > >> Sent: Friday, April 02, 2010 6:00 PM > >> To: nanog at nanog.org > >> Subject: Re: legacy /8 > > > > > >> So, jump through hoops to kludge up IPv4 so it continues to provide > >> address space for new allocations through multiple levels of NAT (or > >> whatever), and buy a bit more time, or jump through the hoops required > >> to deploy IPv6 and eliminate the exhaustion problem? And also, if the > >> IPv4 space is horse-traded among RIRs and customers as you allude to > >> above, IPv6 will look even more attactive as the price and > > preciousness > >> of IPv4 addresses increases. > > > > No problem, everyone tunnels v4 in v4 and the "outer" ip address is > > your 32-bit ASN and you get an entire /0 of "legacy" ip space inside > > your ASN. Just need to get rid of BGP and go to some sort of label > > switching with the border routers having an ASN to upstream label table > > and there ya go. Oh, and probably create an AA RR in DNS that is in > > ASN:x.x.x.x format. Increase the MTU a little and whammo! There ya go! > > Done. > > > > :) > > > > > > > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Apr 3 01:08:57 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 3 Apr 2010 16:38:57 +1030 Subject: legacy /8 In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> Message-ID: <20100403163857.3b852c95@opy.nosense.org> On Fri, 2 Apr 2010 22:06:24 -0700 "George Bonser" wrote: > > > > -----Original Message----- > > From: George Bonser [mailto:gbonser at seven.com] > > Sent: Friday, April 02, 2010 7:53 PM > > To: John Palmer (NANOG Acct); nanog at nanog.org > > Subject: RE: legacy /8 > > > > They hard part is getting all the end nodes to use IPIP tunneling as > > their primary protocol by default. It is doable but that is the hard > > part. > > > > > > Actually, both methods could exist side by side. If a standard packet > arrives, the destination AS is looked up using conventional routing > information, it is encapsulated and sent to the destination AS. In > other words, a standard packet is assumed to be a legacy address space > packet. An encapsulated packet handled in the new way. > > But you know, the fact that the network techies has not exactly spent > the past 10 years busting down the doors for v6 should tell people > something really important. That they are willing to wait until the > wolf is at the door to switch means something that needs to be paid your > attention. v6 could well be the protocol that broke the Internet > because it is sort of like replacing a Jeep with a bus built by Rube > Goldberg. > > That adoption is so low at this point really says that it has failed. > > > I think the Y2K incident was an example worth observing. There was a lot of talk about it from at least 1995 onwards. In my experience however proper efforts to address it seemed to only start early to mid 1998, with the first half of 1999 being "crunch time" with the last six months of 1999 left to finalise anything left over. IPv6 seems to be following a similar time line - we're around two years away from running out of IPv4 addresses, and there now seems to be a lot more discussion, planning and implementation happening in recent times than there has been in the last 5 years. Y2K was a bit different though - there was no alternative other than fixing it. "Carrier grade NAT" didn't exist for YY fields, so there is no actual deadline for IPv6 like there was for Y2K. I think that is what is leaving room for people to think they don't have to deploy it soon, or that it has failed. Regards, Mark. From jimb at jsbc.cc Sat Apr 3 01:47:36 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Fri, 02 Apr 2010 23:47:36 -0700 Subject: legacy /8 In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> Message-ID: <4BB6E488.9030003@jsbc.cc> On 4/2/2010 19:13, George Bonser wrote: > > >> -----Original Message----- >> From: Jim Burwell [mailto:jimb at jsbc.cc] >> Sent: Friday, April 02, 2010 6:00 PM >> To: nanog at nanog.org >> Subject: Re: legacy /8 >> > > >> So, jump through hoops to kludge up IPv4 so it continues to provide >> address space for new allocations through multiple levels of NAT (or >> whatever), and buy a bit more time, or jump through the hoops required >> to deploy IPv6 and eliminate the exhaustion problem? And also, if the >> IPv4 space is horse-traded among RIRs and customers as you allude to >> above, IPv6 will look even more attactive as the price and >> > preciousness > >> of IPv4 addresses increases. >> > No problem, everyone tunnels v4 in v4 and the "outer" ip address is > your 32-bit ASN and you get an entire /0 of "legacy" ip space inside > your ASN. Just need to get rid of BGP and go to some sort of label > switching with the border routers having an ASN to upstream label table > and there ya go. Oh, and probably create an AA RR in DNS that is in > ASN:x.x.x.x format. Increase the MTU a little and whammo! There ya go! > Done. > > :) > > So essentially add 32-bits to the IPv4 address, used as a ASN, and use legacy V4 on the "backbone" which tunnels everything, so the entire intra-ASN internet has to go through v4-in-v4 tunnels. A few "little" changes to DNS, and voila! And of course, there's no "devils in the details" we have to worry about. Heck. Just quote that last post up and submit it as an RFC to replace the IPv6 RFCs! :-) Seriously though, would that really be easier to implement, or be better than IPv6 as this point? I'd think the IETF would probably have considered solutions like that, but IPv6 is what we got. So best learn to love it. :P -Jim -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5570 bytes Desc: S/MIME Cryptographic Signature URL: From owen at delong.com Fri Apr 2 18:53:39 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Apr 2010 16:53:39 -0700 Subject: legacy /8 In-Reply-To: <4BB68075.5050606@2mbit.com> References: <4BB65B39.8010902@mompl.net> <4BB68075.5050606@2mbit.com> Message-ID: On Apr 2, 2010, at 4:40 PM, Brielle Bruns wrote: > On 4/2/10 3:01 PM, Jeroen van Aart wrote: >> I am curious. Once we're nearing exhausting all IPv4 space will there >> ever come a time to ask/demand/force returning all these legacy /8 >> allocations? I think I understand the difficulty in that, but then >> running out of IPs is also a difficult issue. :-) >> >> For some reason I sooner see all IPv4 space being exhausted than IPv6 >> being actually implemented globally. >> >> Greetings, >> Jeroen >> > > I've got a rather stupidly simple and straightforward plan, since we're all throwing ideas out. > > Take back all the IP space from China and give them a single /20 and tell them to make do. They're already behind a great firewall, so they should have no problem using NAT with their citizens for easier restricting of freedoms, and for the actual services they need to run, they can assign a limited amount of static IP addresses for servers, and the rest NAT as well, and port forward for specific services. > Probably not the biggest flaw in this plan, but: Total number of RFC-1918 addresses: 18+ million. Population of China: More than 1.325 billion. I'll leave the other political aspects to others, but, the math simply doesn't work. Owen From owen at delong.com Fri Apr 2 17:52:39 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Apr 2010 15:52:39 -0700 Subject: legacy /8 In-Reply-To: <9D78CBC7F28F40C5AF04DD2C8A40B25B@TAKA> References: <4BB65B39.8010902@mompl.net> <20100402210631.GA21373@puck.nether.net> <9D78CBC7F28F40C5AF04DD2C8A40B25B@TAKA> Message-ID: No, this is how the RIR process works. The RIRs request their next /8s and begin the "cleaning" process on them several months prior to running out of their previous allocations. This is done to try and make the allocations/assignments from those blocks as immediately useful as possible to their customers. I can assure you that RIRs are in the business of distributing IP resources within the policy guidelines set by the community. They have no gain from holding or hoarding them and are not in a position to do any such thing. Owen On Apr 2, 2010, at 3:48 PM, John Palmer (NANOG Acct) wrote: > On the topic of IP4 exhaustion: 1/8, 2/8 and 5/8 have all been assigned in the > last 3 months yet I don't see them being allocated out to customers (users) yet. > > Is this perhaps a bit of hoarding in advance of the complete depletion of /8's? > > ----- Original Message ----- From: "Majdi S. Abbas" > To: "Jeroen van Aart" > Cc: "NANOG list" > Sent: Friday, April 02, 2010 4:06 PM > Subject: Re: legacy /8 > > >> On Fri, Apr 02, 2010 at 02:01:45PM -0700, Jeroen van Aart wrote: >>> I am curious. Once we're nearing exhausting all IPv4 space will >>> there ever come a time to ask/demand/force returning all these >>> legacy /8 allocations? I think I understand the difficulty in that, >>> but then running out of IPs is also a difficult issue. :-) >>> For some reason I sooner see all IPv4 space being exhausted than >>> IPv6 being actually implemented globally. >> Because it's no more than a delaying action. Even presuming >> you get people to cooperate (and they really, have no incentive to >> because they don't necessarily have any agreement covering the space >> with the RIRs) rather than fire up their legal department.... >> A couple of /8s doesn't last long enough to really make a dent >> in the pain. You might buy yourself a few months at most. >> It might actually do more harm than good, by convincing people >> that they can still get v4 space rather than worry about what they >> are going to do in the future. >> --msa >> > From jimb at jsbc.cc Sat Apr 3 02:11:24 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Sat, 03 Apr 2010 00:11:24 -0700 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> Message-ID: <4BB6EA1C.8090108@jsbc.cc> On 4/2/2010 21:23, Randy Bush wrote: >> Anyway, I see it as pretty much moot, since many major players (Comcast, >> Google, etc) are in the midst of major IPv6 deployments as we speak. >> Eventually you will have to jump on the bandwagon too. :-) >> > clue0: the isp for which i work deployed ipv6 in the '90s. we were the > world's first commercial ipv6 isp deployment. > > clue1: not only can i do the math, but i can remember history > Heh. I didn't really doubt that you understood the math. Was just being a bit snarky. :p (this whole thread is sort of flame bait anyway hehe). Anyway, with just 2000::/3 alone, there's about 500 million /32s. According to the CIDR report, there's ~34,000 ASs in BGP right now. Lets double that "for future growth" just for fun. If we do that, it means if we divided those /32s evenly among all of those ASes, each would get about 7800 of them. Each one contains 64Ki /48s. And again, that's just one /3 of the entire v6 space (yeah I know they won't be divided evenly ... different sizes orgs, regional assignments, etc, etc, etc). Anyway, I think the addy space will tide us over for quite a while, even if it's "not enough" as your last post seemed to indicate. Hey, and if we ever do run out, we can just NAT! ;) ;) ;) -Jim From martin at hotze.com Sat Apr 3 02:45:33 2010 From: martin at hotze.com (Martin Hotze) Date: Sat, 3 Apr 2010 09:45:33 +0200 Subject: legacy /8 In-Reply-To: References: Message-ID: <275E689A52D3FD4E922743D02EAEA8FA329373@server1.hotze.local> > Date: Fri, 02 Apr 2010 15:25:22 -0700 > From: Jeroen van Aart > Subject: Re: legacy /8 > To: NANOG list > Message-ID: <4BB66ED2.6080304 at mompl.net> > > Cutler James R wrote: > > I also just got a fresh box of popcorn. I will sit by and wait > > I honestly am not trying to be a troll. It's just everytime I glance > over the IANA IPv4 Address Space Registry I feel rather annoyed about > all those /8s that were assigned back in the day without apparently > realising we might run out. Yes! We definitely *will* run out of poor men address space (IPv4, that is). The sooner the better. Don't keep the patient alive artificially and don't try to give those "ah, they said that IPv6 will come about 10 years ago, too" people any ideas [1]. Au contraire: use your v4-space as fast as possible. :-) #m [1] aren't you tired of all their excuses for NOT looking into IPv6? From jeroen at mompl.net Sat Apr 3 03:03:41 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Sat, 03 Apr 2010 01:03:41 -0700 Subject: legacy /8 In-Reply-To: <3135E5A4-A45F-44A3-A01D-A86F71988E45@delong.com> References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> <3135E5A4-A45F-44A3-A01D-A86F71988E45@delong.com> Message-ID: <4BB6F65D.4000907@mompl.net> Owen DeLong wrote: > It was thought that we would not have nearly so many people connected to the internet. It was expected that most things connecting to the internet would be minicomputers and mainframes. It took some visionary and creative thinking to "come up" with the internet. But given such a train of thought the idea of everyone being connected isn't such a wild idea. I can imagine it'd be almost a given. Although if I get the time frame right in those days you had 2 camps, those (ibm, dec...) who believed that there was no need for home computers and you only needed a few (hundred?) thousand big mainframes and minicomputers and those (commodore, apple...) who believed (rightfully so) there was going to be a big future and demand for home computers. So I guess depending on what "camp" you were in, it's not that strange to not envision all these household computers being interconnected. Greetings, Jeroen From mysidia at gmail.com Sat Apr 3 03:08:00 2010 From: mysidia at gmail.com (James Hess) Date: Sat, 3 Apr 2010 02:08:00 -0600 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> Message-ID: On Fri, Apr 2, 2010 at 9:17 PM, jim deleskie wrote: > not, but I've been asking people last few months why we don't just do > something like this. don't even need to get rid of BGP, just add some [snip] > On Fri, Apr 2, 2010 at 11:13 PM, George Bonser wrote: [snip]>> and there ya go. Oh, and probably create an AA RR in DNS that is in >> ASN:x.x.x.x format. ?Increase the MTU a little and whammo! ?There ya go! It's a good idea. But, it should be noted the 'end result' is not the only thing that matters, in regards to internet protocol, the transition mechanism you need to change and convince the community to change from using an old protocol and old methods to using a new protocol and new practices is almost everything --- stakeholders want no disruption to the stability, or end-to-end connectivity of the internet at any point in time -- if every network must update software, even in the same decade as each others' networks, the protocol change may be as good as dead, due to the relative infrequency of large providers updating equipment. The lack of a good well-thought-out transition mechanism can in effect be a show-stopper for any proposed change to widely-deployed existing protocol. IPv6 has 'dual stack'. It doesn't suffer the 1st problem, but its transition burden _still_ prevents universal IPv6 connectivity'. ASN routing would probably have a similar fate, unless someone came up with a bulletproof easy-as-pie transition mechanism (something preferably better than dual stack). So, how does a HTTP client indicate in the IP packet, the destination ASN obtained from looking up the value of this AA record? And how does that packet get to the web server at another provider, when the user's ISP or their ISP's upstream transit provider is not "ASN-routing-ready" yet......... Or do you suggest an internet flag day? Also, the socket peer of every IP transaction needs to know the source ASN, that means if you modify IP packets to add a 'destination ASN field', you also need a 'source ASN' field. Else there will be no way for the server to send return traffic with full IP information, or even complete TCP connection handshake reliably, especially in multi-homed scenarios. Another result is if either connection endpoint does not know about the new 'ASN packet labelling', they will be unable to properly label their return traffic (particularly in the case of multi-homed networks)... resulting in lack of ability to connect to each other, as the return traffic goes somewhere other than where expected ASN routing would also have some interesting implications for multi-homing in general. Introduces some potentially troubling scenarios where a malicious actor might find some advantage in the ability to force the ASN destination of arbitrary spoofed packets to something unnatural. -- -J From jimb at jsbc.cc Sat Apr 3 03:38:07 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Sat, 03 Apr 2010 01:38:07 -0700 Subject: legacy /8 In-Reply-To: <4BB6F65D.4000907@mompl.net> References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> <3135E5A4-A45F-44A3-A01D-A86F71988E45@delong.com> <4BB6F65D.4000907@mompl.net> Message-ID: <4BB6FE6F.700@jsbc.cc> On 4/3/2010 01:03, Jeroen van Aart wrote: > Owen DeLong wrote: >> It was thought that we would not have nearly so many people connected >> to the internet. It was expected that most things connecting to the >> internet would be minicomputers and mainframes. > > It took some visionary and creative thinking to "come up" with the > internet. But given such a train of thought the idea of everyone being > connected isn't such a wild idea. I can imagine it'd be almost a given. > > Although if I get the time frame right in those days you had 2 camps, > those (ibm, dec...) who believed that there was no need for home > computers and you only needed a few (hundred?) thousand big mainframes > and minicomputers and those (commodore, apple...) who believed > (rightfully so) there was going to be a big future and demand for home > computers. > > So I guess depending on what "camp" you were in, it's not that strange > to not envision all these household computers being interconnected. > Hindsight is always 20/20. But remember that the internet started as a DoD project with just the military, mil contractors, universities, etc, connected to it. At first it wasn't even envisioned as something the general public would even use. And back in those times having a computer at home was still a fairly unusual thing. Only "geeks" had them (I remember kids poking fun at me back in middle school when they found out I had a home computer). Back then, during the "computer revolution", you used a modem to connect to BBSes, services like Compu$serve, and perhaps the UUCP network for email and usenet. The internet was something only big orgs, corps, universities, and the military had. So it's not *too* surprising that the "explosion" that happened after the web browser/server came into being was a bit of a surprise for people. And it wasn't all that long after the explosion that I started hearing about things like "IP-NG", etc (for a while I thought IPv6 would use OSI NSAPs hehe). So they got busy addressing the problem pretty quickly, despite having not predicted such a big explosion in internet use. Of course my memory could be a bit foggy, but there are guys on this list who were on the leading edge of all this who could (and probably have) tell the whole story in more detail. :) -Jim From adrian at creative.net.au Sat Apr 3 05:52:37 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Sat, 3 Apr 2010 18:52:37 +0800 Subject: Books for the NOC guys... In-Reply-To: <86wrwqukcm.fsf@seastrom.com> References: <86wrwqukcm.fsf@seastrom.com> Message-ID: <20100403105237.GC31245@skywalker.creative.net.au> On Fri, Apr 02, 2010, Robert E. Seastrom wrote: > So, what are you having your up-and-coming NOC staff read? Since I thought this was worthwhile summarising, I've dumped it on the mail topics page in the Wiki: http://nanog.cluepon.net/index.php/MailTopics I specifically left out the programming language related ranting. Adrian From rsk at gsp.org Sat Apr 3 06:49:45 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 3 Apr 2010 07:49:45 -0400 Subject: legacy /8 In-Reply-To: <4BB65B39.8010902@mompl.net> References: <4BB65B39.8010902@mompl.net> Message-ID: <20100403114945.GB9479@gsp.org> A more productive approach might, and I emphasize *might*, be to identify those allocations which are hijacked and/or in use by dedicated abuse operations. This would have the desirable side effect of depriving those operations of resources, however it would also saddle subsequent owners with the thorny problem of trying to use heavily-blacklisted allocations. And as others in the thread have observed, it would only delay the inevitable for a while. ---Rsk From jeffrey.lyon at blacklotus.net Sat Apr 3 07:06:44 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 3 Apr 2010 08:06:44 -0400 Subject: legacy /8 In-Reply-To: <4BB6FE6F.700@jsbc.cc> References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> <3135E5A4-A45F-44A3-A01D-A86F71988E45@delong.com> <4BB6F65D.4000907@mompl.net> <4BB6FE6F.700@jsbc.cc> Message-ID: People use IPv4 because it's cost effective to do so. When I only have to pay $1250 per year for a /21 there is little incentive to heavily restrict the use of that space. People are buying dedicated servers every day with /29 - /24 of space using very questionable justification and any justification that is provided is difficult and labor intensive to validate. If the cost of IP space were to go up dramatically many organizations would suddenly decide that they don't need a /18 - longer and therefore would go back to getting smaller allocations from their ISP, returning some space, and/or planning the use of space much more carefully. Supply and demand will run it's course. For small companies the cost of moving to IPv6 is far too great, especially when we rely on certain DDoS mitigation gear that does not yet have an IPv6 equivalent. Jeff On Sat, Apr 3, 2010 at 4:38 AM, Jim Burwell wrote: > On 4/3/2010 01:03, Jeroen van Aart wrote: >> Owen DeLong wrote: >>> It was thought that we would not have nearly so many people connected >>> to the internet. ?It was expected that most things connecting to the >>> internet would be minicomputers and mainframes. >> >> It took some visionary and creative thinking to "come up" with the >> internet. But given such a train of thought the idea of everyone being >> connected isn't such a wild idea. I can imagine it'd be almost a given. >> >> Although if I get the time frame right in those days you had 2 camps, >> those (ibm, dec...) who believed that there was no need for home >> computers and you only needed a few (hundred?) thousand big mainframes >> and minicomputers and those (commodore, apple...) who believed >> (rightfully so) there was going to be a big future and demand for home >> computers. >> >> So I guess depending on what "camp" you were in, it's not that strange >> to not envision all these household computers being interconnected. >> > Hindsight is always 20/20. ?But remember that the internet started as a > DoD project with just the military, mil contractors, universities, etc, > connected to it. ?At first it wasn't even envisioned as something the > general public would even use. ?And back in those times having a > computer at home was still a fairly unusual thing. ?Only "geeks" had > them (I remember kids poking fun at me back in middle school when they > found out I had a home computer). ?Back then, during the "computer > revolution", you used a modem to connect to BBSes, services like > Compu$serve, and perhaps the UUCP network for email and usenet. ?The > internet was something only big orgs, corps, universities, and the > military had. > > So it's not *too* surprising that the "explosion" that happened after > the web browser/server came into being was a bit of a surprise for > people. ?And it wasn't all that long after the explosion that I started > hearing about things like "IP-NG", etc (for a while I thought IPv6 would > use OSI NSAPs hehe). ?So they got busy addressing the problem pretty > quickly, despite having not predicted such a big explosion in internet > use. ?Of course my memory could be a bit foggy, but there are guys on > this list who were on the leading edge of all this who could (and > probably have) tell the whole story in more detail. ?:) > > -Jim > > > > -- 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 deleskie at gmail.com Sat Apr 3 08:49:49 2010 From: deleskie at gmail.com (jim deleskie) Date: Sat, 3 Apr 2010 10:49:49 -0300 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> Message-ID: I haven't seen anything, not to say there isn't, but I would certainly be open to the idea. From an operational point of view to me it seems much more straight forward then v6. -jim On Fri, Apr 2, 2010 at 11:29 PM, John Palmer (NANOG Acct) wrote: > Is someone volunteering to work on an RFC? ?Or, has someone done so for this > already? > > ----- Original Message ----- From: "jim deleskie" > To: > Sent: Friday, April 02, 2010 9:17 PM > Subject: Re: legacy /8 > > > I'm old but maybe not old nuff to know if this was discussed before or > not, but I've been asking people last few months why we don't just do > something like this. don't even need to get rid of BGP, just add some > extension, we see ok to add extensions to BGP to do other things, this > makes at least if not more sence. > > > -jim > > On Fri, Apr 2, 2010 at 11:13 PM, George Bonser wrote: >> >> >>> -----Original Message----- >>> From: Jim Burwell [mailto:jimb at jsbc.cc] >>> Sent: Friday, April 02, 2010 6:00 PM >>> To: nanog at nanog.org >>> Subject: Re: legacy /8 >> >> >>> So, jump through hoops to kludge up IPv4 so it continues to provide >>> address space for new allocations through multiple levels of NAT (or >>> whatever), and buy a bit more time, or jump through the hoops required >>> to deploy IPv6 and eliminate the exhaustion problem? And also, if the >>> IPv4 space is horse-traded among RIRs and customers as you allude to >>> above, IPv6 will look even more attactive as the price and >> >> preciousness >>> >>> of IPv4 addresses increases. >> >> No problem, everyone tunnels v4 in v4 and the "outer" ip address is >> your 32-bit ASN and you get an entire /0 of "legacy" ip space inside >> your ASN. Just need to get rid of BGP and go to some sort of label >> switching with the border routers having an ASN to upstream label table >> and there ya go. Oh, and probably create an AA RR in DNS that is in >> ASN:x.x.x.x format. Increase the MTU a little and whammo! There ya go! >> Done. >> >> :) >> >> >> > > > > > From deleskie at gmail.com Sat Apr 3 08:55:13 2010 From: deleskie at gmail.com (jim deleskie) Date: Sat, 3 Apr 2010 10:55:13 -0300 Subject: legacy /8 In-Reply-To: <4BB6E488.9030003@jsbc.cc> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <4BB6E488.9030003@jsbc.cc> Message-ID: Not sure the IETF looked at it or not, but personally I'm one of those people that has never accepted a solution just because, its the only option there. I haven't always won my battles, but never just give in :) -jim On Sat, Apr 3, 2010 at 3:47 AM, Jim Burwell wrote: > On 4/2/2010 19:13, George Bonser wrote: >> >> >>> -----Original Message----- >>> From: Jim Burwell [mailto:jimb at jsbc.cc] >>> Sent: Friday, April 02, 2010 6:00 PM >>> To: nanog at nanog.org >>> Subject: Re: legacy /8 >>> >> >> >>> So, jump through hoops to kludge up IPv4 so it continues to provide >>> address space for new allocations through multiple levels of NAT (or >>> whatever), and buy a bit more time, or jump through the hoops required >>> to deploy IPv6 and eliminate the exhaustion problem? ?And also, if the >>> IPv4 space is horse-traded among RIRs and customers as you allude to >>> above, IPv6 will look even more attactive as the price and >>> >> preciousness >> >>> of IPv4 addresses increases. >>> >> No problem, ?everyone tunnels v4 in v4 and the "outer" ip address is >> your 32-bit ASN and you get an entire /0 of "legacy" ip space inside >> your ASN. ?Just need to get rid of BGP and go to some sort of label >> switching with the border routers having an ASN to upstream label table >> and there ya go. Oh, and probably create an AA RR in DNS that is in >> ASN:x.x.x.x format. ?Increase the MTU a little and whammo! ?There ya go! >> Done. >> >> :) >> >> > So essentially add 32-bits to the IPv4 address, used as a ASN, and use > legacy V4 on the "backbone" which tunnels everything, so the entire > intra-ASN internet has to go through v4-in-v4 tunnels. ?A few "little" > changes to DNS, and voila! ?And of course, there's no "devils in the > details" we have to worry about. ?Heck. ? ?Just quote that last post up > and submit it as an RFC to replace the IPv6 RFCs! ?:-) > > Seriously though, would that really be easier to implement, or be better > than IPv6 as this point? ?I'd think the IETF would probably have > considered solutions like that, but IPv6 is what we got. ?So best learn > to love it. ?:P > > -Jim > > > From deleskie at gmail.com Sat Apr 3 08:57:59 2010 From: deleskie at gmail.com (jim deleskie) Date: Sat, 3 Apr 2010 10:57:59 -0300 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> Message-ID: James, I agree with you concern, and as someone else said the devil is in the details, you points are something that would need to be looked at if enough people though we should move forward and look at an idea like this, which I think we should, but not sure if enough traffic to start down that road yet. If we do though, this is the kind of input we'd need. -jim On Sat, Apr 3, 2010 at 5:08 AM, James Hess wrote: > On Fri, Apr 2, 2010 at 9:17 PM, jim deleskie wrote: >> not, but I've been asking people last few months why we don't just do >> something like this. don't even need to get rid of BGP, just add some > [snip] >> On Fri, Apr 2, 2010 at 11:13 PM, George Bonser wrote: > [snip]>> and there ya go. Oh, and probably create an AA RR in DNS that is in >>> ASN:x.x.x.x format. ?Increase the MTU a little and whammo! ?There ya go! > > It's a good idea. ? ?But, it should be noted the ?'end result' ? ?is > not the only thing that matters, ?in regards to internet protocol, > the ? transition mechanism you need to change and convince the > community to change from using an old protocol and old methods to > using a new protocol and new practices ?is almost everything --- > stakeholders want no disruption to the stability, or end-to-end > connectivity of the internet ?at any point in time -- ?if every > network must update software, ?even in the same decade as each others' > networks, ?the ?protocol change may be as good as dead, ? due to the > relative infrequency of large providers updating equipment. > > The lack of a good ?well-thought-out transition mechanism can in > effect be a show-stopper ?for any proposed change to widely-deployed > existing protocol. > > > IPv6 ?has 'dual stack'. ? ?It ?doesn't suffer the 1st problem, but > its transition burden _still_ ? prevents ?universal IPv6 > connectivity'. ? ? ASN routing would probably have a similar fate, > unless someone came up with a bulletproof easy-as-pie transition > mechanism ?(something preferably better than dual stack). > > > > So, ?how does a HTTP client indicate in the IP packet, ?the > destination ASN ?obtained from looking up the value of this AA record? > ? ?And how does that packet get to the web server ?at another > provider, ?when the user's ISP or their ISP's ?upstream transit > provider is not ?"ASN-routing-ready" yet......... > > Or do you suggest an internet flag day? > > Also, ?the socket peer of every IP transaction needs to know the > source ASN, ?that means if you modify IP packets to add a > 'destination ASN field', ?you also need a 'source ASN' ?field. > > Else there will be no way for the server to send return traffic with > full IP information, or even complete TCP connection handshake > reliably, ?especially ?in ?multi-homed scenarios. > > Another result is if either connection endpoint ?does not know about > the new 'ASN packet labelling', ? they ?will ?be ?unable to properly > label their return traffic ? (particularly in the case of ?multi-homed > networks)... ?resulting in lack of ability to connect to each other, > as the return traffic ?goes somewhere other than where expected > > ASN routing would also have some interesting ?implications for > multi-homing in general. ? ?Introduces some potentially troubling > scenarios where a malicious actor might find some advantage in the > ability to force the ASN destination of arbitrary spoofed packets ? to > something unnatural. > > > -- > -J > From smb at cs.columbia.edu Sat Apr 3 09:00:54 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sat, 3 Apr 2010 10:00:54 -0400 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <4BB6E488.9030003@jsbc.cc> Message-ID: On Apr 3, 2010, at 9:55 13AM, jim deleskie wrote: > Not sure the IETF looked at it or not, but personally I'm one of those > people that has never accepted a solution just because, its the only > option there. I haven't always won my battles, but never just give in > :) > Guess what -- this solution, or things isomorphic to it, were indeed considered at the time. See RFC 1955: The basic idea is that inter-domain routing be done by routing on autonomous domains (AD). The key is how this is done. The mechanism to do this is for the border routers to encapsulate the original IP datagrams with another IP header. The source and destination addresses in the new header (I will call it the AD-Header from here on) represent the source and destination ADs. Sound familiar from this discussion? > -jim > > On Sat, Apr 3, 2010 at 3:47 AM, Jim Burwell wrote: >> On 4/2/2010 19:13, George Bonser wrote: >>> >>> >>>> -----Original Message----- >>>> From: Jim Burwell [mailto:jimb at jsbc.cc] >>>> Sent: Friday, April 02, 2010 6:00 PM >>>> To: nanog at nanog.org >>>> Subject: Re: legacy /8 >>>> >>> >>> >>>> So, jump through hoops to kludge up IPv4 so it continues to provide >>>> address space for new allocations through multiple levels of NAT (or >>>> whatever), and buy a bit more time, or jump through the hoops required >>>> to deploy IPv6 and eliminate the exhaustion problem? And also, if the >>>> IPv4 space is horse-traded among RIRs and customers as you allude to >>>> above, IPv6 will look even more attactive as the price and >>>> >>> preciousness >>> >>>> of IPv4 addresses increases. >>>> >>> No problem, everyone tunnels v4 in v4 and the "outer" ip address is >>> your 32-bit ASN and you get an entire /0 of "legacy" ip space inside >>> your ASN. Just need to get rid of BGP and go to some sort of label >>> switching with the border routers having an ASN to upstream label table >>> and there ya go. Oh, and probably create an AA RR in DNS that is in >>> ASN:x.x.x.x format. Increase the MTU a little and whammo! There ya go! >>> Done. >>> >>> :) >>> >>> >> So essentially add 32-bits to the IPv4 address, used as a ASN, and use >> legacy V4 on the "backbone" which tunnels everything, so the entire >> intra-ASN internet has to go through v4-in-v4 tunnels. A few "little" >> changes to DNS, and voila! And of course, there's no "devils in the >> details" we have to worry about. Heck. Just quote that last post up >> and submit it as an RFC to replace the IPv6 RFCs! :-) >> >> Seriously though, would that really be easier to implement, or be better >> than IPv6 as this point? I'd think the IETF would probably have >> considered solutions like that, but IPv6 is what we got. So best learn >> to love it. :P >> >> -Jim >> >> >> > > --Steve Bellovin, http://www.cs.columbia.edu/~smb From marka at isc.org Sat Apr 3 09:55:21 2010 From: marka at isc.org (Mark Andrews) Date: Sun, 04 Apr 2010 01:55:21 +1100 Subject: legacy /8 In-Reply-To: Your message of "Sat, 03 Apr 2010 10:57:59 -0300." References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> Message-ID: <201004031455.o33EtLp5032731@drugs.dv.isc.org> In message , jim d eleskie writes: > James, > > I agree with you concern, and as someone else said the devil is in > the details, you points are something that would need to be looked at > if enough people though we should move forward and look at an idea > like this, which I think we should, but not sure if enough traffic to > start down that road yet. If we do though, this is the kind of input > we'd need. > > -jim This sort of thing was thought of and *rejected* over a decade ago. You will still have ALL the reachability problems from legacy machines that you have with IPv4 + IPv6. Your Windows 95 machine wouldn't be able to reach most of the Internet as it would be under this model. You still need to upgrade all the application and other tools. There never was a magic wand that could fix this. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bogstad at pobox.com Sat Apr 3 09:59:25 2010 From: bogstad at pobox.com (Bill Bogstad) Date: Sat, 3 Apr 2010 10:59:25 -0400 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <20100403000952.GA9888@vacation.karoshi.com.> Message-ID: On Fri, Apr 2, 2010 at 8:22 PM, Randy Bush wrote: > ipv4 spae is not 'running out.' ?the rirs are running out of a free > resource which they then rent to us. ?breaks my little black heart. > > even if, and that's an if, ipv6 takes off, ipv4 is gonna be around for a > loooong while. ?when 95% of the world has end-to-end ipv6, do you think > amazon et alia are gonna blow 5% of their market by decomissioning ipv4? Absolutely. It all depends on the cost/benefit ratio. As an analogy, there are plenty of software companies who only distribute their software for Windows. The potential for additional revenue just isn't worth the cost to port to other operating systems. And sometimes a port is available for a while and then it goes away. Did you know that Microsoft once had a port of Internet Explorer for Solaris? In a world where 95% of people have native IPv6 connectivity, the Luddites who only have IPv4 probably aren't your best customers anyway... Bill Bogstad From wavetossed at googlemail.com Sat Apr 3 10:34:38 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Sat, 3 Apr 2010 16:34:38 +0100 Subject: legacy /8 In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> Message-ID: > That adoption is so low at this point really says that it has failed. In the real world, there is no success or failure, only next steps. At this point, IPv4 has failed, and IPv6 is the next step. No realistic alternative next steps exist at present. In addition any alternative next step to IPv6 would require massive forklift upgrades. IPv6 is already in place and has been for over 5 years. We just have to start using it. --Michael Dillon From LarrySheldon at cox.net Sat Apr 3 10:43:23 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 03 Apr 2010 10:43:23 -0500 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> Message-ID: <4BB7621B.9030607@cox.net> On 4/3/2010 10:34, Michael Dillon wrote: >> That adoption is so low at this point really says that it has failed. > > In the real world, there is no success or failure, only next steps. > At this point, IPv4 has failed, Failed? Really?!!?! Not often you hear something that has changed just about every aspect of life and enabled things that could not be imagined at its outset called a failure -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From robert at timetraveller.org Sat Apr 3 11:17:17 2010 From: robert at timetraveller.org (Robert Brockway) Date: Sat, 3 Apr 2010 12:17:17 -0400 (EDT) Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> <20100403001414.GB9888@vacation.karoshi.com.> Message-ID: On Fri, 2 Apr 2010, jim deleskie wrote: > Just like 640k or memory :) But what if I said "640 petabytes will be more than anyone will ever need". The future might prove me wrong but it probably won't happen for a long time. That's a better analogy for IPv6. IPv6 could have included a larger address space, or it could have been allocated differently[1] but the reality is we have no way of knowing how future generations will use the network. I full expect that advances in computing will render IPv6 obsolete well before the address space is exhausted. Perhaps this may occur in 100 years or more. Future generations may well have to go back to the drawing board to develop new protocols to best utilise the technology that they have available at the time. [1] 48bit host identifier rather than 64bit, for example Rob > On Fri, Apr 2, 2010 at 9:25 PM, Randy Bush wrote: >>> IPv6 as effectively reindroduced classful addressing. >> >> but it's not gonna be a problem this time, right? ?after all, >> 32^h^h128^h^h^h64 bits is more than we will ever need, right? >> >> randy >> >> > -- Email: robert at timetraveller.org IRC: Solver Web: http://www.practicalsysadmin.com Open Source: The revolution that silently changed the world From gbonser at seven.com Sat Apr 3 12:15:21 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 3 Apr 2010 10:15:21 -0700 Subject: legacy /8 In-Reply-To: <20100403163857.3b852c95@opy.nosense.org> References: <4BB65B39.8010902@mompl.net><4BB69310.7080205@jsbc.cc><5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <20100403163857.3b852c95@opy.nosense.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6C70@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Mark Smith > [mailto:nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org] > Sent: Friday, April 02, 2010 11:09 PM > To: George Bonser > Cc: John Palmer (NANOG Acct); nanog at nanog.org > Subject: Re: legacy /8 > Y2K was a bit different though - there was no alternative other than > fixing it. "Carrier grade NAT" didn't exist for YY fields, so there is > no actual deadline for IPv6 like there was for Y2K. I think that is > what is leaving room for people to think they don't have to deploy it > soon, or that it has failed. > > Regards, > Mark. > > > I think part of the problem with v6 is that it is still sort of a moving target. There seem to be a lot of ways of doing this or that and it seems new ones come out a couple of times a year that are incompatible with other ways of doing things. Things such as automatic address assignment and communicating with v4 from v6 are just a pain in the hips at the moment, there is not ironclad, cast in stone, "this is how it is done, period". But if you look at other technologies, it was the network operators that dragged them into play through necessity. Nobody had to tell anyone that they must put MPLS into their network or VRFs or BGP or whatever. The operators dragged those technologies in because they needed them. For the vast majority of operators, the only problem v6 is going to solve (admittedly a huge problem) is address depletion and a lot of the other "features" are going to go unused by most people but have to be dealt with (turned off with a big hammer in many cases). We have 128 bits of addressing, you would have thought someone might have decided early on to come up with something simple like ... the first 32 bits are your ASN and that is your "net block". Have another facility that is not connected to the first? Get another ASN. But this is all water long under the bridge. At the moment we are stuck with what we have. We really don't have the choice at this point but to hold our noses and use v6 and that is going to cause a lot of problems in a lot of places with a lot of vendors. Actually, to many operators a depletion of v4 addresses is a good thing because it serves as a barrier of entry to competition. I would guess that people who have more than enough v4 space currently are glad to see it hard to obtain and also glad to see nobody moving to v6. It just means more pie for them. From gbonser at seven.com Sat Apr 3 12:24:49 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 3 Apr 2010 10:24:49 -0700 Subject: legacy /8 In-Reply-To: <4BB6E488.9030003@jsbc.cc> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <4BB6E488.9030003@jsbc.cc> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6C71@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Jim Burwell [mailto:jimb at jsbc.cc] > Sent: Friday, April 02, 2010 11:48 PM > To: George Bonser > Cc: nanog at nanog.org > Subject: Re: legacy /8 > > On 4/2/2010 19:13, George Bonser wrote: > > > > > >> -----Original Message----- > >> From: Jim Burwell [mailto:jimb at jsbc.cc] > >> Sent: Friday, April 02, 2010 6:00 PM > >> To: nanog at nanog.org > >> Subject: Re: legacy /8 > >> > > > > > > Seriously though, would that really be easier to implement, or be > better > than IPv6 as this point? I'd think the IETF would probably have > considered solutions like that, but IPv6 is what we got. So best learn > to love it. :P > > -Jim > That is true and we have little choice at this point but we had 10 years and simply encapsulating v4 in v4 could have been implemented at the router level years ago with little problem years ago. And forget about the IETF at this point because they would not have had to be involved with this. It is operating within the v4 spec that was already specified, they would not have had to do anything. Call it v4^2 and implement it initially at the router level and then eventually customer demand pulls it down to the end system level with tcp/ipip becoming the standard. It was really just a muse (the point of the smiley at the end). I will be in the process of deploying v6 once I get a current project put to bed. Where did I put that helmet? G From gbonser at seven.com Sat Apr 3 12:31:31 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 3 Apr 2010 10:31:31 -0700 Subject: legacy /8 In-Reply-To: <4BB7621B.9030607@cox.net> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Larry Sheldon [mailto:LarrySheldon at cox.net] > Sent: Saturday, April 03, 2010 8:43 AM > To: nanog at nanog.org > Subject: Re: legacy /8 > > On 4/3/2010 10:34, Michael Dillon wrote: > >> That adoption is so low at this point really says that it has > failed. > > > > In the real world, there is no success or failure, only next steps. > > At this point, IPv4 has failed, > > Failed? Really?!!?! > Failed in the sense that I am not sure there is enough time left to really get v6 deployment going before we hit the wall. It is like skydiving and waiting too long to open the chute. Any school teaching v4 at this point other than as a legacy protocol that they teach on the second year because "they might see it in the wild" should be closed down. All new instruction that this point should begin and end with v6 with v4 as an "aside". But that isn't. From Valdis.Kletnieks at vt.edu Sat Apr 3 12:39:08 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 03 Apr 2010 13:39:08 -0400 Subject: legacy /8 In-Reply-To: Your message of "Sat, 03 Apr 2010 08:06:44 EDT." References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> <3135E5A4-A45F-44A3-A01D-A86F71988E45@delong.com> <4BB6F65D.4000907@mompl.net> <4BB6FE6F.700@jsbc.cc> Message-ID: <32099.1270316348@localhost> On Sat, 03 Apr 2010 08:06:44 EDT, Jeffrey Lyon said: > For small companies the cost of moving to IPv6 is far too great, > especially when we rely on certain DDoS mitigation gear that does not > yet have an IPv6 equivalent. So? How many people are *realistically* being hit by IPv6 DDoS right now? (I saw a number in the last 2-3 days that 2-3% of spam is now being delivered via SMTP-over-IPv6). You may not need that gear as much as you thought... Did you tell your mitigation gear vendor 5 years ago that their next model needed to have IPv6 support? Given that currently most stuff is dual-stack, and IPv6 isn't totally widespread, what are the effects of doing IPv6 DDoS mitigation by simply turning off IPv6 on your upstream link and letting traffic fall back to IPv4 where you have mitigation gear? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From marka at isc.org Sat Apr 3 12:40:54 2010 From: marka at isc.org (Mark Andrews) Date: Sun, 04 Apr 2010 03:40:54 +1000 Subject: legacy /8 In-Reply-To: Your message of "Sat, 03 Apr 2010 10:43:23 CDT." <4BB7621B.9030607@cox.net> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> Message-ID: <201004031740.o33HesP0034661@drugs.dv.isc.org> In message <4BB7621B.9030607 at cox.net>, Larry Sheldon writes: > On 4/3/2010 10:34, Michael Dillon wrote: > >> That adoption is so low at this point really says that it has failed. > > > > In the real world, there is no success or failure, only next steps. > > At this point, IPv4 has failed, > > Failed? Really?!!?! Failed, no. However it's well past its "best before date" and is on life support and has been for many years now. > Not often you hear something that has changed just about every aspect of > life and enabled things that could not be imagined at its outset called > a failure -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From LarrySheldon at cox.net Sat Apr 3 12:53:47 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 03 Apr 2010 12:53:47 -0500 Subject: legacy /8 In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> Message-ID: <4BB780AB.6060006@cox.net> On 4/3/2010 12:31, George Bonser wrote: > > >> -----Original Message----- >> From: Larry Sheldon [mailto:LarrySheldon at cox.net] >> Sent: Saturday, April 03, 2010 8:43 AM >> To: nanog at nanog.org >> Subject: Re: legacy /8 >> >> On 4/3/2010 10:34, Michael Dillon wrote: >>>> That adoption is so low at this point really says that it has >> failed. >>> >>> In the real world, there is no success or failure, only next steps. >>> At this point, IPv4 has failed, >> >> Failed? Really?!!?! >> > > Failed in the sense that I am not sure there is enough time left to > really get v6 deployment going before we hit the wall. It is like > skydiving and waiting too long to open the chute. That is the parachute's fault? Really? -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From wavetossed at googlemail.com Sat Apr 3 13:07:26 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Sat, 3 Apr 2010 19:07:26 +0100 Subject: legacy /8 In-Reply-To: <4BB7621B.9030607@cox.net> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> Message-ID: > Not often you hear something that has changed just about every aspect of > life and enabled things that could not be imagined at its outset ?called > a failure Sounds like you are describing the Roman Empire. It failed and that's why we now have an EU in its place. Things change. Time to move on. IPv4 has run out of addresses and we are nowhere near finished GROWING THE NETWORK. IPv6 was created to solve just this problem, and 10 years ago folks started deploying it in order to be ready. By 5 years ago, every significant router on the market supported IPv6. Now that we actually need IPv6 in order to continue network growth, most ISPs are in the fortunate position that their network hardware already supports it well enough, so the investment required is minimized. --Michael Dillon From mysidia at gmail.com Sat Apr 3 13:07:31 2010 From: mysidia at gmail.com (James Hess) Date: Sat, 3 Apr 2010 12:07:31 -0600 Subject: legacy /8 In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> Message-ID: On Sat, Apr 3, 2010 at 11:31 AM, George Bonser wrote: > Any school teaching v4 at this point other than as a legacy protocol > that they teach on the second year because "they might see it in the > wild" should be closed down. ?All new instruction that this point should > begin and end with v6 with v4 as an "aside". ?But that isn't. > They would be doing the student, their customer, a disservice to not teach both, with emphasis on V4, just because one possible speculated outcome in the years ahead is that IPv4 becomes a legacy protocol. Schools do not have crystal balls, and they can't know how important IPv4 or IPv6 will be to those taught later. I suppose if Google announced tomorrow, that search engine access over IPv4 is going to be discontinued in 12 months, and you will have to connect using IPv6, then IPv4 might become legacy....... They could have posted that on April 1, with impunity too :) Enterprises may take a long time to move, there are so many participants involved, it is difficult to fathom them all acting at once, at least, until some major content providers, major search engines, etc, announce they will _stop_ providing services over V4. Industry may be leaning towards IPv6 adoption, and v4 may be abandoned soon after free pool exhaustion, but there are other very likely outcomes too --- such as a heck of a lot of V4 devices and DS-Lite deployments, where Enterprise networks will want to keep their same familiar IPv4, and keep v6 "migration" costs as low as possible. -- -J From Valdis.Kletnieks at vt.edu Sat Apr 3 13:11:05 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 03 Apr 2010 14:11:05 -0400 Subject: legacy /8 In-Reply-To: Your message of "Sat, 03 Apr 2010 13:12:20 +1030." <20100403131220.5dce0bbc@opy.nosense.org> References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> <20100403131220.5dce0bbc@opy.nosense.org> Message-ID: <602.1270318265@localhost> On Sat, 03 Apr 2010 13:12:20 +1030, Mark Smith said: > going to be enough. I'm not sure why the 32 bit address size was > persisted with at that point - maybe it was because there would be > significant performance loss in handling addresses greater than what > was probably the most common host word size at the time. I've always been surprised that the early preponderance of 36-bit machines (DEC -10/20, Multics boxes) didn't stick us with a 36 bit address. That would have bought us a few more decades. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rudi.daniel at gmail.com Sat Apr 3 13:19:45 2010 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Sat, 3 Apr 2010 14:19:45 -0400 Subject: NANOG Digest, Vol 27, Issue 23 In-Reply-To: References: Message-ID: I am researching a WISP and need some advise about mesh networks, low cost equipment, and operations in a developing country with a relatively small population say 120K people. Anyone here can offer advice off list please? RD From gbonser at seven.com Sat Apr 3 13:25:48 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 3 Apr 2010 11:25:48 -0700 Subject: legacy /8 In-Reply-To: <4BB780AB.6060006@cox.net> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com><4BB7621B.9030607@cox.net><5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> <4BB780AB.6060006@cox.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6C73@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Larry Sheldon [mailto:LarrySheldon at cox.net] > Sent: Saturday, April 03, 2010 10:54 AM > Cc: nanog at nanog.org > Subject: Re: legacy /8 > > > That is the parachute's fault? > > Really? > -- No. But that isn't the point. The point is that v6 was a bad solution to the problem. Rather than simply address the address depletion problem, it also "solves" a lot of problems that nobody has while creating a whole bunch more that we will have. Rather than simply address the problem that was on the horizon, the group took the opportunity to complicate it with a lot of other contraptions and saw that as being a "good thing" that apparently we and the vendors are just too dumb to realize or something. And they made v4 incompatible with v6 rather really addressing the problem. They saw simply extending the header with additional address bits to be a "bad thing" for some reason when that is really all that was needed and so they went on building their mousetrap and we have the mother of all internet protocols that slices and dices and even makes Julien fries when all we needed was a bigger potato peeler. I am not saying we can change it at this point but I am saying we should learn from it and never, ever, do things this way again. From skrepetski at gmail.com Sat Apr 3 13:33:07 2010 From: skrepetski at gmail.com (Stephen Repetski) Date: Sat, 3 Apr 2010 14:33:07 -0400 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> Message-ID: <007801cad35c$1b88c2c0$529a4840$@gmail.com> > -----Original Message----- > From: James Hess [mailto:mysidia at gmail.com] > Sent: Saturday, April 03, 2010 2:08 PM > To: George Bonser > Cc: nanog at nanog.org > Subject: Re: legacy /8 > > On Sat, Apr 3, 2010 at 11:31 AM, George Bonser > wrote: > > Any school teaching v4 at this point other than as a legacy protocol > > that they teach on the second year because "they might see it in the > > wild" should be closed down. ?All new instruction that this point > > should begin and end with v6 with v4 as an "aside". ?But that isn't. > > > > They would be doing the student, their customer, a disservice to not teach > both, with emphasis on V4, just because one possible speculated outcome > in the years ahead is that IPv4 becomes a legacy protocol. > Schools do not have crystal balls, and they can't know how important > IPv4 or IPv6 will be to those taught later. I've been taking some networking classes for my undergrad college degree, and there've only been about 3 mentions of IPv6 during the whole time I've been here (at supposedly a high-tech school). Also, did I mention we're still being taught classful networking? I've never heard my professors udder the CIDR acronym or talk about subnetting. Hopefully this changes as students progress into the higher-level classes, but I wouldn't want to be the one attempting to get a job with no knowledge of what's changed since my professor was in school. ---------- Stephen (Trey) Repetski skr3394 at rit.edu | skrepetski at gmail.com srepetsk.net | RIT '13, TJHSST '09 From gbonser at seven.com Sat Apr 3 13:43:47 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 3 Apr 2010 11:43:47 -0700 Subject: legacy /8 In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6C73@RWC-EX1.corp.seven.com> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com><4BB7621B.9030607@cox.net><5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com><4BB780AB.6060006@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C73@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6C74@RWC-EX1.corp.seven.com> > -----Original Message----- > From: George Bonser [mailto:gbonser at seven.com] > Sent: Saturday, April 03, 2010 11:26 AM > To: Larry Sheldon > Cc: nanog at nanog.org > Subject: RE: legacy /8 > > > > > -----Original Message----- > > From: Larry Sheldon [mailto:LarrySheldon at cox.net] > > Sent: Saturday, April 03, 2010 10:54 AM > > Cc: nanog at nanog.org > > Subject: Re: legacy /8 > > > > > > That is the parachute's fault? > > > > Really? > > -- Maybe the correct analogy is that you are supplied with a "much better" parachute that takes you so long to open that by the time you get it opened, you are too close to the ground. And that still isn't the 'chute's fault, it is the fault of whoever decided it would be "better". So imagine you are now dropping load that are much larger than before and so you need a parachute that is "bigger" but rather than simply increasing the size of the 'chute, they also add a bunch of other features than make the deployment of those 'chutes more difficult. Not only is the chute different, but the riggers need to be completely retrained and it is no longer compatible with the other rigging so all that needs to be replaced, too. And yes, you can drop a bigger load with it but 90% of the extra "features" end up being turned off or causing problems because someone accidently left them enabled. And by the time you figure out that you have to pull 15 cords to get the thing open, you are too late. Is it really "better"? Yes, it is more capable but if all you do is cut meat for a living, are you sure you want to do that with a Swiss Army knife? Here is the most important concept to my mind: They could have taken a dual-track approach. They could have expanded v4 while at the same time developing v6. If the reason for not doing that was "if we expand v4 then nobody will ever use v6" then that tells you that v6 wasn't needed and that all that was needed was expansion of v4. Intentionally abandoning v4 for no other reason other than to force adoption of v6 was a dumb idea driven by ego, in my opinion. The notion that they "knew better" what was needed than the people actually using it is a common theme through history. Besides address depletion, can anyone tell me what other problem v6 "solves"? From marka at isc.org Sat Apr 3 13:42:28 2010 From: marka at isc.org (Mark Andrews) Date: Sun, 04 Apr 2010 04:42:28 +1000 Subject: legacy /8 In-Reply-To: Your message of "Sat, 03 Apr 2010 11:25:48 MST." <5A6D953473350C4B9995546AFE9939EE08FE6C73@RWC-EX1.corp.seven.com> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com><4BB7621B.9030607@cox.net><5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> <4BB780AB.6060006@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C73@RWC-EX1.corp.seven.com> Message-ID: <201004031842.o33IgSdJ035346@drugs.dv.isc.org> In message <5A6D953473350C4B9995546AFE9939EE08FE6C73 at RWC-EX1.corp.seven.com>, "George Bonser" writes: > No. But that isn't the point. The point is that v6 was a bad solution > to the problem. Rather than simply address the address depletion > problem, it also "solves" a lot of problems that nobody has while > creating a whole bunch more that we will have. Rather than simply > address the problem that was on the horizon, the group took the > opportunity to complicate it with a lot of other contraptions and saw > that as being a "good thing" that apparently we and the vendors are just > too dumb to realize or something. And they made v4 incompatible with v6 > rather really addressing the problem. They saw simply extending the > header with additional address bits to be a "bad thing" for some reason > when that is really all that was needed and so they went on building > their mousetrap and we have the mother of all internet protocols that > slices and dices and even makes Julien fries when all we needed was a > bigger potato peeler. =20 > > I am not saying we can change it at this point but I am saying we should > learn from it and never, ever, do things this way again. And we would have still had the same problem of intercommunicating. We know how to talk from IPv6 to IPv4 and get the reply traffic back. The hard part is how to initiate connection from IPv4 to IPv6. The same problem would exist in your "just expand the address bits world". Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From drc at virtualized.org Sat Apr 3 13:54:43 2010 From: drc at virtualized.org (David Conrad) Date: Sat, 3 Apr 2010 08:54:43 -1000 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> <20100403001414.GB9888@vacation.karoshi.com.> Message-ID: On Apr 3, 2010, at 6:17 AM, Robert Brockway wrote: > On Fri, 2 Apr 2010, jim deleskie wrote: >> Just like 640k or memory :) > But what if I said "640 petabytes will be more than anyone will ever need". The future might prove me wrong but it probably won't happen for a long time. That's a better analogy for IPv6. Not really. The reason some folks aren't sanguine about the amount of address space available in IPv6 is because (a) it is a fixed size and (b) the policies by which the address space are allocated are subject to the whims of human behavior. For example, recently in RIPE, they were folks arguing for people to be able to get /24s just by saying they were using a particular transition strategy. For another example, there are governments arguing in the ITU that countries should receive large blocks (/8s have been suggested) so IP addresses could be handed out like telephone numbers (the concepts of route system scalability are irrelevant to these folks). With these sorts of policies being seriously suggested, it is probably appropriate for folks who remember the history of address policy to speak out. Regards, -drc From drc at virtualized.org Sat Apr 3 14:07:27 2010 From: drc at virtualized.org (David Conrad) Date: Sat, 3 Apr 2010 09:07:27 -1000 Subject: legacy /8 In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6C73@RWC-EX1.corp.seven.com> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com><4BB7621B.9030607@cox.net><5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> <4BB780AB.6060006@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C73@RWC-EX1.corp.seven.com> Message-ID: <95AF6CF6-7651-46D8-BF37-DFD3AD2B3696@virtualized.org> On Apr 3, 2010, at 8:25 AM, George Bonser wrote: > The point is that v6 was a bad solution to the problem. Well, yes, but... > Rather than simply address the address depletion > problem, it also "solves" a lot of problems that nobody has while > creating a whole bunch more that we will have. Not really. The only problem IPv6 really solves (that couldn't be solved in one way or another in IPv4) was the limited amount of address space. Well, OK. IPv6 also does stateless autoconfiguration for folks who care about that, but you can (after much battle with the IETF) mostly ignore that if you don't care. IPv6 doesn't, unfortunately, solve the real problem which is routing system scalability, but that's a separate rant. > And they made v4 incompatible with v6 rather really addressing the problem. How would you propose making going from a smaller fixed address space to a larger one backwards compatible? How would you deal with the myriad of applications that 'know' an IP address fits into a 32 bit "int" and make use of that fact? > I am not saying we can change it at this point but I am saying we should > learn from it and never, ever, do things this way again. Which is, I think, why some folks argue for more conservatism in address allocation policy. Regards, -drc From gbonser at seven.com Sat Apr 3 14:09:51 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 3 Apr 2010 12:09:51 -0700 Subject: legacy /8 In-Reply-To: <201004031842.o33IgSdJ035346@drugs.dv.isc.org> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com><4BB7621B.9030607@cox.net><5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> <4BB780AB.6060006@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C73@RWC-EX1.corp.seven.com> <201004031842.o33IgSdJ035346@drugs.dv.isc.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6C76@RWC-EX1.corp.seven.com> > -----Original Message----- > From: marka at isc.org [mailto:marka at isc.org] > Sent: Saturday, April 03, 2010 11:42 AM > To: George Bonser > Cc: Larry Sheldon; nanog at nanog.org > Subject: Re: legacy /8 > > > And we would have still had the same problem of intercommunicating. > We know how to talk from IPv6 to IPv4 and get the reply traffic back. > The hard part is how to initiate connection from IPv4 to IPv6. The > same problem would exist in your "just expand the address bits world". > > Mark Actually, Mark, I hadn't said "just expand the address", I said to tunnel v4 in v4 which we already know how to do and most routers are already capable of doing. But yes, in the case of legacy devices that don't "speak" the new protocol, some sort of state for the flow would have to be maintained in that unit's first hop (or close to first hop) gateway. Simply increasing the address header on v4 to 128 bits would have fixed this problem years ago and got rid of such problems as NAT and we wouldn't be having this issue (and it would have been completely backwards compatible as 0s would be inserted into the new expanded address bits to put the legacy space in a special address range. I wouldn't expect to work out all the details over email on a weekend but I don't think it would take 10 years, either. The fundamental issue to me is that v6 solves a lot of problems that aren't really problems for most people and to get the fix that solves the problem you do have, you must accept a bunch of additional "fixes" for problems you don't have that makes the whole thing some big unwieldy contraption. That having been said, once the world has migrated to v6, we should have an easier go of it in the future as v6 is more easily extensible. But in the meantime, we are stuck with both protocols for probably the next 20 years or so as there are going to be places that are going to run v4 internally even if they communicate v6 externally. So ... "we are going to mandate that everyone use this new and better car but it will take different fuel, use different tires, won't fit in your garage and oh, it is incompatible with all existing roads unless you load it up on one of the old style vehicles piggy-back, but new roads are being built (here's a picture of one) and might someday be available where you live. And two years from now there will be none of the old cars left." But my daughter will need a car in three years and there are no such roads here. "Oh well! The new way is much better, it is for your own good, you will see. Trust me". From randy at psg.com Sat Apr 3 15:36:26 2010 From: randy at psg.com (Randy Bush) Date: Sun, 04 Apr 2010 05:36:26 +0900 Subject: legacy /8 In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6C73@RWC-EX1.corp.seven.com> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> <4BB780AB.6060006@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C73@RWC-EX1.corp.seven.com> Message-ID: > No. But that isn't the point. The point is that v6 was a bad solution > to the problem. Rather than simply address the address depletion > problem, it also "solves" a lot of problems that nobody has while > creating a whole bunch more that we will have. it's known as "second system syndrome." and you neglect to add that ipv6 did not deal with the routing problems, which are rather intimately connected with addressing in both the ipv4 and the ipv6 models. randy From frnkblk at iname.com Sat Apr 3 16:22:12 2010 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 3 Apr 2010 16:22:12 -0500 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> Message-ID: If "every significant router on the market" supported IPv6 five years ago, why aren't transit links glowing with IPv6 connectivity? If it's not the hardware, than I'm guessing it's something else, like people or processes? Frank -----Original Message----- From: Michael Dillon [mailto:wavetossed at googlemail.com] Sent: Saturday, April 03, 2010 1:07 PM To: Larry Sheldon Cc: nanog at nanog.org Subject: Re: legacy /8 > Not often you hear something that has changed just about every aspect of > life and enabled things that could not be imagined at its outset ?called > a failure Sounds like you are describing the Roman Empire. It failed and that's why we now have an EU in its place. Things change. Time to move on. IPv4 has run out of addresses and we are nowhere near finished GROWING THE NETWORK. IPv6 was created to solve just this problem, and 10 years ago folks started deploying it in order to be ready. By 5 years ago, every significant router on the market supported IPv6. Now that we actually need IPv6 in order to continue network growth, most ISPs are in the fortunate position that their network hardware already supports it well enough, so the investment required is minimized. --Michael Dillon From frnkblk at iname.com Sat Apr 3 16:30:32 2010 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 3 Apr 2010 16:30:32 -0500 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> Message-ID: If Google made the same strong statement with IPv6 as they have done with their 700 MHz bid or the Google-subsidized fiber project, it could make a significant difference. A few examples come to mind: - free or discounted advertising to vendors if delivered over IPv6: this would incent advertisers to have viewers access content over IPv6, even if it was just on mobile phones with certain apps. - free or discounted Google Apps if a certain percentage of client access was over IPv6, etc: this would incent enterprises (the non-profits are either free or discounted, so this example applies mostly to the for-profits) to find native IPv6 access because it provides an immediate and direct savings Frank -----Original Message----- From: James Hess [mailto:mysidia at gmail.com] Sent: Saturday, April 03, 2010 1:08 PM To: George Bonser Cc: nanog at nanog.org Subject: Re: legacy /8 I suppose if Google announced tomorrow, that search engine access over IPv4 is going to be discontinued in 12 months, and you will have to connect using IPv6, then IPv4 might become legacy....... They could have posted that on April 1, with impunity too :) Enterprises may take a long time to move, there are so many participants involved, it is difficult to fathom them all acting at once, at least, until some major content providers, major search engines, etc, announce they will _stop_ providing services over V4. -- -J From drc at virtualized.org Sat Apr 3 16:35:56 2010 From: drc at virtualized.org (David Conrad) Date: Sat, 3 Apr 2010 11:35:56 -1000 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> Message-ID: On Apr 3, 2010, at 11:22 AM, Frank Bulk wrote: > If "every significant router on the market" supported IPv6 five years ago, > why aren't transit links glowing with IPv6 connectivity? If it's not the > hardware, than I'm guessing it's something else, like people or processes? Or the fact that "supporting IPv6" could (and as far I could tell did until very recently) mean minimalistic process switching of packets without any of the 'niceties' of filtering, management, monitoring, etc. support. It also ignores the fact that there is a bit more to providing Internet service than simply running routers. However, historically we had: 1) why should ISPs pay to deploy IPv6 when their customers aren't asking for it? 2) why should customers ask for IPv6 when there is no content available via it? 3) why should content providers make their content available over IPv6 when they can't get it from their ISPs and none of their customers are asking for it? It may be that IPv4 free pool run out will result in costs for obtaining IPv4 to rise sufficiently to address (1). Or we could have multi-layer NAT. Regards, -drc From zaid at zaidali.com Sat Apr 3 16:49:57 2010 From: zaid at zaidali.com (Zaid Ali) Date: Sat, 03 Apr 2010 14:49:57 -0700 Subject: legacy /8 In-Reply-To: Message-ID: They are not glowing because applications are simply not moving to IPv6. Google has two popular applications on IPv6, Netflix is on it way there but what are other application companies doing about it? A popular application like e-mail is so far behind [ref: http://eng.genius.com/blog/2009/09/14/email-on-ipv6/] and I still encounter registrar's providing DNS service not supporting Quad A's. I feel talking to network operators is preaching to the choir, the challenge is helping content providers think about moving to IPv6. I think we will only see success once we are able to successfully work with content providers but they are quite busy now building real technology like the "Cloud" Zaid On 4/3/10 2:22 PM, "Frank Bulk" wrote: > If "every significant router on the market" supported IPv6 five years ago, > why aren't transit links glowing with IPv6 connectivity? If it's not the > hardware, than I'm guessing it's something else, like people or processes? > > Frank > > -----Original Message----- > From: Michael Dillon [mailto:wavetossed at googlemail.com] > Sent: Saturday, April 03, 2010 1:07 PM > To: Larry Sheldon > Cc: nanog at nanog.org > Subject: Re: legacy /8 > >> Not often you hear something that has changed just about every aspect of >> life and enabled things that could not be imagined at its outset ?called >> a failure > > Sounds like you are describing the Roman Empire. It failed and that's why > we now have an EU in its place. > > Things change. Time to move on. > > IPv4 has run out of addresses and we are nowhere near finished GROWING > THE NETWORK. IPv6 was created to solve just this problem, and 10 years > ago folks started deploying it in order to be ready. By 5 years ago, every > significant router on the market supported IPv6. Now that we actually need > IPv6 in order to continue network growth, most ISPs are in the fortunate > position that their network hardware already supports it well enough, so > the investment required is minimized. > > --Michael Dillon > > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Apr 3 20:15:00 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 4 Apr 2010 10:45:00 +0930 Subject: legacy /8 In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6C73@RWC-EX1.corp.seven.com> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> <4BB780AB.6060006@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C73@RWC-EX1.corp.seven.com> Message-ID: <20100404104500.1c7b6d49@opy.nosense.org> On Sat, 3 Apr 2010 11:25:48 -0700 "George Bonser" wrote: > > > > -----Original Message----- > > From: Larry Sheldon [mailto:LarrySheldon at cox.net] > > Sent: Saturday, April 03, 2010 10:54 AM > > Cc: nanog at nanog.org > > Subject: Re: legacy /8 > > > > > > That is the parachute's fault? > > > > Really? > > -- > > > No. But that isn't the point. The point is that v6 was a bad solution > to the problem. Rather than simply address the address depletion > problem, it also "solves" a lot of problems that nobody has while > creating a whole bunch more that we will have. Ever used IPX or Appletalk? If you haven't, then you don't know how simple and capable networking can be. And those protocols were designed more than 20 years ago, yet they're still more capable than IPv4. I used to teach Novell CNE courses around the mid 90s. Of the 7 courses, one of them was a two day course on a networking protocol. That networking protocol *wasn't* IPX - it was TCP/IP. IPX just worked, but you had to spend two days explaining TCP/IP. Even though I'd been using TCP/IP for a number of years before then, it still to me 5 attempts at teaching that course before I was completely happy with how I'd explained subnets, and had that feedback from students. I think IPv6 has not just learnt from the history of IPv4, it has also learnt from the history of other protocols. > Rather than simply > address the problem that was on the horizon, the group took the > opportunity to complicate it with a lot of other contraptions and saw > that as being a "good thing" that apparently we and the vendors are just > too dumb to realize or something. And they made v4 incompatible with v6 > rather really addressing the problem. They saw simply extending the > header with additional address bits to be a "bad thing" for some reason > when that is really all that was needed and so they went on building > their mousetrap and we have the mother of all internet protocols that > slices and dices and even makes Julien fries when all we needed was a > bigger potato peeler. > > I am not saying we can change it at this point but I am saying we should > learn from it and never, ever, do things this way again. > > > > > > > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Apr 3 20:16:14 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 4 Apr 2010 10:46:14 +0930 Subject: Fw: legacy /8 Message-ID: <20100404104614.6bff3a1a@opy.nosense.org> Hi, Vint Cerf kindly sent through some more explanation. Regards, Mark. Begin forwarded message: Date: Sat, 3 Apr 2010 08:17:28 -0400 From: Vint Cerf To: Mark Smith Cc: Andrew Gray <3356 at blargh.com>, NANOG List Subject: Re: legacy /8 When the Internet design work began, there were only a few fairly large networks around. ARPANET was one. The Packet Radio and Packet Satellite networks were still largely nascent. Ethernet had been implemented in one place: Xerox PARC. We had no way to know whether the Internet idea was going to work. We knew that the NCP protocol was inadequate for lossy network operation (think: PRNET and Ethernet in particular). This was a RESEARCH project. We assumed that national scale networks were expensive so there would not be too many of them. And we certainly did not think there would be many built for a proof of concept. So 8 bits seemed reasonable. Later, with local networks becoming popular, we shifted to the class A-D address structure and when class B was near exhaustion, the NSFNET team (I think specifically Hans-Werner Braun but perhaps others also) came up with CIDR and the use of masks to indicate the size of the "network" part of the 32 bit address structure. By 1990 (7 years after the operational start of the Internet and 17 years since its basic design), it seemed clear that the 32 bit space would be exhausted and the long debate about IPng that became IPv6 began. CIDR slowed the rate of consumption through more efficient allocation of network addresses but now, in 2010, we face imminent exhaustion of the 32 bit structure and must move to IPv6. Part of the reason for not changing to a larger address space sooner had to do with the fact that there were a fairly large number of operating systems in use and every one of them would have had to be modified to run a new TCP and IP protocol. So the "hacks" seemed the more convenient alternative. There had been debates during the 1976 year about address size and proposals ranged from 32 to 128 bit to variable length address structures. No convergence appeared and, as the program manager at DARPA, I felt it necessary to simply declare a choice. At the time (1977), it seemed to me wasteful to select 128 bits and variable length address structures led to a lot of processing overhead per packet to find the various fields of the IP packet format. So I chose 32 bits. vint On Fri, Apr 2, 2010 at 10:42 PM, Mark Smith < nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote: > On Fri, 02 Apr 2010 15:38:26 -0700 > Andrew Gray <3356 at blargh.com> wrote: > > > Jeroen van Aart writes: > > > > > Cutler James R wrote: > > >> I also just got a fresh box of popcorn. I will sit by and wait > > > > > > I honestly am not trying to be a troll. It's just everytime I glance > over > > > the IANA IPv4 Address Space Registry I feel rather annoyed about all > those > > > /8s that were assigned back in the day without apparently realising we > > > might run out. > > > > > > It was explained to me that many companies with /8s use it for their > > > internal network and migrating to 10/8 instead is a major pain. > > > > You know, I've felt the same irritation before, but one thing I am > wondering > > and perhaps some folks around here have been around long enough to know - > > what was the original thinking behind doing those /8s? > > > > I understand that they were A classes and assigned to large companies, > etc. > > but was it just not believed there would be more than 126(-ish) of these > > entities at the time? Or was it thought we would move on to larger > address > > space before we did? Or was it that things were just more free-flowing > back > > in the day? Why were A classes even created? RFC 791 at least doesn't > seem > > to provide much insight as to the 'whys'. > > > > That's because RFC791 is a long way from the original design > assumptions of the Internet Protocols. > > "A Protocol for Packet Network Intercommunication", Vinton G. Cerf and > Robert E. Kahn, 1974, says - > > "The choice for network identification (8 bits) allows up to 256 > distinct networks. This size seems sufficient for the foreseeable > future." > > That view seems to have persisted up until at least RFC761, January > 1980, which still specified the single 8 bit network, 24 bit node > address format. RFC791, September 1981, introduces classes. So > somewhere within that period it was recognised that 256 networks wasn't > going to be enough. I'm not sure why the 32 bit address size was > persisted with at that point - maybe it was because there would be > significant performance loss in handling addresses greater than what > was probably the most common host word size at the time. > > If you start looking into the history of IPv4 addressing, and arguably > why it is so hard to understand and teach compared to other > protocols such as Novell's IPX, Appletalk etc., everything that has been > added to allow increasing the use of IP (classes, subnets, classless) > while avoiding increasing the address size past 32 bits is a series of > very neat hacks. IPv4 is a 1970s protocol that has had to cope with > dramatic and unforeseen success. It's not a state of the art protocol > any more, and shouldn't be used as an example of how things should be > done today (As a minimum, I think later protocols like Novell's IPX and > Appletalk are far better candidates). It is, however, a testament to how > successfully something can be hacked over time to continue to work far, > far beyond it's original design parameters and assumptions. > > (IMO, if you want to understand the design philosophies of IPv6 you're > better off studying IPX and Appletalk than using your IPv4 knowledge. > I think IPv6 is a much closer relative to those protocols than it is to > IPv4. For example, router anycast addresses was implemented and used in > Appletalk.) > > Possibly Vint Cerf might be willing to clear up some of these questions > about the origins of IPv4 addressing. > > Regards, > Mark. > > -------------- next part -------------- When the Internet design work began, there were only a few fairly large networks around. ARPANET was one. The Packet Radio and Packet Satellite networks were still largely nascent. Ethernet had been implemented in one place: Xerox PARC. We had no way to know whether the Internet idea was going to work. We knew that the NCP protocol was inadequate for lossy network operation (think: PRNET and Ethernet in particular). This was a RESEARCH project. We assumed that national scale networks were expensive so there would not be too many of them. And we certainly did not think there would be many built for a proof of concept. So 8 bits seemed reasonable. Later, with local networks becoming popular, we shifted to the class A-D address structure and when class B was near exhaustion, the NSFNET team (I think specifically Hans-Werner Braun but perhaps others also) came up with CIDR and the use of masks to indicate the size of the "network" part of the 32 bit address structure. By 1990 (7 years after the operational start of the Internet and 17 years since its basic design), it seemed clear that the 32 bit space would be exhausted and the long debate about IPng that became IPv6 began. CIDR slowed the rate of consumption through more efficient allocation of network addresses but now, in 2010, we face imminent exhaustion of the 32 bit structure and must move to IPv6. Part of the reason for not changing to a larger address space sooner had to do with the fact that there were a fairly large number of operating systems in use and every one of them would have had to be modified to run a new TCP and IP protocol. So the "hacks" seemed the more convenient alternative. There had been debates during the 1976 year about address size and proposals ranged from 32 to 128 bit to variable length address structures. No convergence appeared and, as the program manager at DARPA, I felt it necessary to simply declare a choice. At the time (1977), it seemed to me wasteful to select 128 bits and variable length address structures led to a lot of processing overhead per packet to find the various fields of the IP packet format. So I chose 32 bits. vint On Fri, Apr 2, 2010 at 10:42 PM, Mark Smith <[1]nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote: On Fri, 02 Apr 2010 15:38:26 -0700 Andrew Gray <[2]3356 at blargh.com> wrote: > Jeroen van Aart writes: > > > Cutler James R wrote: > >> I also just got a fresh box of popcorn. I will sit by and wait > > > > I honestly am not trying to be a troll. It's just everytime I glance over > > the IANA IPv4 Address Space Registry I feel rather annoyed about all those > > /8s that were assigned back in the day without apparently realising we > > might run out. > > > > It was explained to me that many companies with /8s use it for their > > internal network and migrating to 10/8 instead is a major pain. > > You know, I've felt the same irritation before, but one thing I am wondering > and perhaps some folks around here have been around long enough to know - > what was the original thinking behind doing those /8s? > > I understand that they were A classes and assigned to large companies, etc. > but was it just not believed there would be more than 126(-ish) of these > entities at the time? Or was it thought we would move on to larger address > space before we did? Or was it that things were just more free-flowing back > in the day? Why were A classes even created? RFC 791 at least doesn't seem > to provide much insight as to the 'whys'. > That's because RFC791 is a long way from the original design assumptions of the Internet Protocols. "A Protocol for Packet Network Intercommunication", Vinton G. Cerf and Robert E. Kahn, 1974, says - "The choice for network identification (8 bits) allows up to 256 distinct networks. This size seems sufficient for the foreseeable future." That view seems to have persisted up until at least RFC761, January 1980, which still specified the single 8 bit network, 24 bit node address format. RFC791, September 1981, introduces classes. So somewhere within that period it was recognised that 256 networks wasn't going to be enough. I'm not sure why the 32 bit address size was persisted with at that point - maybe it was because there would be significant performance loss in handling addresses greater than what was probably the most common host word size at the time. If you start looking into the history of IPv4 addressing, and arguably why it is so hard to understand and teach compared to other protocols such as Novell's IPX, Appletalk etc., everything that has been added to allow increasing the use of IP (classes, subnets, classless) while avoiding increasing the address size past 32 bits is a series of very neat hacks. IPv4 is a 1970s protocol that has had to cope with dramatic and unforeseen success. It's not a state of the art protocol any more, and shouldn't be used as an example of how things should be done today (As a minimum, I think later protocols like Novell's IPX and Appletalk are far better candidates). It is, however, a testament to how successfully something can be hacked over time to continue to work far, far beyond it's original design parameters and assumptions. (IMO, if you want to understand the design philosophies of IPv6 you're better off studying IPX and Appletalk than using your IPv4 knowledge. I think IPv6 is a much closer relative to those protocols than it is to IPv4. For example, router anycast addresses was implemented and used in Appletalk.) Possibly Vint Cerf might be willing to clear up some of these questions about the origins of IPv4 addressing. Regards, Mark. References 1. mailto:nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org 2. mailto:3356 at blargh.com From randy at psg.com Sat Apr 3 20:18:46 2010 From: randy at psg.com (Randy Bush) Date: Sun, 04 Apr 2010 10:18:46 +0900 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> Message-ID: > If "every significant router on the market" supported IPv6 five years ago, and if cash fell from the sky ... to folk actually running real networks, 'support' means *parity* with ipv4, i.e. fast path at decent rates, management and monitoring, no licensing extortion, ... we don't have that today! the *additional* cost and effort to the isp of fullly deploying dual-stack is still non-trivial. this is mightily off-pissing. randy From thegameiam at yahoo.com Sat Apr 3 20:37:51 2010 From: thegameiam at yahoo.com (David Barak) Date: Sat, 3 Apr 2010 18:37:51 -0700 (PDT) Subject: legacy /8 In-Reply-To: <20100404104500.1c7b6d49@opy.nosense.org> Message-ID: <451188.24584.qm@web31802.mail.mud.yahoo.com> --- On Sat, 4/3/10, Mark Smith wrote: > To: "George Bonser" > > No.? But that isn't the point.? The point is > that v6 was a bad solution > > to the problem.? Rather than simply address the > address depletion > > problem, it also "solves" a lot of problems that > nobody has while > > creating a whole bunch more that we will have. > > Ever used IPX or Appletalk? If you haven't, then you don't > know how > simple and capable networking can be. And those protocols > were designed > more than 20 years ago, yet they're still more capable than > IPv4. Spoken like someone who has forgotten how much {fun|trouble} cable range + zones were... IPX, AppleTalk, VINES, DECNet, SNA, and all of the other protocol suites which were kicking around in the 80s and early 90s each had the "one thing they do really really well," but none of them were sufficiently flexible, extensible, easy, or cheap to capture the market. Examples of some things which those protocols *didn't* do well include (obviously the list is different for each individual protocol): * interdomain routing - most were optimized for single-administrative control networks * multicast * handle an encryption layer at layer 3 * cheap + easy to implement, no license required * distributed centralized administration (i.e. DHCP servers) * tolerate a wide variety of {link|connection} performance characteristics > I think IPv6 has not just learnt from the history of IPv4, > it has also learnt from the history of other protocols. Sadly, though, it also picked up some of the mistaken optimizations from the other protocols. The mess that has been made of RA+SLAAC+DHCPv6+DNS is something which can't be described as "elegant," and I certainly don't find it an improvement over IPv4 DHCP+DNS. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From ipv3.com at gmail.com Sat Apr 3 20:38:46 2010 From: ipv3.com at gmail.com (IPv3.com) Date: Sat, 3 Apr 2010 20:38:46 -0500 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? Message-ID: What is "The Internet" TCP/IP or UNIX-to-UNIX ? As of 2010, many people would likely answer that question based on the Services they use as opposed to a religious adoration for TCP/IP. What if TCP is removed ? and IP is completely re-worked in the same 160-bit foot-print as IPv4 ? Would 64-bit Addressing last a few years ? IPv6 is a loser because everyone has to carry the overhead of bloated packets. It is a one-size-fits-all take it or leave it solution. People leave it. The real (new?) need is ONE-WAY streaming to carry ATSC to HDTVs. That can be done with 64-bit addressing in an IPv4 footprint. The Destination Address is most critical to deliver the AV show to the right viewer. IPv6 is too little, too late, in too big a package and at a high price. UNIX-based CPE is now under $50. Anyone can download the complete open source and all the tools to build it. http://www.linksysbycisco.com/gpl UNIX-to-UNIX Service-Based solutions pre-date many ARPA DARPA DOD funding programs run by people who do not write code, they write contracts and purchase orders. What is "The Internet" TCP/IP or UNIX-to-UNIX ? From jmamodio at gmail.com Sat Apr 3 20:49:43 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sat, 3 Apr 2010 20:49:43 -0500 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: References: Message-ID: > What is "The Internet" TCP/IP or UNIX-to-UNIX ? None of the above. Read the instructions manual and don't abuse your meds. J. From jgreco at ns.sol.net Sat Apr 3 21:36:55 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 3 Apr 2010 20:36:55 -0600 (CST) Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: from "IPv3.com" at Apr 03, 2010 08:38:46 PM Message-ID: <201004040236.o342at51023284@aurora.sol.net> > What if TCP is removed ? and IP is completely re-worked in the same > 160-bit foot-print as IPv4 ? Would 64-bit Addressing last a few years ? > > IPv6 is a loser because everyone has to carry the overhead of bloated > packets. It is a one-size-fits-all take it or leave it solution. By that logic, wouldn't IPv4 also be considered a loser because everyone has been carrying the overhead of bloated packets for years? Especially near the beginning, we didn't need a 32-bit-sized address ... And why would we jump to 64-bit addressing, since you're so worried about the bloat in packets? Wouldn't it be more sensible to move to 36-bit or 40-bit addresses? If we jump to 64, aren't we wasting at least 56 bits per packet then (2 * (64 - 36))? And if we're going to completely re-work IP, why wouldn't we just move to a version that ensures addresses are plentiful? And if we're going to do that, why not just go with 128 bits? Bits are cheap. I mean, really, really, really, REALLY cheap. Trading a few bytes worth in order to get a solution that'll last us for the rest of our lifetimes (and then some) is a no-brainer. However, if you're really interested in it, I suggest you read the message I posted, subject of "Important", a few days ago. It suggests a bloat-free way to continue to grow the existing network. It's completely practical and I think you should promote it. ... 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 nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Apr 3 22:31:45 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 4 Apr 2010 13:01:45 +0930 Subject: legacy /8 In-Reply-To: <451188.24584.qm@web31802.mail.mud.yahoo.com> References: <20100404104500.1c7b6d49@opy.nosense.org> <451188.24584.qm@web31802.mail.mud.yahoo.com> Message-ID: <20100404130145.4c2c5000@opy.nosense.org> On Sat, 3 Apr 2010 18:37:51 -0700 (PDT) David Barak wrote: > --- On Sat, 4/3/10, Mark Smith wrote: > > To: "George Bonser" > > > No.? But that isn't the point.? The point is > > that v6 was a bad solution > > > to the problem.? Rather than simply address the > > address depletion > > > problem, it also "solves" a lot of problems that > > nobody has while > > > creating a whole bunch more that we will have. > > > > Ever used IPX or Appletalk? If you haven't, then you don't > > know how > > simple and capable networking can be. And those protocols > > were designed > > more than 20 years ago, yet they're still more capable than > > IPv4. > > Spoken like someone who has forgotten how much {fun|trouble} cable range + zones were... > I'll admit I didn't do enough with Appletalk to fully understand Zones. However I do like how cable ranges allow you to have odd numbers of multipes of 256 nodes, rather than doubling or halving the subnet size, as is the case with IPv4. > IPX, AppleTalk, VINES, DECNet, SNA, and all of the other protocol suites which were kicking around in the 80s and early 90s each had the "one thing they do really really well," but none of them were sufficiently flexible, extensible, easy, or cheap to capture the market. > > Examples of some things which those protocols *didn't* do well include (obviously the list is different for each individual protocol): > In a lot of cases they were add-ons to IPv4 too. Crypto was an add on, multicast was an add on, more than 256 networks was an add on, IPv4 isn't always cheap and easy to implement because of IPR clauses. Centralised, database driven address administration via DHCP is probably unique, however distributed centralised services were available in IPX and Appletalk via SAP, NDS, NBP and ZIP. > * interdomain routing - most were optimized for single-administrative control networks > * multicast > * handle an encryption layer at layer 3 > * cheap + easy to implement, no license required > * distributed centralized administration (i.e. DHCP servers) > * tolerate a wide variety of {link|connection} performance characteristics > The following are worth having look at, as they show what was the state of the art when they were published in 1985. "Xerox Network Systems Architecture - Introduction to Xerox Network Systems" http://bitsavers.org/pdf/xerox/xns/XNSG058504_XNS_Introduction.pdf "Xerox Network Systems Architecture - General Information Manual" http://bitsavers.org/pdf/xerox/xns/XNSG068504_XNS_GenInfo.pdf Most of the things on your list are there, or could have been as added using the same methods used to add them to IPv4. > > I think IPv6 has not just learnt from the history of IPv4, > > it has also learnt from the history of other protocols. > > Sadly, though, it also picked up some of the mistaken optimizations from the other protocols. The mess that has been made of RA+SLAAC+DHCPv6+DNS is something which can't be described as "elegant," and I certainly don't find it an improvement over IPv4 DHCP+DNS. > Unfortunately I think that was always going to happen. I don't think there is as strong a need for centralised management of IP address space as what DHCP/BOOTP/RARP have provided. However as DHCP et al. is the only way to do autoconf in IPv4, I think people were always going to want to have a stateful equivalent in IPv6 as they're comfortable with it. If people were prepared to have given up the "DHCP way" of managing addresses, and had accepted using link layer addresses as layer 3 node addresses, like XNS did (and IPv4 originally did too - RFC826 is the in 800s for a reason), then IPv6 could have been simpler by not having to have a neighbor discovery protocol to map layer 3 to layer 2 addresses. I'm hoping multicast DNS and DNS-Service Discovery become more popular. In conjunction with IPv6 SLAAC, the Internet will have finally caught up with what people were easily doing in the early 1990s with Appletalk and IPX. Regards, Mark. From dhc2 at dcrocker.net Sat Apr 3 22:53:30 2010 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Sat, 03 Apr 2010 20:53:30 -0700 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: References: Message-ID: <4BB80D3A.1020709@dcrocker.net> On 4/3/2010 6:38 PM, IPv3.com wrote: > What is "The Internet" TCP/IP or UNIX-to-UNIX ? > > As of 2010, many people would likely answer that question based on > the Services they use as opposed to a religious adoration for TCP/IP. See: ...anti-v6 religious diatribe elided... mis-directed attack, in spite of having such an easy target. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From randy at psg.com Sun Apr 4 00:29:59 2010 From: randy at psg.com (Randy Bush) Date: Sun, 04 Apr 2010 14:29:59 +0900 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: References: Message-ID: > UNIX-to-UNIX Service-Based solutions pre-date many ARPA DARPA DOD > funding programs run by people who do not write code you're shocking lack of clue is showing randy From avg at kotovnik.com Sun Apr 4 01:11:09 2010 From: avg at kotovnik.com (Vadim Antonov) Date: Sat, 3 Apr 2010 23:11:09 -0700 (PDT) Subject: legacy /8 In-Reply-To: <20100404104500.1c7b6d49@opy.nosense.org> Message-ID: With all that bitching about IPv6 how come nobody wrote an RFC for a very simple solution to the IPv4 address exhaustion problem: Step 1: specify an IP option for extra "low order" bits of source & destination address. Add handling of these to the popular OSes. Step 2: make NATs which directly connect extended addresses but also NAT them to non-extended external IPs. Step 3: leave backones unchanged. Gradually reduce size of allocated blocks forcing people to NAT as above. Step 4: watch people migrating their apps to extended addresses to avoid dealing with NAT bogosity and resulting tech support calls & costs. Step 5: remove NATs. --vadim From adrian at creative.net.au Sun Apr 4 01:34:25 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Sun, 4 Apr 2010 14:34:25 +0800 Subject: legacy /8 In-Reply-To: References: <20100404104500.1c7b6d49@opy.nosense.org> Message-ID: <20100404063425.GE31245@skywalker.creative.net.au> On Sat, Apr 03, 2010, Vadim Antonov wrote: > Step 1: specify an IP option for extra "low order" bits of source & > destination address. Add handling of these to the popular OSes. Don't IP options translate to "handle in slow path" on various routing platforms? :) THat makes "leave backbones unchanged" not happen. Adrian From dwhite at olp.net Sun Apr 4 01:34:47 2010 From: dwhite at olp.net (Dan White) Date: Sun, 4 Apr 2010 01:34:47 -0500 Subject: legacy /8 In-Reply-To: References: <20100404104500.1c7b6d49@opy.nosense.org> Message-ID: <20100404063446.GC18195@dan.olp.net> On 03/04/10?23:11?-0700, Vadim Antonov wrote: >With all that bitching about IPv6 how come nobody wrote an RFC for a very >simple solution to the IPv4 address exhaustion problem: +1 years. >Step 1: specify an IP option for extra "low order" bits of source & >destination address. Add handling of these to the popular OSes. +5 years. >Step 2: make NATs which directly connect extended addresses but also NAT >them to non-extended external IPs. > >Step 3: leave backones unchanged. Gradually reduce size of allocated >blocks forcing people to NAT as above. Never. >Step 4: watch people migrating their apps to extended addresses to avoid >dealing with NAT bogosity and resulting tech support calls & costs. +10 years. >Step 5: remove NATs. This is a good example of why patching v4 or trying to maintain backwards compatibility is not practical. -- Dan White From jeroen at mompl.net Sun Apr 4 02:51:06 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Sun, 04 Apr 2010 00:51:06 -0700 Subject: interop show network (was: legacy /8) Message-ID: <4BB844EA.70305@mompl.net> Someone in another thread mentioned interop show network. Which made me curious and I did a bit of searching. I found the following article from 2008 about the interop show: http://www.networkworld.com/community/node/27583 The show could setup an IPv6 only network in order to showcase it? That'd free up a /8. "There are an enormous number of vendors that are either not ready for IPv6, or are simply unwilling to say that supporting IPv6 is the future requirement for enterprise network operators. This future is a lot closer than many expect. Only a handful of the large network hardware vendors at the show were in better shape. I'm sure that's because those companies that have been tracking or leading the IPv6 protocol work within the IETF; however, not many displayed that capability outright on their booths. (..) So why is Interop so late to the IPv6 world? No good answer seemed to be present. My guess is that it's because Interop itself has a /8's worth of IPv4 space ? space allocated back in 1991 specifically for the Interop tradeshows. That's a lot of address space and a quick calculation shows that Interop has permanently allocated nearly half a percent of the presently used IPv4 address space. Maybe that address space should be returned to IANA? Maybe Interop should run a show where IP allocation is also part of the pre-show network planning. Then, maybe, they will see the light and realize that IPv6 is important! Perhaps with IPv6 available, Interop will also start showing off new applications and capabilities that IPv6 brings to the table." The author though is an employee of hurricane electric. Which is interesting because I have 166 netblocks for that company in my permanent spam block list. Including 12*/24 blocks and 1*/18. And I have no doubt that will be increasing. So I guess that puts it in a perspective. Regards, Jeroen From owen at delong.com Sat Apr 3 11:16:56 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 3 Apr 2010 09:16:56 -0700 Subject: legacy /8 In-Reply-To: <4BB6F65D.4000907@mompl.net> References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> <3135E5A4-A45F-44A3-A01D-A86F71988E45@delong.com> <4BB6F65D.4000907@mompl.net> Message-ID: <207E4E4F-B642-424E-8649-810A589DA54B@delong.com> On Apr 3, 2010, at 1:03 AM, Jeroen van Aart wrote: > Owen DeLong wrote: >> It was thought that we would not have nearly so many people connected to the internet. It was expected that most things connecting to the internet would be minicomputers and mainframes. > > It took some visionary and creative thinking to "come up" with the internet. But given such a train of thought the idea of everyone being connected isn't such a wild idea. I can imagine it'd be almost a given. > You need a better view backwards in time to contextualize this. The vision of everyone being connected was there. Everyone would have access to one or more of the approximately 5 million or so minicomputers and mainframes that was expected to be connected to the internet. It was based on 56kbit lines and the primary applications were email, ftp, and telnet. (I believe in that order, too). IRC was added several years later. > Although if I get the time frame right in those days you had 2 camps, those (ibm, dec...) who believed that there was no need for home computers and you only needed a few (hundred?) thousand big mainframes and minicomputers and those (commodore, apple...) who believed (rightfully so) there was going to be a big future and demand for home computers. > I believe the IPv4 classful addressing scheme (which some have pointed out was the second IPv4 addressing scheme, I wasn't involved early enough for the first, so didn't remember it) predates commodore, apple, etc. > So I guess depending on what "camp" you were in, it's not that strange to not envision all these household computers being interconnected. > At the time, connecting was very expensive. Getting one of the DS-0 circuits required in order to get on to the backbone was more than $500/month in most locations. Owen From owen at delong.com Sat Apr 3 23:12:45 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 3 Apr 2010 21:12:45 -0700 Subject: legacy /8 In-Reply-To: References: Message-ID: On Apr 3, 2010, at 2:49 PM, Zaid Ali wrote: > They are not glowing because applications are simply not moving to IPv6. > Google has two popular applications on IPv6, Netflix is on it way there but > what are other application companies doing about it? A popular application > like e-mail is so far behind [ref: > http://eng.genius.com/blog/2009/09/14/email-on-ipv6/] and I still encounter > registrar's providing DNS service not supporting Quad A's. > Uh, netflix seems fully functional to me on IPv6. What do you think is missing? The registrar problem is definitely real... I'm having tremendous difficulty with OpenSRS. (If anyone from OpenSRS is listening, please fix this!!) My email seems to work fine dual-stacked when I haven't borked the router. > I feel talking to network operators is preaching to the choir, the challenge > is helping content providers think about moving to IPv6. > Indeed. Owen From zaid at zaidali.com Sun Apr 4 03:43:49 2010 From: zaid at zaidali.com (Zaid Ali) Date: Sun, 04 Apr 2010 01:43:49 -0700 Subject: legacy /8 In-Reply-To: Message-ID: This sounds like Step 1: I have a wisdom tooth, it hurts on my right jaw and so I will chew from my left. Step 2: Take some pain killers. Step 3: Damn it hurts I will ignore it and it will eventually heal. Step 4: Continue to take pain killers and perhaps if I sleep more it will grow in the right direction and everything will be fine. Step 5: Wake up everything is fine. You will actually wake up without a toothache and things will seem fine except you now have teeth you don't actually need because they will cause blockage, hard to brush, floss constraints, many future dental trips etc. Your ancestors needed wisdom teeth in the stone age because they bit off more than they could chew, food was rough and coarse and teeth fell out easily. Through evolution diet changed and jaws eventually became smaller and humans chewed differently so you don't need the protection of wisdom teeth. Given that understanding you can avoid 5 painful steps and go to a doctor to have it pulled out, slight extra pain in doing so but you gain healthier teeth. Leaving dentistry and coming back to IP, we have to think of what we want the future IP address model to be and how does it affects the future of the Internet model. A lot of smart people have come together to bring the IPv6 solution, it works (not without flaws but neither did IPv4 in the early days) so lets work together in figuring out implementation and adoption. There is nothing stopping anyone from writing an RFC on IP option for low order bits+NAT et al and to that I wish anyone well. Just make sure one addresses scaling/backward compatibility because it will be like not being able to predict what kind of food will get stuck around your oddly grown wisdom tooth that caused a hole and now need a filling. Implementing IPv4 patches/NAT etc will not harm or break the Internet model but the question is do we want this or do we want to implement IPv6 that may be have a bit of pain now but the right thing for the future. Lets go where we want and have a healthy Internet, adopt IPv6 and phase out IPv4. Zaid P.s. Disclaimer: I have always been a network operator and never a dentist. I did build networks for a medical university many moons ago and often got into interesting discussions about medicine. On 4/3/10 11:11 PM, "Vadim Antonov" wrote: > > With all that bitching about IPv6 how come nobody wrote an RFC for a very > simple solution to the IPv4 address exhaustion problem: > > Step 1: specify an IP option for extra "low order" bits of source & > destination address. Add handling of these to the popular OSes. > > Step 2: make NATs which directly connect extended addresses but also NAT > them to non-extended external IPs. > > Step 3: leave backones unchanged. Gradually reduce size of allocated > blocks forcing people to NAT as above. > > Step 4: watch people migrating their apps to extended addresses to avoid > dealing with NAT bogosity and resulting tech support calls & costs. > > Step 5: remove NATs. > > --vadim > > From wavetossed at googlemail.com Sun Apr 4 03:46:42 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Sun, 4 Apr 2010 09:46:42 +0100 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> Message-ID: >> If "every significant router on the market" supported IPv6 five years ago, > > and if cash fell from the sky ... > > to folk actually running real networks, 'support' means *parity* with > ipv4, i.e. fast path at decent rates, management and monitoring, no > licensing extortion, ... > > we don't have that today! We need more of the spirit of the old days of networking when people building UUCP, and Fidonet and IP networks did less complaining about "vendors" and made things work as best they could. Eventually, the vendors caught on and jumped on the bandwagon. The fact is that lack of fastpath support doesn't matter until IPv6 traffic levels get high enough to need the fastpath. Today we need to get more complete IPv6 coverage. And if management and monitoring work fine on IPv4 and networks are dual-stacked, why change? Do you have an actual example of a vendor, today, charging a higher license fee for IPv6 support? > the *additional* cost and effort to the isp of fullly deploying > dual-stack is still non-trivial. ?this is mightily off-pissing. Nobody promised you a free lunch. In any case, the investment required to turn up IPv6 support is a lot less than the cost of carrier grade NAT. And the running costs of IPv6 are also lower, --Michael Dillon From zaid at zaidali.com Sun Apr 4 03:59:15 2010 From: zaid at zaidali.com (Zaid Ali) Date: Sun, 04 Apr 2010 01:59:15 -0700 Subject: legacy /8 In-Reply-To: Message-ID: On 4/3/10 9:12 PM, "Owen DeLong" wrote: > Uh, netflix seems fully functional to me on IPv6. What do you think is > missing? Functional is the easy part and it seems Netflix has executed that well. I was implying that the v6 traffic rate might not be quite there yet which is what we saw with Google a while back but eventually v6 traffic started to multiply. I could be wrong here and happy to be corrected. Zaid From jwbensley at gmail.com Sun Apr 4 04:10:44 2010 From: jwbensley at gmail.com (James Bensley) Date: Sun, 4 Apr 2010 10:10:44 +0100 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: References: Message-ID: If you did some more reading this would all be come clear? On 4 April 2010 02:38, IPv3.com wrote: > What is "The Internet" TCP/IP or UNIX-to-UNIX ? > Well both and neither, both of these are used and much more! > As of 2010, many people would likely answer that question based on > the Services they use as opposed to a religious adoration for TCP/IP. What if TCP is removed ? and IP is completely re-worked in the same > 160-bit foot-print as IPv4 ? Would 64-bit Addressing last a few years ? That isn't going to happen to house it, think about how massively its implemented? > IPv6 is a loser because everyone has to carry the overhead of bloated > packets. It is a one-size-fits-all take it or leave it solution. > People leave it. > > The real (new?) need is ONE-WAY streaming to carry ATSC to HDTVs. > That can be done with 64-bit addressing in an IPv4 footprint. The > Destination > Address is most critical to deliver the AV show to the right viewer. > > IPv6 is too little, too late, in too big a package and at a high price. > Some would agree, I don't. And its not too little to late because many people have already changing to IPv6, I think its quite high up there on ISPs todo list for those who haven't. > UNIX-based CPE is now under $50. Anyone can download the complete > open source and all the tools to build it. > http://www.linksysbycisco.com/gpl > > UNIX-to-UNIX Service-Based solutions pre-date many ARPA DARPA DOD > funding programs run by people who do not write code, they write contracts > and purchase orders. > > What is "The Internet" TCP/IP or UNIX-to-UNIX ? > Both and more. With your UNIX-to-UNIX suggestion, I'm not 100% sure on what you mean but what protocols do you think Unix uses? 'Cos it aint guna be Unix-Internet-Protocol/Transmission Control Protocol is it? Also when you say Unix systems I get the impression you are hinting at something open source, especially as that URL ends in /gpl but Unix isn't open source only some various of it are so if you were counting on open source as a solution, I don't believe you can. -- Regards, James. http://www.jamesbensley.co.cc/ From jwbensley at gmail.com Sun Apr 4 04:12:37 2010 From: jwbensley at gmail.com (James Bensley) Date: Sun, 4 Apr 2010 10:12:37 +0100 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: References: Message-ID: Sorry for double post: Also having the email account ipv3.com at gmail.com, thats not very useful? This sort email address should be on the list rules like that other fellow who was spamming about top 50 AS's for botnets/spam etc. -- Regards, James. http://www.jamesbensley.co.cc/ From lists at internetpolicyagency.com Sun Apr 4 04:40:40 2010 From: lists at internetpolicyagency.com (Roland Perry) Date: Sun, 4 Apr 2010 10:40:40 +0100 Subject: legacy /8 In-Reply-To: <207E4E4F-B642-424E-8649-810A589DA54B@delong.com> References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> <3135E5A4-A45F-44A3-A01D-A86F71988E45@delong.com> <4BB6F65D.4000907@mompl.net> <207E4E4F-B642-424E-8649-810A589DA54B@delong.com> Message-ID: In article <207E4E4F-B642-424E-8649-810A589DA54B at delong.com>, Owen DeLong writes >I believe the IPv4 classful addressing scheme (which some have pointed >out was the second IPv4 addressing scheme, I wasn't involved early >enough for the first, so didn't remember it) predates commodore, apple, >etc. On a historical note, if Classful Addressing is deemed to date from rfc792 (1981) [but I'd be grateful for other nominations of a suitable alternate date] then that post-dates the Commodore PET and Apple II which were both launched in 1977. Some sources claim the PET is later, but I remember it because I was doing a project on "PCs in Schools" in the spring of 1977, using an 8-bit PC that I had built myself on a patchboard. And the PET arrived just in time for me to be able say to "I'm not completely insane - a viable PC you could install in a school is now commercially available". -- Roland Perry From youareanidiot at bogus.com Sun Apr 4 04:59:07 2010 From: youareanidiot at bogus.com (Randy Bush) Date: Sun, 04 Apr 2010 18:59:07 +0900 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: References: Message-ID: > Also having the email account ipv3.com at gmail.com, thats not very > useful? an amazing insight! we need an email address police to get rid of those folk who have un-american email addresses. randy From ipv3.com at gmail.com Sun Apr 4 05:00:18 2010 From: ipv3.com at gmail.com (IPv3.com) Date: Sun, 4 Apr 2010 05:00:18 -0500 Subject: Was a 1956 Video Phone User - "On the Internet" ? Message-ID: Based on these ASCII notes...(c. 1995 cave paintings)... http://www.ietf.org/rfc/rfc1775.txt Was a 1956 Video Phone User - "On the Internet" ? http://www.porticus.org/bell/telephones-picturephone.html Is a 2010 HDTV (ATSC DLNA) viewer - "On the Internet" ? Note for IPv6 archeologists...Mobile Digital TV went with IPv4+Shim http://www.atsc.org Funding of the so-called Eco-System (aka Idle Rich Society) also appears to define "The Internet" in some circles. It appears 100+ people live off of Internet Fees for doing largely nothing. They of course travel to explain why that structure is essential. Is it ? From ipv3.com at gmail.com Sun Apr 4 05:19:24 2010 From: ipv3.com at gmail.com (IPv3.com) Date: Sun, 4 Apr 2010 05:19:24 -0500 Subject: Tidbits & the "NANOG Community" Message-ID: Tidbits & the "NANOG Community" ... with respect to jumping from 32-bits to 64-bits many UNIX-to-UNIX users have noted... ONE more bit (33) may be enough to distinguish Legacy from New. The bit would go on the Left as opposed to Right which would double the existing mess. ... Linux has the added bit ready in the SPARE bit and the Left-most TTL bit deprecated to 0 years ago. A Source+Destination pair is needed for full interchange between Legacy and New. A single bit would be isolated planes. ... Based on a survey of IPv4 Address Space the "NANOG Community" does not appear to involve many critical back-bones or infrastructure. In some circles that would not be considered "On the Internet". YMMV From randy at psg.com Sun Apr 4 05:23:50 2010 From: randy at psg.com (Randy Bush) Date: Sun, 04 Apr 2010 19:23:50 +0900 Subject: Tidbits & the "NANOG Community" In-Reply-To: References: Message-ID: From ipv3.com at gmail.com Sun Apr 4 05:24:50 2010 From: ipv3.com at gmail.com (IPv3.com) Date: Sun, 4 Apr 2010 05:24:50 -0500 Subject: As the "NANOG Community" Moves to IPv6... Message-ID: As the "NANOG Community" Moves to IPv6... ... it might be a Public Service to post the IPv4 /8s made available. ... without that, Carriers may [assume] they are no longer in use and start using them for their expansion ... the DNS AAAA records of course flag your move to IPv6 From mmc at internode.com.au Sun Apr 4 05:40:54 2010 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sun, 4 Apr 2010 20:10:54 +0930 Subject: As the "NANOG Community" Moves to IPv6... In-Reply-To: References: Message-ID: <3FD722E7-BAC0-4E6A-826F-E0AB8637EC89@internode.com.au> On 04/04/2010, at 7:54 PM, IPv3.com wrote: > As the "NANOG Community" Moves to IPv6... > ... > it might be a Public Service to post the IPv4 /8s made available. > ... http://www.iana.org/assignments/ipv4-address-space/ MMC From ops.lists at gmail.com Sun Apr 4 05:53:45 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 4 Apr 2010 16:23:45 +0530 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: References: Message-ID: On Sun, Apr 4, 2010 at 2:42 PM, James Bensley wrote: > > Also having the email account ipv3.com at gmail.com, thats not very useful? He's still got to reach the heights of IPv9 -- Suresh Ramasubramanian (ops.lists at gmail.com) From jgreco at ns.sol.net Sun Apr 4 07:49:29 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 4 Apr 2010 07:49:29 -0500 (CDT) Subject: legacy /8 In-Reply-To: from "Roland Perry" at Apr 04, 2010 10:40:40 AM Message-ID: <201004041249.o34CnUUt078737@aurora.sol.net> > In article <207E4E4F-B642-424E-8649-810A589DA54B at delong.com>, Owen > DeLong writes > >I believe the IPv4 classful addressing scheme (which some have pointed > >out was the second IPv4 addressing scheme, I wasn't involved early > >enough for the first, so didn't remember it) predates commodore, apple, > >etc. > > On a historical note, if Classful Addressing is deemed to date from > rfc792 (1981) [but I'd be grateful for other nominations of a suitable > alternate date] then that post-dates the Commodore PET and Apple II > which were both launched in 1977. If you wanted to consider the "high 8 bits = network, low 24 bits = host" model as being classful addressing, then that predates. I concede this is a bit dodgy. > Some sources claim the PET is later, but I remember it because I was > doing a project on "PCs in Schools" in the spring of 1977, using an > 8-bit PC that I had built myself on a patchboard. And the PET arrived > just in time for me to be able say to "I'm not completely insane - a > viable PC you could install in a school is now commercially available". Your memory seems to be in error; the PET was created for the June 1977 CES, and wasn't shipped to customers until at least later that year. It seems very likely that you received your PET in the spring of 1978. ... 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 tore.anderson at redpill-linpro.com Sun Apr 4 08:30:38 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Sun, 04 Apr 2010 15:30:38 +0200 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> Message-ID: <4BB8947E.3080502@redpill-linpro.com> * Michael Dillon > Do you have an actual example of a vendor, today, charging a higher > license fee for IPv6 support? Juniper. If you want to run OSPFv3 on their layer 3 switches, you need a quite expensive "advanced" licence. OSPFv2, on the other hand, is included in the base licence. Our IPv6 topology is largely based on static routes because of this. There's no customers that are willing to pay extra for IPv6 support at the moment, hence we cannot justify the extra cost of the licences. It sucks. I hope Juniper will come to their senses soon. BR, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From lists at internetpolicyagency.com Sun Apr 4 08:41:43 2010 From: lists at internetpolicyagency.com (Roland Perry) Date: Sun, 4 Apr 2010 14:41:43 +0100 Subject: legacy /8 In-Reply-To: <201004041249.o34CnUUt078737@aurora.sol.net> References: <201004041249.o34CnUUt078737@aurora.sol.net> Message-ID: In article <201004041249.o34CnUUt078737 at aurora.sol.net>, Joe Greco writes >> Some sources claim the PET is later, but I remember it because I was >> doing a project on "PCs in Schools" in the spring of 1977, using an >> 8-bit PC that I had built myself on a patchboard. And the PET arrived >> just in time for me to be able say to "I'm not completely insane - a >> viable PC you could install in a school is now commercially available". > >Your memory seems to be in error; the PET was created for the June 1977 >CES, and wasn't shipped to customers until at least later that year. It >seems very likely that you received your PET in the spring of 1978. I use the expressions "arrived" and "available" in the spirit of vapourware that was endemic in the industry at the time. In other words, it was when the product was "introduced". It's true that we would not have expected to see a real one in the UK until much later. There are at least two sources which date the PET to "Winter CES" and "Jan 1977", but I agree that June CES is where production items would be first shown; however by then schools were out and my project was finished (I was studying to be maths teacher). -- Roland Perry From leen at consolejunkie.net Sun Apr 4 08:44:07 2010 From: leen at consolejunkie.net (Leen Besselink) Date: Sun, 04 Apr 2010 15:44:07 +0200 Subject: legacy /8 In-Reply-To: <32099.1270316348@localhost> References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> <3135E5A4-A45F-44A3-A01D-A86F71988E45@delong.com> <4BB6F65D.4000907@mompl.net> <4BB6FE6F.700@jsbc.cc> <32099.1270316348@localhost> Message-ID: <4BB897A7.60503@consolejunkie.net> On 04/03/2010 07:39 PM, Valdis.Kletnieks at vt.edu wrote: > On Sat, 03 Apr 2010 08:06:44 EDT, Jeffrey Lyon said: > > >> For small companies the cost of moving to IPv6 is far too great, >> especially when we rely on certain DDoS mitigation gear that does not >> yet have an IPv6 equivalent. >> > So? How many people are *realistically* being hit by IPv6 DDoS right now? > (I saw a number in the last 2-3 days that 2-3% of spam is now being delivered > via SMTP-over-IPv6). You may not need that gear as much as you thought... > > This maybe ?: http://labs.ripe.net/content/spam-over-ipv6 "Out of the total number of emails received, 14% were received over IPv6, the rest over IPv4." "Looking only at the number of e-mails received over IPv6, 3.5% were classified as spam, the rest were legitimate." But then again this is a pretty low number as well: "Looking only at the number of emails received over IPv4: 31% were classified as spam, the rest were legitimate." Some of us deal with 98% or more. > Did you tell your mitigation gear vendor 5 years ago that their next model > needed to have IPv6 support? > > Given that currently most stuff is dual-stack, and IPv6 isn't totally > widespread, what are the effects of doing IPv6 DDoS mitigation by simply > turning off IPv6 on your upstream link and letting traffic fall back to IPv4 > where you have mitigation gear? > > From sfouant at shortestpathfirst.net Sun Apr 4 08:46:08 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Sun, 4 Apr 2010 13:46:08 +0000 Subject: Tidbits & the "NANOG Community" Message-ID: <244352414-1270388747-cardhu_decombobulator_blackberry.rim.net-1933095789-@bda294.bisx.prod.on.blackberry> Sounds like this guy could benefit from some carpeting and a few Roombas in his Data Center ;) Stefan Fouant ------Original Message------ From: Randy Bush To: IPv3.com Cc: nanog at nanog.org Subject: Re: Tidbits & the "NANOG Community" Sent: Apr 4, 2010 6:23 AM Sent from my Verizon Wireless BlackBerry From LarrySheldon at cox.net Sun Apr 4 09:02:53 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 04 Apr 2010 09:02:53 -0500 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: <201004040236.o342at51023284@aurora.sol.net> References: <201004040236.o342at51023284@aurora.sol.net> Message-ID: <4BB89C0D.2000007@cox.net> On 4/3/2010 21:36, Joe Greco wrote: >> What if TCP is removed ? and IP is completely re-worked in the same >> 160-bit foot-print as IPv4 ? Would 64-bit Addressing last a few years ? I must have dozed off--what is the connection between the Subject: and the recent traffic under it. "The Internet" (Note caps) is the (I'd like to say "web" but that will be misunderstood--current usage is actually correct, but bigger than porn and such) of connections between networks. Its connection layer is IP, other protocols such as UDP and IP (AND OTHERS) "ride" on IP, which in turn rides on one or more layers of facility-relevant transport protocols. UUCP is not a descriptor of any kind of a network in any engineering sense that I know of. It is a point-to-point communications protocol. Other protocols, including network protocols (NNTP, SMTP) used in networking as a sociologist might use the term. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Sun Apr 4 09:17:04 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 04 Apr 2010 09:17:04 -0500 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: References: Message-ID: <4BB89F60.2040006@cox.net> On 4/4/2010 00:29, Randy Bush wrote: >> UNIX-to-UNIX Service-Based solutions pre-date many ARPA DARPA DOD >> funding programs run by people who do not write code > > you're shocking lack of clue is showing As is the lack of access to any of a large collection of books, articles, and anecdotes. ("Access" here meaning physical access to a document, or practical access meaning "unable to derive meaning from a document in hand.) -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From patrick at ianai.net Sun Apr 4 09:22:20 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 4 Apr 2010 10:22:20 -0400 Subject: As the "NANOG Community" Moves to IPv6... In-Reply-To: <3FD722E7-BAC0-4E6A-826F-E0AB8637EC89@internode.com.au> References: <3FD722E7-BAC0-4E6A-826F-E0AB8637EC89@internode.com.au> Message-ID: On Apr 4, 2010, at 6:40 AM, Matthew Moyle-Croft wrote: > On 04/04/2010, at 7:54 PM, IPv3.com wrote: > >> As the "NANOG Community" Moves to IPv6... >> ... >> it might be a Public Service to post the IPv4 /8s made available. >> ... > > http://www.iana.org/assignments/ipv4-address-space/ Please don't feed the troll. -- TTFN, patrick P.S. Does anyone else think that perhaps "ipv3.com" == "Guillaume FORTAINE"? From sthaug at nethelp.no Sun Apr 4 09:31:25 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sun, 04 Apr 2010 16:31:25 +0200 (CEST) Subject: legacy /8 In-Reply-To: <4BB8947E.3080502@redpill-linpro.com> References: <4BB8947E.3080502@redpill-linpro.com> Message-ID: <20100404.163125.41679142.sthaug@nethelp.no> > > Do you have an actual example of a vendor, today, charging a higher > > license fee for IPv6 support? > > Juniper. If you want to run OSPFv3 on their layer 3 switches, you need > a quite expensive "advanced" licence. OSPFv2, on the other hand, is > included in the base licence. > > Our IPv6 topology is largely based on static routes because of this. > There's no customers that are willing to pay extra for IPv6 support at > the moment, hence we cannot justify the extra cost of the licences. It > sucks. I hope Juniper will come to their senses soon. It used to be considerably worse. As late as May 2009, Juniper charged $10.000 (list price) for an "IPv6 Support on JunOS" on license (for high end M/MX/T series), and the same amount for an E series IPv6 license. Fortunately Juniper seems to have come to their senses here, and these licenses are now $0. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From lists at internetpolicyagency.com Sun Apr 4 09:42:10 2010 From: lists at internetpolicyagency.com (Roland Perry) Date: Sun, 4 Apr 2010 15:42:10 +0100 Subject: legacy /8 In-Reply-To: <4BB897A7.60503@consolejunkie.net> References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> <3135E5A4-A45F-44A3-A01D-A86F71988E45@delong.com> <4BB6F65D.4000907@mompl.net> <4BB6FE6F.700@jsbc.cc> <32099.1270316348@localhost> <4BB897A7.60503@consolejunkie.net> Message-ID: In article <4BB897A7.60503 at consolejunkie.net>, Leen Besselink writes >> (I saw a number in the last 2-3 days that 2-3% of spam is now being delivered >> via SMTP-over-IPv6). You may not need that gear as much as you thought... > >This maybe ?: >http://labs.ripe.net/content/spam-over-ipv6 > >"Out of the total number of emails received, 14% were received over >IPv6, the rest over IPv4." RIPE NCC has been running ipv6 mail for some time, so this may be higher than average. >"Looking only at the number of e-mails received over IPv6, 3.5% were >classified as spam, the rest were legitimate." > >But then again this is a pretty low number as well: > >"Looking only at the number of emails received over IPv4: 31% were >classified as spam, the rest were legitimate." > >Some of us deal with 98% or more. Don't forget it also said: "this excludes messages already rejected by blacklisting and greylisting ... and sent to non-existent email addresses within the ripe.net domain" and: "Additionally, our statistics only take our primary MX system into account (and not email sent from the secondary MX system to the primary)." -- Roland Perry From LarrySheldon at cox.net Sun Apr 4 09:45:44 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 04 Apr 2010 09:45:44 -0500 Subject: Was a 1956 Video Phone User - "On the Internet" ? In-Reply-To: References: Message-ID: <4BB8A618.3060309@cox.net> On 4/4/2010 05:00, IPv3.com wrote: > Based on these ASCII notes...(c. 1995 cave paintings)... > http://www.ietf.org/rfc/rfc1775.txt > > Was a 1956 Video Phone User - "On the Internet" ? > http://www.porticus.org/bell/telephones-picturephone.html > > Is a 2010 HDTV (ATSC DLNA) viewer - "On the Internet" ? > > Note for IPv6 archeologists...Mobile Digital TV went with IPv4+Shim > http://www.atsc.org > > Funding of the so-called Eco-System (aka Idle Rich Society) also > appears to define "The Internet" in some circles. It appears 100+ > people live off of Internet Fees for doing largely nothing. They of > course travel to explain why that structure is essential. Is it ? Are you sure you are on the right platform--sounds more like I would expect to hear in Amherst or Sproul hall. Or did you just forget to mention your point? To answer the question in the Subject: (the last time anything made sense to me in that message): No. It was an experiment in the PANS branch of POTS (PSTN to some people). -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From skandor at gmail.com Sun Apr 4 09:53:54 2010 From: skandor at gmail.com (A.B. Jr.) Date: Sun, 4 Apr 2010 11:53:54 -0300 Subject: what about 48 bits? Message-ID: Hi, Lots of traffic recently about 64 bits being too short or too long. What about mac addresses? Aren't they close to exhaustion? Should be. Or it is assumed that mac addresses are being widely reused throughout the world? All those low cost switches and wifi adapters DO use unique mac addresses? From jsage at finchhaven.com Sun Apr 4 09:56:25 2010 From: jsage at finchhaven.com (John Sage) Date: Sun, 04 Apr 2010 07:56:25 -0700 Subject: Was a 1956 Video Phone User - "On the Internet" ? In-Reply-To: <4BB8A618.3060309@cox.net> References: <4BB8A618.3060309@cox.net> Message-ID: <4BB8A899.7090803@finchhaven.com> Larry Sheldon wrote: > On 4/4/2010 05:00, IPv3.com wrote: >> Based on these ASCII notes...(c. 1995 cave paintings)... >> http://www.ietf.org/rfc/rfc1775.txt >> >> Was a 1956 Video Phone User - "On the Internet" ? >> http://www.porticus.org/bell/telephones-picturephone.html >> >> Is a 2010 HDTV (ATSC DLNA) viewer - "On the Internet" ? >> >> Note for IPv6 archeologists...Mobile Digital TV went with IPv4+Shim >> http://www.atsc.org >> >> Funding of the so-called Eco-System (aka Idle Rich Society) also >> appears to define "The Internet" in some circles. It appears 100+ >> people live off of Internet Fees for doing largely nothing. They of >> course travel to explain why that structure is essential. Is it ? > > > Are you sure you are on the right platform--sounds more like I would > expect to hear in Amherst or Sproul hall. > > Or did you just forget to mention your point? > > To answer the question in the Subject: (the last time anything made > sense to me in that message): > > No. It was an experiment in the PANS branch of POTS (PSTN to some people). The degree to which people subscribed to this list, apparently having nothing better to do, will respond to a blatant troll is breathtaking. Of course recent evidence shows quite clearly that [some] people subscribed to this list, apparently having nothing better to do, will respond to anything... - John From jmamodio at gmail.com Sun Apr 4 09:57:12 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 4 Apr 2010 09:57:12 -0500 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: <4BB89C0D.2000007@cox.net> References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> Message-ID: > UUCP is not a descriptor of any kind of a network in any engineering > sense that I know of. ?It is a point-to-point communications protocol. You should revise some of the history behind it. It was a descriptor for a very large network, it was even a TLD in the mid eighties when the transition to DNS was taking place, the old bang style addresses like mine original seismo!atina!pete transitioned for a while to pete at atina.UUCP and later to pete at atina.ar. UUCP was not just a point to point protocol. Originally it was a set of utility programs to permit copying files between Unix systems (Unix to Unix CoPy, hence the name), since electronic emails where essentially files UUCP became the transport mechanism for both electronic email and later Usenet News. Some referred to UUCP as Unix to Unix Communications Protocol, not quite right but yes one of the pieces of UUCP (uucico = Unix to Unix Copy in Copy Out) implemented different type of communication protocols negotiated during the initial handshake phase and fine tuned to different communication facilities, point to point, telephone modems, specific modems such as Telebit Trailblazers with PEP, different types of encapsulation using X.28, X25, and obviously TCP/IP. For several years until we've got a more decent telecommunications infrastructure UUCP was all we had in Argentina to let the academic and science community reach out and communicate with their colleagues around the world, we had an adapted version of the UUCP implementation for DOS (some called it UUPC) that became very popular and enabled our "UUCP network" to reach over 800 nodes in the early 90's when we later were able to get a direct (IP) connection to the rest of the world. My .02 Cheers Jorge From deleskie at gmail.com Sun Apr 4 09:57:25 2010 From: deleskie at gmail.com (jim deleskie) Date: Sun, 4 Apr 2010 11:57:25 -0300 Subject: what about 48 bits? In-Reply-To: References: Message-ID: I've seen duplicate addresses in the wild in the past, I assume there is some amount of reuse, even though they are suppose to be unique. -jim On Sun, Apr 4, 2010 at 11:53 AM, A.B. Jr. wrote: > Hi, > > Lots of traffic recently about 64 bits being too short or too long. > > What about mac addresses? Aren't they close to exhaustion? Should be. Or it > is assumed that mac addresses are being widely reused throughout the world? > All those low cost switches and wifi adapters DO use unique mac addresses? > From jmamodio at gmail.com Sun Apr 4 09:59:40 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 4 Apr 2010 09:59:40 -0500 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: <4BB89F60.2040006@cox.net> References: <4BB89F60.2040006@cox.net> Message-ID: >>> UNIX-to-UNIX Service-Based solutions pre-date many ARPA DARPA DOD >>> funding programs run by people who do not write code >> >> you're shocking lack of clue is showing > > As is the lack of access to any of a large collection of books, > articles, and anecdotes. ?("Access" here meaning physical access to a > document, or practical access meaning "unable to derive meaning from a > document in hand.) Or being so extremely stupid not using this medium to ask directly to many who were and are still part of it, many of them reading the non-operational contents of this list. Cheers Jorge From dga at cs.cmu.edu Sun Apr 4 10:10:56 2010 From: dga at cs.cmu.edu (David Andersen) Date: Sun, 4 Apr 2010 11:10:56 -0400 Subject: what about 48 bits? In-Reply-To: References: Message-ID: <1A45C388-F50A-44E5-9A58-C20E72E5A495@cs.cmu.edu> There are some classical cases of assigning the same MAC address to every machine in a batch, resetting the counter used to number them, etc.; unless shown otherwise, these are likely to be errors, not accidental collisions. -Dave On Apr 4, 2010, at 10:57 AM, jim deleskie wrote: > I've seen duplicate addresses in the wild in the past, I assume there > is some amount of reuse, even though they are suppose to be unique. > > -jim > > On Sun, Apr 4, 2010 at 11:53 AM, A.B. Jr. wrote: >> Hi, >> >> Lots of traffic recently about 64 bits being too short or too long. >> >> What about mac addresses? Aren't they close to exhaustion? Should be. Or it >> is assumed that mac addresses are being widely reused throughout the world? >> All those low cost switches and wifi adapters DO use unique mac addresses? >> > > From john-nanog at johnpeach.com Sun Apr 4 10:17:28 2010 From: john-nanog at johnpeach.com (John Peach) Date: Sun, 04 Apr 2010 11:17:28 -0400 Subject: what about 48 bits? In-Reply-To: <1A45C388-F50A-44E5-9A58-C20E72E5A495@cs.cmu.edu> References: <1A45C388-F50A-44E5-9A58-C20E72E5A495@cs.cmu.edu> Message-ID: <20100404111728.2b5c9ecf@milhouse.peachfamily.net> On Sun, 4 Apr 2010 11:10:56 -0400 David Andersen wrote: > There are some classical cases of assigning the same MAC address to every machine in a batch, resetting the counter used to number them, etc.; unless shown otherwise, these are likely to be errors, not accidental collisions. > > -Dave > > On Apr 4, 2010, at 10:57 AM, jim deleskie wrote: > > > I've seen duplicate addresses in the wild in the past, I assume there > > is some amount of reuse, even though they are suppose to be unique. > > > > -jim > > > > On Sun, Apr 4, 2010 at 11:53 AM, A.B. Jr. wrote: > >> Hi, > >> > >> Lots of traffic recently about 64 bits being too short or too long. > >> > >> What about mac addresses? Aren't they close to exhaustion? Should be. Or it > >> is assumed that mac addresses are being widely reused throughout the world? > >> All those low cost switches and wifi adapters DO use unique mac addresses? > >> Sun, for one, used to assign the same MAC address to every NIC in the same box. -- John From bill at herrin.us Sun Apr 4 10:31:08 2010 From: bill at herrin.us (William Herrin) Date: Sun, 4 Apr 2010 11:31:08 -0400 Subject: what about 48 bits? In-Reply-To: <20100404111728.2b5c9ecf@milhouse.peachfamily.net> References: <1A45C388-F50A-44E5-9A58-C20E72E5A495@cs.cmu.edu> <20100404111728.2b5c9ecf@milhouse.peachfamily.net> Message-ID: On Sun, Apr 4, 2010 at 11:17 AM, John Peach wrote: > Sun, for one, used to assign the same MAC address to every NIC in the > same box. Technically, they assigned a MAC to the NIC and a MAC to the box. Unless you configured it otherwise, all NICs in the box defaulted to using the box's MAC instead of their own. Made for some interesting problems with early VLAN switches... Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jim at reptiles.org Sun Apr 4 10:37:10 2010 From: jim at reptiles.org (Jim Mercer) Date: Sun, 4 Apr 2010 11:37:10 -0400 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> Message-ID: <20100404153710.GA52140@reptiles.org> On Sun, Apr 04, 2010 at 09:57:12AM -0500, Jorge Amodio wrote: > You should revise some of the history behind it. It was a descriptor > for a very large network, it was even a TLD in the mid eighties when > the transition to DNS was taking place, the old bang style addresses > like mine original seismo!atina!pete transitioned for a while to > pete at atina.UUCP and later to pete at atina.ar. i don't recall .uucp making it into the actual DNS, but i remember our mail system used it as a trigger to do a uucp-maps lookup. > For several years until we've got a more decent telecommunications > infrastructure UUCP was all we had in Argentina to let the academic > and science community reach out and communicate with their colleagues > around the world, we had an adapted version of the UUCP implementation > for DOS (some called it UUPC) that became very popular and enabled our > "UUCP network" to reach over 800 nodes in the early 90's when we later > were able to get a direct (IP) connection to the rest of the world. uucp introduced a far-flung group of hosts, academic and otherwise, to things that were popular on the internet, namely email and USENET. i'm sure its an open debate as to if being in the UUCP maps also meant that you were "on the Internet", but many people seemed or seem to think this way. i recall seeing uucp going into not only south america, but the caribbean, south pacific and many other regions, much the same way that you describe it. there were several organizations who were quite dedicated to using uucp over (dialup/X.25/carrier-pigeon) in order to extend email and USENET deep into the third world. -- Jim Mercer jim at reptiles.org +92 336 520-4504 From swmike at swm.pp.se Sun Apr 4 10:41:34 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 4 Apr 2010 17:41:34 +0200 (CEST) Subject: what about 48 bits? In-Reply-To: References: Message-ID: On Sun, 4 Apr 2010, jim deleskie wrote: > I've seen duplicate addresses in the wild in the past, I assume there > is some amount of reuse, even though they are suppose to be unique. 5 percent of the mac addresses in a ADSL population used the same MAC address. Turned out to be some D-link device that didn't have unique address but they all had the same, and had a feature where you could "clone" the internal PC MAC address if you wanted to, otherwise it used some default address. D-link support responded to customer inquiries with "yes, we know that they're not unique enough". Nuff said, avoid. -- Mikael Abrahamsson email: swmike at swm.pp.se From nanog at qualitymail.com Sun Apr 4 10:43:25 2010 From: nanog at qualitymail.com (William Duck) Date: Sun, 4 Apr 2010 08:43:25 -0700 Subject: UETS/EFR (was Re: what about 48 bits?) Message-ID: <20100404084325.96CBF667@resin12.mta.everyone.net> http://www.lmdata.es/uets.htm -------- Original Message -------- Subject: what about 48 bits? Date: Sun, 4 Apr 2010 11:53:54 -0300 From: A.B. Jr. To: nanog at nanog.org Hi, Lots of traffic recently about 64 bits being too short or too long. What about mac addresses? Aren't they close to exhaustion? Should be. Or it is assumed that mac addresses are being widely reused throughout the world? All those low cost switches and wifi adapters DO use unique mac addresses? _____________________________________________________________ Get your own *free* email address like this one from www.OwnEmail.com From jof at thejof.com Sun Apr 4 10:46:17 2010 From: jof at thejof.com (Jonathan Lassoff) Date: Sun, 04 Apr 2010 08:46:17 -0700 Subject: what about 48 bits? In-Reply-To: <20100404111728.2b5c9ecf@milhouse.peachfamily.net> References: <1A45C388-F50A-44E5-9A58-C20E72E5A495@cs.cmu.edu> <20100404111728.2b5c9ecf@milhouse.peachfamily.net> Message-ID: <1270395578-sup-3974@sfo.thejof.com> Excerpts from John Peach's message of Sun Apr 04 08:17:28 -0700 2010: > On Sun, 4 Apr 2010 11:10:56 -0400 > David Andersen wrote: > > > There are some classical cases of assigning the same MAC address to every machine in a batch, resetting the counter used to number them, etc.; unless shown otherwise, these are likely to be errors, not accidental collisions. > > > > -Dave > > > > On Apr 4, 2010, at 10:57 AM, jim deleskie wrote: > > > > > I've seen duplicate addresses in the wild in the past, I assume there > > > is some amount of reuse, even though they are suppose to be unique. > > > > > > -jim > > > > > > On Sun, Apr 4, 2010 at 11:53 AM, A.B. Jr. wrote: > > >> Hi, > > >> > > >> Lots of traffic recently about 64 bits being too short or too long. > > >> > > >> What about mac addresses? Aren't they close to exhaustion? Should be. Or it > > >> is assumed that mac addresses are being widely reused throughout the world? > > >> All those low cost switches and wifi adapters DO use unique mac addresses? > > >> > Sun, for one, used to assign the same MAC address to every NIC in the > same box. I could see how that *could* work as long as each interface connected to a different LAN. Maybe the NICs shared a single MII/MAC sublayer somehow? I've never borne witness to this though. Re: MAC address exhaustion, if the the second-to-least significant bit in the first byte is 0 (Globally Unique / Individually Assigned bit), then the first three bytes of the MAC should correspond to the manufacturer's "Organizationally Unique Identifier". These are maintained by the IEEE, and they have a list of who's who here: http://standards.ieee.org/regauth/oui/index.shtml I haven't ever programmatically gone through the list, but it looks like a lot of the space is assigned. Cheers, jof From marka at isc.org Sun Apr 4 10:49:38 2010 From: marka at isc.org (Mark Andrews) Date: Mon, 05 Apr 2010 01:49:38 +1000 Subject: what about 48 bits? In-Reply-To: Your message of "Sun, 04 Apr 2010 11:17:28 -0400." <20100404111728.2b5c9ecf@milhouse.peachfamily.net> References: <1A45C388-F50A-44E5-9A58-C20E72E5A495@cs.cmu.edu> <20100404111728.2b5c9ecf@milhouse.peachfamily.net> Message-ID: <201004041549.o34FnclI012123@drugs.dv.isc.org> In message <20100404111728.2b5c9ecf at milhouse.peachfamily.net>, John Peach writes: > On Sun, 4 Apr 2010 11:10:56 -0400 > David Andersen wrote: > > > There are some classical cases of assigning the same MAC address to every machine in a batch, resetting the counter used to number them, etc.; unless shown otherwise, these are > likely to be errors, not accidental collisions. > > > > -Dave > > > > On Apr 4, 2010, at 10:57 AM, jim deleskie wrote: > > > > > I've seen duplicate addresses in the wild in the past, I assume there > > > is some amount of reuse, even though they are suppose to be unique. > > > > > > -jim > > > > > > On Sun, Apr 4, 2010 at 11:53 AM, A.B. Jr. wrote: > > >> Hi, > > >> > > >> Lots of traffic recently about 64 bits being too short or too long. > > >> > > >> What about mac addresses? Aren't they close to exhaustion? Should be. Or it > > >> is assumed that mac addresses are being widely reused throughout the world? > > >> All those low cost switches and wifi adapters DO use unique mac addresses? > > >> > Sun, for one, used to assign the same MAC address to every NIC in the > same box. Which is perfectly legal. > > -- > John > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From smb at cs.columbia.edu Sun Apr 4 10:51:52 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sun, 4 Apr 2010 11:51:52 -0400 Subject: what about 48 bits? In-Reply-To: <1270395578-sup-3974@sfo.thejof.com> References: <1A45C388-F50A-44E5-9A58-C20E72E5A495@cs.cmu.edu> <20100404111728.2b5c9ecf@milhouse.peachfamily.net> <1270395578-sup-3974@sfo.thejof.com> Message-ID: On Apr 4, 2010, at 11:46 17AM, Jonathan Lassoff wrote: > Excerpts from John Peach's message of Sun Apr 04 08:17:28 -0700 2010: >> On Sun, 4 Apr 2010 11:10:56 -0400 >> David Andersen wrote: >> >>> There are some classical cases of assigning the same MAC address to every machine in a batch, resetting the counter used to number them, etc.; unless shown otherwise, these are likely to be errors, not accidental collisions. >>> >>> -Dave >>> >>> On Apr 4, 2010, at 10:57 AM, jim deleskie wrote: >>> >>>> I've seen duplicate addresses in the wild in the past, I assume there >>>> is some amount of reuse, even though they are suppose to be unique. >>>> >>>> -jim >>>> >>>> On Sun, Apr 4, 2010 at 11:53 AM, A.B. Jr. wrote: >>>>> Hi, >>>>> >>>>> Lots of traffic recently about 64 bits being too short or too long. >>>>> >>>>> What about mac addresses? Aren't they close to exhaustion? Should be. Or it >>>>> is assumed that mac addresses are being widely reused throughout the world? >>>>> All those low cost switches and wifi adapters DO use unique mac addresses? >>>>> >> Sun, for one, used to assign the same MAC address to every NIC in the >> same box. > > I could see how that *could* work as long as each interface connected to > a different LAN. > > Maybe the NICs shared a single MII/MAC sublayer somehow? I've never > borne witness to this though. There was a socketed ROM IC with the *machine's* MAC address on the motherboard, way back when. If your motherboard needed replacing, the tech would move that IC to the replacement. Why was this done? The reason was simple: compatibility with other stacks. Remember that circa 1988-1990, it was not obvious that TCP/IP was going to be the winner. --Steve Bellovin, http://www.cs.columbia.edu/~smb From Joel.Snyder at Opus1.COM Sun Apr 4 10:59:38 2010 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Sun, 04 Apr 2010 08:59:38 -0700 Subject: legacy /8 Message-ID: <4BB8B76A.8080404@opus1.com> Owen DeLong wrote: >It was based on 56kbit lines and the primary applications were >email, ftp, and telnet. (you have to have the right Yorkshire accent and Monty Python background for this...) 56kbit lines? If only we were so lucky... We had 9600 V.29 synchronous modems! Synchronous? My god, how pampered you were. We had V.32 dialup and those crazy Telebit modems. Got 19.2 once, in one direction, on a good day. 19.2 asymmetric? We dreamed of 19.2 asymmetric! We had 300 bps dialup using an acoustic coupler. Acoustic coupler? Luxury!!! We had to hum the modem tones ourselves into the phone line over a 2500 set with a frayed cord... (you can go on this way for a long time... We now return you to your regularly scheduled IPv3 NANOG troll...) jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From LarrySheldon at cox.net Sun Apr 4 11:02:42 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 04 Apr 2010 11:02:42 -0500 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> Message-ID: <4BB8B822.20705@cox.net> On 4/4/2010 09:57, Jorge Amodio wrote: >> UUCP is not a descriptor of any kind of a network in any engineering >> sense that I know of. It is a point-to-point communications protocol. > > You should revise some of the history behind it. It was a descriptor > for a very large network, it was even a TLD in the mid eighties when > the transition to DNS was taking place, the old bang style addresses > like mine original seismo!atina!pete transitioned for a while to > pete at atina.UUCP and later to pete at atina.ar. I agree with some of this and most of the following, but I think the problem is not so much my history as it is the drift in definitions. And I do not pretend to any special authority in the area. But when I think of "network" I think of things like the PSTN, ABC, Mutual, California's DOJ torn-tape TTY, and FIDO where the message to be delivered was the focus and the internal works were pretty much uninteresting to the "user". > UUCP was not just a point to point protocol. Originally it was a set > of utility programs to permit copying files between Unix systems (Unix > to Unix CoPy, hence the name), since electronic emails where > essentially files UUCP became the transport mechanism for both > electronic email and later Usenet News. CoPy is the only decode that ever occurs to me. And the file view of the world is correct and I had forgotten it. > > Some referred to UUCP as Unix to Unix Communications Protocol, not > quite right but yes one of the pieces of UUCP (uucico = Unix to Unix > Copy in Copy Out) implemented different type of communication > protocols negotiated during the initial handshake phase and fine > tuned to different communication facilities, point to point, telephone > modems, specific modems such as Telebit Trailblazers with PEP, > different types of encapsulation using X.28, X25, and obviously > TCP/IP. > > For several years until we've got a more decent telecommunications > infrastructure UUCP was all we had in Argentina to let the academic > and science community reach out and communicate with their colleagues > around the world, we had an adapted version of the UUCP implementation > for DOS (some called it UUPC) that became very popular and enabled our > "UUCP network" to reach over 800 nodes in the early 90's when we later > were able to get a direct (IP) connection to the rest of the world. > > My .02 Mine is that while "UUCP" took on a networkish patina in recent years (I know a place here in town that still uses it, or did when I last had contact with them a few years ago). But in it origins, UUCP was no more a network function that "cp" is today. (Hmmm....interesting digression. Was there NFS before there was IP? Seems like it, but I don't remember how it worked.) With UUCP you had to dial somebody up, say howdy (sometimes human to human) and issue the copy command. Sure enough, frequent users had cron jobs and scripts to do all that. And sure enough, co-operative sites would strip their own names off the beginning of a bang path and pass the file to the next in line, the next time they talked to them. Which might be anywhere from a few seconds to never from now. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Sun Apr 4 11:07:39 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 04 Apr 2010 11:07:39 -0500 Subject: Was a 1956 Video Phone User - "On the Internet" ? In-Reply-To: <4BB8A899.7090803@finchhaven.com> References: <4BB8A618.3060309@cox.net> <4BB8A899.7090803@finchhaven.com> Message-ID: <4BB8B94B.3060309@cox.net> On 4/4/2010 09:56, John Sage wrote: > The degree to which people subscribed to this list, apparently having > nothing better to do, will respond to a blatant troll is breathtaking. Mama taught me to be polite and forgiving, it takes me a while to give up on a persistent idiot--I want so badly to find a way to engage them. But I do learn eventually. > Of course recent evidence shows quite clearly that [some] people > subscribed to this list, apparently having nothing better to do, will > respond to anything... I am suitably chastened--kind of like being slapped with a stale bar-rag. MY apologies. but I did feel a need to respond to you. I'm over it now. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From zaid at zaidali.com Sun Apr 4 11:10:58 2010 From: zaid at zaidali.com (Zaid Ali) Date: Sun, 04 Apr 2010 09:10:58 -0700 Subject: legacy /8 In-Reply-To: <4BB897A7.60503@consolejunkie.net> Message-ID: On 4/4/10 6:44 AM, "Leen Besselink" wrote: > "Out of the total number of emails received, 14% were received over > IPv6, the rest over IPv4." It should be clear that 14% received here is email to RIPE NCC servers. I don't think we have 14% of SMTP traffic out there coming via IPv6. Actual SMTP traffic may still be under 1%, I have done some work with a colleague to sample 0.5M domains yielding in <2% AAAA MX records and we heard similar data with other folks that ran a similar experiment. Seeing an uptick on quad A MX record is still a good thing and tells us there is some form of migration but SMTP over IPv6 will be really valuable data here. Has anyone collected and published data on this? Zaid From LarrySheldon at cox.net Sun Apr 4 11:28:52 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 04 Apr 2010 11:28:52 -0500 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: <20100404153710.GA52140@reptiles.org> References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <20100404153710.GA52140@reptiles.org> Message-ID: <4BB8BE44.7050500@cox.net> On 4/4/2010 10:37, Jim Mercer wrote: > On Sun, Apr 04, 2010 at 09:57:12AM -0500, Jorge Amodio wrote: >> You should revise some of the history behind it. It was a descriptor >> for a very large network, it was even a TLD in the mid eighties when >> the transition to DNS was taking place, the old bang style addresses >> like mine original seismo!atina!pete transitioned for a while to >> pete at atina.UUCP and later to pete at atina.ar. > > i don't recall .uucp making it into the actual DNS, but i remember our mail > system used it as a trigger to do a uucp-maps lookup. I thought it was a sendmail hack, along with .bitnet and others. > i'm sure its an open debate as to if being in the UUCP maps also meant that > you were "on the Internet", but many people seemed or seem to think this way. My problem is that the UUCP maps (and the host-host communications) existed before, during and apart from anything properly labeled "The Internet". That the UUCP world developed links to "The Internet" (and FIDONet, and BITNET and ....) goes without saying. But landing you Piper Cherokee at LAX doesn't make you part of the Commercial Airline Industry. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From ras at e-gerbil.net Sun Apr 4 13:08:56 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sun, 4 Apr 2010 13:08:56 -0500 Subject: what about 48 bits? In-Reply-To: References: Message-ID: <20100404180856.GP75640@gerbil.cluepon.net> On Sun, Apr 04, 2010 at 11:53:54AM -0300, A.B. Jr. wrote: > Hi, > > Lots of traffic recently about 64 bits being too short or too long. > > What about mac addresses? Aren't they close to exhaustion? Should be. > Or it is assumed that mac addresses are being widely reused throughout > the world? All those low cost switches and wifi adapters DO use unique > mac addresses? http://en.wikipedia.org/wiki/MAC_address The IEEE expects the MAC-48 space to be exhausted no sooner than the year 2100[3]; EUI-64s are not expected to run out in the foreseeable future. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From dhc2 at dcrocker.net Sun Apr 4 13:11:59 2010 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Sun, 04 Apr 2010 11:11:59 -0700 Subject: Tidbits & the "NANOG Community" In-Reply-To: <244352414-1270388747-cardhu_decombobulator_blackberry.rim.net-1933095789-@bda294.bisx.prod.on.blackberry> References: <244352414-1270388747-cardhu_decombobulator_blackberry.rim.net-1933095789-@bda294.bisx.prod.on.blackberry> Message-ID: <4BB8D66F.4010506@dcrocker.net> On 4/4/2010 6:46 AM, Stefan Fouant wrote: > Sounds like this guy could benefit from some carpeting and a few Roombas in his Data Center ;) trolls rarely benefit from anything but being ignored. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From drc at virtualized.org Sun Apr 4 13:24:36 2010 From: drc at virtualized.org (David Conrad) Date: Sun, 4 Apr 2010 08:24:36 -1000 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> Message-ID: <19E7C0EA-03D9-43A4-9E65-57565F2144C2@virtualized.org> On Apr 3, 2010, at 10:46 PM, Michael Dillon wrote: > If "every significant router on the market" supported IPv6 five years ago,We need more of the spirit of the old days of networking when people building UUCP, and Fidonet and IP networks did less complaining about "vendors" and made things work as best they could. You're joking, right? You don't think that perhaps the fact that the Internet is seen as a critical piece of the telecommunications infrastructure on which national economies have become increasingly dependent and that people pay real money for and expect to operate 24x7x365 with full support might have something to do with why things are a bit different then when a tiny number of highly technical folks were playing around? > The fact is that lack of fastpath support doesn't matter until IPv6 > traffic levels get high enough to need the fastpath. Yeah, fortunately, the fact that your router is burning CPU doing IPv6 has no impact on stuff like BGP convergence. > Today we need to get more complete > IPv6 coverage. And if management and monitoring work fine on IPv4 and > networks are dual-stacked, why change? Because things break? > Do you have an actual example of a vendor, today, charging a higher license > fee for IPv6 support? Others have pointed this out. >> the *additional* cost and effort to the isp of fullly deploying >> dual-stack is still non-trivial. this is mightily off-pissing. > > Nobody promised you a free lunch. In any case, the investment required to > turn up IPv6 support is a lot less than the cost of carrier grade NAT. And > the running costs of IPv6 are also lower, Can you provide pointers to these analyses? Any evidence-backed data showing how CGN is more expensive would be very helpful. Regards, -drc From smb at cs.columbia.edu Sun Apr 4 13:36:49 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sun, 4 Apr 2010 14:36:49 -0400 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: <4BB8B822.20705@cox.net> References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <4BB8B822.20705@cox.net> Message-ID: <1B8F9D77-2C18-4DE3-A814-9A49600308F4@cs.columbia.edu> On Apr 4, 2010, at 12:02 42PM, Larry Sheldon wrote: > On 4/4/2010 09:57, Jorge Amodio wrote: >>> UUCP is not a descriptor of any kind of a network in any engineering >>> sense that I know of. It is a point-to-point communications protocol. >> >> You should revise some of the history behind it. It was a descriptor >> for a very large network, it was even a TLD in the mid eighties when >> the transition to DNS was taking place, the old bang style addresses >> like mine original seismo!atina!pete transitioned for a while to >> pete at atina.UUCP and later to pete at atina.ar. > > I agree with some of this and most of the following, but I think the > problem is not so much my history as it is the drift in definitions. > > And I do not pretend to any special authority in the area. > > But when I think of "network" I think of things like the PSTN, ABC, > Mutual, California's DOJ torn-tape TTY, and FIDO where the message to be > delivered was the focus and the internal works were pretty much > uninteresting to the "user". > >> UUCP was not just a point to point protocol. Originally it was a set >> of utility programs to permit copying files between Unix systems (Unix >> to Unix CoPy, hence the name), since electronic emails where >> essentially files UUCP became the transport mechanism for both >> electronic email and later Usenet News. > > CoPy is the only decode that ever occurs to me. And the file view of > the world is correct and I had forgotten it. >> >> Some referred to UUCP as Unix to Unix Communications Protocol, not >> quite right but yes one of the pieces of UUCP (uucico = Unix to Unix >> Copy in Copy Out) implemented different type of communication >> protocols negotiated during the initial handshake phase and fine >> tuned to different communication facilities, point to point, telephone >> modems, specific modems such as Telebit Trailblazers with PEP, >> different types of encapsulation using X.28, X25, and obviously >> TCP/IP. >> >> For several years until we've got a more decent telecommunications >> infrastructure UUCP was all we had in Argentina to let the academic >> and science community reach out and communicate with their colleagues >> around the world, we had an adapted version of the UUCP implementation >> for DOS (some called it UUPC) that became very popular and enabled our >> "UUCP network" to reach over 800 nodes in the early 90's when we later >> were able to get a direct (IP) connection to the rest of the world. >> >> My .02 > > Mine is that while "UUCP" took on a networkish patina in recent years (I > know a place here in town that still uses it, or did when I last had > contact with them a few years ago). > > But in it origins, UUCP was no more a network function that "cp" is > today. (Hmmm....interesting digression. Was there NFS before there was > IP? Seems like it, but I don't remember how it worked.) > > With UUCP you had to dial somebody up, say howdy (sometimes human to > human) and issue the copy command. Sure enough, frequent users had cron > jobs and scripts to do all that. And sure enough, co-operative sites > would strip their own names off the beginning of a bang path and pass > the file to the next in line, the next time they talked to them. Which > might be anywhere from a few seconds to never from now. There were two primary user-issued commands, uucp and uux (remote execution). You'd say something like uucp file... site!file uucp site!file... file uux site!command [site!file...] uux command site!file... The paths you could write to or retrieve from, as well as the list of commands that could be executed remotely, were set in a configuration file. The former was typically restricted much as anon-ftp is; the latter was typically rmail and -- after about 1982 -- rnews for Usenet. There was very little, if any, manual dialing; you typically either had an autodialer or you were polled by someone who did. Calling frequency and legal times of day for calling were also configurable, though polling -- and only polling -- was typically done via cron. The receiving site did not strip its name off the email path, the sending site did. That is, if I typed mail foo!bar!bletch!user my mailer would translate that to uux foo!rmail bar!bletch!user Site foo, in turn, would execute uux bar!rmail bletch!user etc. File transfer wasn't multihop, nor was remote execution per se. Usenet used a flooding algorithm with duplicate suppression. Uucp was designed for autodial modems, originally controlled by Bell autodialers; on PDP-11s, you needed a DN-11 to control the dialer. The dialer was hooked to a modem -- a real one, with no telephone or dial attached to it; the modem was also hooked to a serial path. Even very early on, though, uucp operated over higher-speed devices, such as the Bell Labs Datakit Virtual Circuit Switch and the ARPANET. Figuring the explicit mail routing path was annoying. I wrote (and Peter Honeyman rewrote) a command called pathalias; it took topology and cost data and generated the optimum path. Since cost had to reflect monetary cost, reliability, and policy -- not everyone would forward for everyone else -- people had to tweak the metric to get the effect they desired. (That, at least, should sound vaguely on-topic for NANOG...) But the visibility of the path was the only thing ordinary users had to worry about. --Steve Bellovin, http://www.cs.columbia.edu/~smb From lyndon at orthanc.ca Sun Apr 4 14:08:16 2010 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sun, 4 Apr 2010 13:08:16 -0600 (MDT) Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: <1B8F9D77-2C18-4DE3-A814-9A49600308F4@cs.columbia.edu> References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <4BB8B822.20705@cox.net> <1B8F9D77-2C18-4DE3-A814-9A49600308F4@cs.columbia.edu> Message-ID: > File transfer wasn't multihop It was, for at least some versions (V2 and later?), if the intermediate site(s) allowed execution of the uucp command. 25 years on the brain is fuzzy on the details ... --lyndon From smb at cs.columbia.edu Sun Apr 4 14:18:18 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sun, 4 Apr 2010 15:18:18 -0400 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <4BB8B822.20705@cox.net> <1B8F9D77-2C18-4DE3-A814-9A49600308F4@cs.columbia.edu> Message-ID: On Apr 4, 2010, at 3:08 16PM, Lyndon Nerenberg wrote: >> File transfer wasn't multihop > > It was, for at least some versions (V2 and later?), if the intermediate site(s) allowed execution of the uucp command. 25 years on the brain is fuzzy on the details ... You could certainly add uux and uux to the list of legal remote commands, but I confess that my memory is also dim about whether uucp file a!b!c would be translated automatically. It has indeed been a while... --Steve Bellovin, http://www.cs.columbia.edu/~smb From lyndon at orthanc.ca Sun Apr 4 14:24:53 2010 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sun, 4 Apr 2010 13:24:53 -0600 (MDT) Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <4BB8B822.20705@cox.net> <1B8F9D77-2C18-4DE3-A814-9A49600308F4@cs.columbia.edu> Message-ID: > You could certainly add uux and uux to the list of legal remote commands, but I confess that my memory is also dim about whether > > uucp file a!b!c > > would be translated automatically. It has indeed been a while... I'm pretty sure it was adding 'uucp' in the commands list that enabled the behaviour. HDB might have used a different config file syntax for turning this on. I would have to dig out the source code to remember the details. The command syntax you show above worked -- UUCP handled the re-queueing internally. --lyndon From msokolov at ivan.Harhan.ORG Sun Apr 4 14:33:38 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Sun, 4 Apr 2010 19:33:38 GMT Subject: Juniper's artificial feature blocking (was legacy /8) Message-ID: <1004041933.AA21122@ivan.Harhan.ORG> Tore Anderson wrote: > Juniper. If you want to run OSPFv3 on their layer 3 switches, you need > a quite expensive "advanced" licence. OSPFv2, on the other hand, is > included in the base licence. Really? My level of respect for Juniper has just dropped a few notches after reading this NANOG post - I didn't know that they were engaged in such DRM-like feature blocking practices. Where can I find more information about Juniper's stance on such practices (having some feature X present in both HW and SW, but artificially blocked until one buys an unlock key from them) and the exact degree to which they engage in such? The reason I ask is because I've been considering building my own PIM for their J-series, a PIM that would terminate Nokia/Covad's flavor of SDSL/2B1Q at the physical layer and present an ATM interface to JunOS, optionally supporting NxSDSL bonding with MLPPPoA. I have no love for routers that aren't 100% FOSS, but I couldn't find any other existing router platform which could be extended with 3rd-party physical interface modules, and designing and building my own base router chassis is not a viable option if I want to actually have something built before the Sun swells into a red giant and engulfs the Earth. So I thought that even though it isn't 100% FOSS, JunOS ought to be at least tolerable given that it appears to be based on FreeBSD and I've heard that it even allows the user to get direct access to the underlying Unix shell (does it really?) - but hearing about DRM-like artificial feature blocking seems to negate that. I mean, how could their disabled-until-you-pay blocking of "premium features" be effective if a user can get to the underlying Unix OS, shell, file system, processes, etc? Wouldn't such access allow smart users to unblock whatever feature is artificially blocked? Someone please educate me... MS From morrowc.lists at gmail.com Sun Apr 4 15:03:05 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 4 Apr 2010 16:03:05 -0400 Subject: legacy /8 In-Reply-To: <19E7C0EA-03D9-43A4-9E65-57565F2144C2@virtualized.org> References: <4BB65B39.8010902@mompl.net> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <19E7C0EA-03D9-43A4-9E65-57565F2144C2@virtualized.org> Message-ID: On Sun, Apr 4, 2010 at 2:24 PM, David Conrad wrote: > On Apr 3, 2010, at 10:46 PM, Michael Dillon wrote: >> The fact is that lack of fastpath support doesn't matter until IPv6 >> traffic levels get high enough to need the fastpath. > > Yeah, fortunately, the fact that your router is burning CPU doing IPv6 has no impact on stuff like BGP convergence. also, for the record, there are parts of this ipv6 internet thing where ... doing things in the slowpath is no longer feasible. From jmamodio at gmail.com Sun Apr 4 15:28:14 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 4 Apr 2010 15:28:14 -0500 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: <20100404153710.GA52140@reptiles.org> References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <20100404153710.GA52140@reptiles.org> Message-ID: > i don't recall .uucp making it into the actual DNS, but i remember our mail > system used it as a trigger to do a uucp-maps lookup. It was for a brief period of time as a pseudo-domain and placeholder for MX RRs for machines participating in the UUCP project. Mary Ann Horton (formerly Mark Horton) was in charge of the UUCP zone. http://tools.ietf.org/html/rfc976 > uucp introduced a far-flung group of hosts, academic and otherwise, to things > that were popular on the internet, namely email and USENET. Once upon a time there were not Internet and connection to ARPAnet was restricted, which triggered into existence CSNET, BITNET, etc, etc.) and for many, particularly developing countries or small institutions, could not afford to pay for a permanent connection sort of a DDS 56K. BTW in Argentina we didn't have even digital lines, just nasty copper between some places. > i'm sure its an open debate as to if being in the UUCP maps also meant that > you were "on the Internet", but many people seemed or seem to think this way. At some time there was some sort of confusion everywhere, and also turf battles between different "networks", CSNET vs BTINET, etc, but people one way or another got connected and that was the goal those days to get as many people as possible connected via some network and at minimum be able to have electronic email. There were some popular sites that ran services such as ftp via email, archie via email, etc. > i recall seeing uucp going into not only south america, but the caribbean, > south pacific and many other regions, much the same way that you describe it. Many of the developing countries did their first step that way. > there were several organizations who were quite dedicated to using uucp over > (dialup/X.25/carrier-pigeon) in order to extend email and USENET deep into > the third world. Yes we used what we had at hand, Rick Adams originally at SEISMO and later at UUNET, Randy Bush, the folks at Pyramid, and many others helped a lot to get people on board. Very interesting days :-), while visiting Glenn Ricart (SURAnet) at UMD I remember giving sort of a lecture about UUCP and the tricks we used to get connected to his undergrad students. Cheers Jorge From jmamodio at gmail.com Sun Apr 4 15:39:17 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 4 Apr 2010 15:39:17 -0500 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: <4BB8B822.20705@cox.net> References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <4BB8B822.20705@cox.net> Message-ID: > But when I think of "network" I think of things like the PSTN, ABC, > Mutual, California's DOJ torn-tape TTY, and FIDO where the message to be > delivered was the focus and the internal works were pretty much > uninteresting to the "user". Read "Notable Computer Networks, John Quarterman and Josiah Hoskins, CACM Vol 29, No 10, Oct 1986", UUCP was considered one of the "Cooperative Networks". >> UUCP was not just a point to point protocol. Originally it was a set >> of utility programs to permit copying files between Unix systems (Unix >> to Unix CoPy, hence the name), since electronic emails where >> essentially files UUCP became the transport mechanism for both >> electronic email and later Usenet News. > > CoPy is the only decode that ever occurs to me. ?And the file view of > the world is correct and I had forgotten it. Steven Bellovin can give you more details, there are several papers and he wrote one with Peter Honeyman who is the guy that rewrote the original version of the UUCP utilities developed by Mike Lesk at AT&T. > Mine is that while "UUCP" took on a networkish patina in recent years (I > know a place here in town that still uses it, or did when I last had > contact with them a few years ago). I know some that still use it. > With UUCP you had to dial somebody up, say howdy (sometimes human to > human) and issue the copy command. ?Sure enough, frequent users had cron > jobs and scripts to do all that. ?And sure enough, co-operative sites > would strip their own names off the beginning of a bang path and pass > the file to the next in line, the next time they talked to them. ?Which > might be anywhere from a few seconds to never from now. Read RFC976 for additional details. http://tools.ietf.org/html/rfc976 Cheers Jorge. From jmamodio at gmail.com Sun Apr 4 15:41:02 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 4 Apr 2010 15:41:02 -0500 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: <4BB8BE44.7050500@cox.net> References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <20100404153710.GA52140@reptiles.org> <4BB8BE44.7050500@cox.net> Message-ID: > That the UUCP world developed links to "The Internet" (and FIDONet, and > BITNET and ....) goes without saying. ?But landing you Piper Cherokee at > LAX doesn't make you part of the Commercial Airline Industry. That's how for some time the distinction between "internet" and "Internet" was born. Jorge From jaap at NLnetLabs.nl Sun Apr 4 15:43:23 2010 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Sun, 04 Apr 2010 22:43:23 +0200 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <4BB8B822.20705@cox.net> <1B8F9D77-2C18-4DE3-A814-9A49600308F4@cs.columbia.edu> Message-ID: <201004042043.o34KhN5W077445@bartok.nlnetlabs.nl> It was, for at least some versions (V2 and later?), if the intermediate site(s) allowed execution of the uucp command. 25 years on the brain is fuzzy on the details ... You could certainly add uux and uux to the list of legal remote commands, but I confess that my memory is also dim about whether uucp file a!b!c would be translated automatically. It has indeed been a while... Yup. The real work was done by uucico (using an x.21 type protocol implemented by Greg Chesson of EGREG fame if I remember correctly). UUCP and friends where front-ends for it and has been reimplemnted as the honeydanber version. Then there were the AT&T Basic Network Utilities version, Taylor uucp, the EUUG version etc. of these. jaap From matthew at matthew.at Sun Apr 4 15:51:27 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 04 Apr 2010 13:51:27 -0700 Subject: what about 48 bits? In-Reply-To: <20100404180856.GP75640@gerbil.cluepon.net> References: <20100404180856.GP75640@gerbil.cluepon.net> Message-ID: <4BB8FBCF.4020909@matthew.at> Richard A Steenbergen wrote: > On Sun, Apr 04, 2010 at 11:53:54AM -0300, A.B. Jr. wrote: > >> Hi, >> >> Lots of traffic recently about 64 bits being too short or too long. >> >> What about mac addresses? Aren't they close to exhaustion? Should be. >> Or it is assumed that mac addresses are being widely reused throughout >> the world? All those low cost switches and wifi adapters DO use unique >> mac addresses? >> > > http://en.wikipedia.org/wiki/MAC_address > > The IEEE expects the MAC-48 space to be exhausted no sooner than the > year 2100[3]; EUI-64s are not expected to run out in the foreseeable > future. > > And this is what happens when you can use 100% of the bits on "endpoint identity" and not waste huge sections of them on the decision bits for "routing topology". Of course it comes with a privacy problem if you want to use that endpoint identifier globally and not change it for every session (as some protocols that separate routable-address from endpoint-identity do) Matthew Kaufman From avg at kotovnik.com Sun Apr 4 16:04:39 2010 From: avg at kotovnik.com (Vadim Antonov) Date: Sun, 4 Apr 2010 14:04:39 -0700 (PDT) Subject: legacy /8 In-Reply-To: Message-ID: > Zaid > > P.s. Disclaimer: I have always been a network operator and never a dentist. I would have thought opposite. People who have been on this list longer would probably remember when I was playing in this sandbox. The real wisdom about networks is "never try to change everything and everywhere at once". You either do gradual migration, or you end up in a big pile of poo. Which what IPv6 transition situation is. --vadim From scott at doc.net.au Sun Apr 4 16:05:50 2010 From: scott at doc.net.au (Scott Howard) Date: Sun, 4 Apr 2010 14:05:50 -0700 Subject: what about 48 bits? In-Reply-To: <4BB8FBCF.4020909@matthew.at> References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> Message-ID: On Sun, Apr 4, 2010 at 1:51 PM, Matthew Kaufman wrote: > http://en.wikipedia.org/wiki/MAC_address >> >> The IEEE expects the MAC-48 space to be exhausted no sooner than the year >> 2100[3]; EUI-64s are not expected to run out in the foreseeable future. >> >> > > And this is what happens when you can use 100% of the bits on "endpoint > identity" and not waste huge sections of them on the decision bits for > "routing topology". > Having around 4 orders of magnitude more addresses probably doesn't hurt either... Although even MAC-48 addresses are "wasteful" in that only 1/4 of them are assignable to/by vendors, with the other 3/4 being assigned to multicast and local addresses (the MAC equivalent of RFC1918) Scott. From mysidia at gmail.com Sun Apr 4 16:07:17 2010 From: mysidia at gmail.com (James Hess) Date: Sun, 4 Apr 2010 16:07:17 -0500 Subject: Juniper's artificial feature blocking (was legacy /8) In-Reply-To: <1004041933.AA21122@ivan.Harhan.ORG> References: <1004041933.AA21122@ivan.Harhan.ORG> Message-ID: On Sun, Apr 4, 2010 at 2:33 PM, Michael Sokolov wrote: > feature blocking seems to negate that. ?I mean, how could their > disabled-until-you-pay blocking of "premium features" be effective if a > user can get to the underlying Unix OS, shell, file system, processes, Probably signed binaries, veriexec with a signature list of allowed executables, proprietary system daemons, hardware drivers, and read-only filesystems. Protections may be in hardware, and you do not have source code. You can in JunOS "start shell user root" as much as you like and get a root shell on various platforms, but some functions are limited. Using a 'key' is slightly less of a network operator nightmare than having 100 featuresets, and thousands of mystery meat images for the same software version. At least you don't need to go buy a new software image, and do a full upgrade procedure to gain feature access. Applying a key seems less risky and less likely that downtime is needed, when you decide that you now need this feature. > etc? ?Wouldn't such access allow smart users to unblock whatever feature [snip] Perhaps, but that would be tedious and probably waste a lot of user time, which can have higher cost than buying a key. The warranty might be voided, and the installation wouldn't be supported anymore, new bugs can be discovered. Upgrades can be required. Even CPU manufacturers are noted for artificially restricting features in software (such as VT or hyper-threading, even artificially disabling cores). Not all buyers of L3 switches need or want to pay for that, and there is more $$$ to be made from those that do. The manufacturer can either segment their market by not offering OSPFv3 on the device, release a new higher-end hardware model for V3 support at 10x the cost, or offer an add-on license, as an incremental upgrade to a larger number of users (including the installed base). -- -J From wavetossed at googlemail.com Sun Apr 4 16:14:23 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Sun, 4 Apr 2010 22:14:23 +0100 Subject: Was a 1956 Video Phone User - "On the Internet" ? In-Reply-To: References: Message-ID: > Was a 1956 Video Phone User - "On the Internet" ? > http://www.porticus.org/bell/telephones-picturephone.html Seems like ipvsomething.com is just another Internet entrepreneur who earns money from driving traffic to nonsense sites that host Google ads. He seems to think that the NANOG list is a good way to get such traffic both directly from curious NANOG members and indirectly from the URLs that get recorded in various NANOG email archives. Please don't copy his URLs if you reply to one of his messages. --Michael Dillon From williams.bruce at gmail.com Sun Apr 4 16:38:46 2010 From: williams.bruce at gmail.com (Bruce Williams) Date: Sun, 4 Apr 2010 14:38:46 -0700 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: <201004042043.o34KhN5W077445@bartok.nlnetlabs.nl> References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <4BB8B822.20705@cox.net> <1B8F9D77-2C18-4DE3-A814-9A49600308F4@cs.columbia.edu> <201004042043.o34KhN5W077445@bartok.nlnetlabs.nl> Message-ID: This is an example of the law that the number of replys is directly propotional to the cluelessness of the post? Bruce On Sun, Apr 4, 2010 at 1:43 PM, Jaap Akkerhuis wrote: > > > ? ?It was, for at least some versions (V2 and later?), if the > ? ?intermediate site(s) allowed execution of the uucp command. 25 > ? ?years on the brain is fuzzy on the details ... > > ? ?You could certainly add uux and uux to the list of legal remote > ? ?commands, but I confess that my memory is also dim about whether > > ? ? ? ?uucp file a!b!c > > ? ?would be translated automatically. ?It has indeed been a while... > > Yup. The real work was done by uucico (using an x.21 type protocol > implemented by Greg Chesson of EGREG fame if I remember correctly). > UUCP and friends where front-ends for it and has been reimplemnted > as the honeydanber version. Then there were the AT&T Basic Network > Utilities version, Taylor uucp, the EUUG version etc. of these. > > ? ? ? ?jaap > > -- - Bruce Williams From jimb at jsbc.cc Sun Apr 4 16:48:38 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Sun, 04 Apr 2010 14:48:38 -0700 Subject: what about 48 bits? In-Reply-To: <1270395578-sup-3974@sfo.thejof.com> References: <1A45C388-F50A-44E5-9A58-C20E72E5A495@cs.cmu.edu> <20100404111728.2b5c9ecf@milhouse.peachfamily.net> <1270395578-sup-3974@sfo.thejof.com> Message-ID: <4BB90936.7090607@jsbc.cc> On 4/4/2010 08:46, Jonathan Lassoff wrote: > Excerpts from John Peach's message of Sun Apr 04 08:17:28 -0700 2010: > >> On Sun, 4 Apr 2010 11:10:56 -0400 >> David Andersen wrote: >> >> >>> There are some classical cases of assigning the same MAC address to every machine in a batch, resetting the counter used to number them, etc.; unless shown otherwise, these are likely to be errors, not accidental collisions. >>> >>> -Dave >>> >>> On Apr 4, 2010, at 10:57 AM, jim deleskie wrote: >>> >>> >>>> I've seen duplicate addresses in the wild in the past, I assume there >>>> is some amount of reuse, even though they are suppose to be unique. >>>> >>>> -jim >>>> >>>> On Sun, Apr 4, 2010 at 11:53 AM, A.B. Jr. wrote: >>>> >>>>> Hi, >>>>> >>>>> Lots of traffic recently about 64 bits being too short or too long. >>>>> >>>>> What about mac addresses? Aren't they close to exhaustion? Should be. Or it >>>>> is assumed that mac addresses are being widely reused throughout the world? >>>>> All those low cost switches and wifi adapters DO use unique mac addresses? >>>>> >>>>> >> Sun, for one, used to assign the same MAC address to every NIC in the >> same box. >> > I could see how that *could* work as long as each interface connected to > a different LAN. > That was a logic Sun used. Every NIC would be connected to a different subnet, so duplicate MACs shouldn't be a problem. For the most part this worked, but some situations required a unique MAC per NIC, and Sun had a bit you could flip to turn this on. I believe it was an OpenBoot prom variable called "local-mac-address?" which you'd set to true if you wanted it to use each NICs MAC instead of the "system MAC". -Jim From zaid at zaidali.com Sun Apr 4 16:50:22 2010 From: zaid at zaidali.com (Zaid Ali) Date: Sun, 04 Apr 2010 14:50:22 -0700 Subject: legacy /8 In-Reply-To: Message-ID: On 4/4/10 2:04 PM, "Vadim Antonov" wrote: > >> Zaid >> >> P.s. Disclaimer: I have always been a network operator and never a dentist. > > I would have thought opposite. > It is sometimes helpful to draw lessons from nature and other systems :) > People who have been on this list longer would probably remember when I > was playing in this sandbox. > > The real wisdom about networks is "never try to change everything and > everywhere at once". You either do gradual migration, or you end up in a > big pile of poo. Which what IPv6 transition situation is. > > --vadim > I too apply the same "real wisdom" and view IPv6 transition as a gradual migration and we are seeing a lot of success already with this approach, its just that the adoption numbers are slower than we would like. I get a sense that our 5+ year IPv6 discussions have people worried and panicked that the best thing is to leave things as they are which makes me think we should perhaps spend less time on the advocacy part of IPv6 solution and put our efforts on what we get out of implementation. Zaid From john-nanog at johnpeach.com Sun Apr 4 16:56:07 2010 From: john-nanog at johnpeach.com (John Peach) Date: Sun, 04 Apr 2010 17:56:07 -0400 Subject: what about 48 bits? In-Reply-To: <4BB90936.7090607@jsbc.cc> References: <1A45C388-F50A-44E5-9A58-C20E72E5A495@cs.cmu.edu> <20100404111728.2b5c9ecf@milhouse.peachfamily.net> <1270395578-sup-3974@sfo.thejof.com> <4BB90936.7090607@jsbc.cc> Message-ID: <20100404175607.66c94bc1@milhouse.peachfamily.net> On Sun, 04 Apr 2010 14:48:38 -0700 Jim Burwell wrote: > On 4/4/2010 08:46, Jonathan Lassoff wrote: > > Excerpts from John Peach's message of Sun Apr 04 08:17:28 -0700 2010: > > > >> On Sun, 4 Apr 2010 11:10:56 -0400 > >> David Andersen wrote: > >> > >> > >>> There are some classical cases of assigning the same MAC address to every machine in a batch, resetting the counter used to number them, etc.; unless shown otherwise, these are likely to be errors, not accidental collisions. > >>> > >>> -Dave > >>> > >>> On Apr 4, 2010, at 10:57 AM, jim deleskie wrote: > >>> > >>> > >>>> I've seen duplicate addresses in the wild in the past, I assume there > >>>> is some amount of reuse, even though they are suppose to be unique. > >>>> > >>>> -jim > >>>> > >>>> On Sun, Apr 4, 2010 at 11:53 AM, A.B. Jr. wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> Lots of traffic recently about 64 bits being too short or too long. > >>>>> > >>>>> What about mac addresses? Aren't they close to exhaustion? Should be. Or it > >>>>> is assumed that mac addresses are being widely reused throughout the world? > >>>>> All those low cost switches and wifi adapters DO use unique mac addresses? > >>>>> > >>>>> > >> Sun, for one, used to assign the same MAC address to every NIC in the > >> same box. > >> > > I could see how that *could* work as long as each interface connected to > > a different LAN. > > > That was a logic Sun used. Every NIC would be connected to a different > subnet, so duplicate MACs shouldn't be a problem. For the most part > this worked, but some situations required a unique MAC per NIC, and Sun > had a bit you could flip to turn this on. I believe it was an OpenBoot > prom variable called "local-mac-address?" which you'd set to true if you > wanted it to use each NICs MAC instead of the "system MAC". You can set the MAC address to whatever you want in Solaris, using ifconfig and local-mac-address was (is) the PROM variable. -- John From jimb at jsbc.cc Sun Apr 4 16:56:41 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Sun, 04 Apr 2010 14:56:41 -0700 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <4BB8B822.20705@cox.net> <1B8F9D77-2C18-4DE3-A814-9A49600308F4@cs.columbia.edu> Message-ID: <4BB90B19.7060305@jsbc.cc> On 4/4/2010 12:18, Steven Bellovin wrote: > On Apr 4, 2010, at 3:08 16PM, Lyndon Nerenberg wrote: > > >>> File transfer wasn't multihop >>> >> It was, for at least some versions (V2 and later?), if the intermediate site(s) allowed execution of the uucp command. 25 years on the brain is fuzzy on the details ... >> > > You could certainly add uux and uux to the list of legal remote commands, but I confess that my memory is also dim about whether > > uucp file a!b!c > > would be translated automatically. It has indeed been a while... > Heh this brings back some memories. uucp/uux for email and news. I remember writing shells scripts that would pull the UUCP maps out of the UseNet newsgroup (comp.mail.maps IIRC) and run "pathalias" on it to generate email bang path routes to all other mapped UUCP sites from yours so that you could use domain-style email addresses instead of remembering the paths! So then you could address an email to "user at uucpsite.uucp" and Sendmail or Smail (I ran Smail) would look it up in the pathalias generated databse and convert it to a bang path. :) I also remember a few key "dual-connected" sites which were both on the UUCP network and the internet were used as gateways into the internet/DNS/SMTP email world. Specifically I remember "psuvax" being a widely used, and abused site for this, which eventually shut down that service because too many people were using them as a UUCP/internet gateway for email, sucking up all their cycles and bandwidth! -Jim From mysidia at gmail.com Sun Apr 4 17:34:33 2010 From: mysidia at gmail.com (James Hess) Date: Sun, 4 Apr 2010 17:34:33 -0500 Subject: what about 48 bits? In-Reply-To: References: Message-ID: On Sun, Apr 4, 2010 at 9:53 AM, A.B. Jr. wrote: > Lots of traffic recently about 64 bits being too short or too long. > What about mac addresses? Aren't they close to exhaustion? Should be. Or it > is assumed that mac addresses are being widely reused throughout the world? > All those low cost switches and wifi adapters DO use unique mac addresses? Hardware MAC-48 addresses are not assigned based on a network topology. The first 24 bits are used for OUI which is an ID number applied for [and paid for] by a manufacturer of network devices, the 2nd LSB of the most significant byte is reserved for 'local vs universal administration flag', and the LSB of the most significant byte is reserved for unicast/multicast flag. The bottom 24 bits are assigned by manufacturer. So there are 22 bits of usable global unicast OUIs, that is 4,194,304 possible. and each OUI has 16,777,216 MAC address numbers. Of the possible OUIs, only 13,557 are currently listed as allocated in the IEEE OUI listing. http://standards.ieee.org/regauth/oui/index.shtml So a theoretical maximum of 227,448,717,312 unicast MAC addresses could be globally assigned today (which is a vast overestimate, assuming all presently assigned OUIs are already completely exhausted). Out of 70,368,744,177,664, that is what, 0.3% ? -- -J From randy at psg.com Sun Apr 4 17:42:23 2010 From: randy at psg.com (Randy Bush) Date: Mon, 05 Apr 2010 07:42:23 +0900 Subject: legacy /8 In-Reply-To: <4BB8947E.3080502@redpill-linpro.com> References: <4BB65B39.8010902@mompl.net> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <4BB8947E.3080502@redpill-linpro.com> Message-ID: > Juniper. If you want to run OSPFv3 on their layer 3 switches, you need > a quite expensive "advanced" licence. OSPFv2, on the other hand, is > included in the base licence. yep maybe try is-is randy From randy at psg.com Sun Apr 4 17:50:08 2010 From: randy at psg.com (Randy Bush) Date: Mon, 05 Apr 2010 07:50:08 +0900 Subject: legacy /8 In-Reply-To: <19E7C0EA-03D9-43A4-9E65-57565F2144C2@virtualized.org> References: <4BB65B39.8010902@mompl.net> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <19E7C0EA-03D9-43A4-9E65-57565F2144C2@virtualized.org> Message-ID: >> The fact is that lack of fastpath support doesn't matter until IPv6 >> traffic levels get high enough to need the fastpath. > Yeah, fortunately, the fact that your router is burning CPU doing IPv6 > has no impact on stuff like BGP convergence. and, after all, if ipv6 takes off, we plan to throw away our investment in current routers and buy new ones. gsrs and crss are cheap. i think this is a great thread. ten new entries in my .procmailrc. of course the person to whom you were responding was there looooong ago. randy From randy at psg.com Sun Apr 4 17:55:07 2010 From: randy at psg.com (Randy Bush) Date: Mon, 05 Apr 2010 07:55:07 +0900 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: <1B8F9D77-2C18-4DE3-A814-9A49600308F4@cs.columbia.edu> References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <4BB8B822.20705@cox.net> <1B8F9D77-2C18-4DE3-A814-9A49600308F4@cs.columbia.edu> Message-ID: > the visibility of the path was the only thing ordinary users had to > worry about. you forgot, "and thus sigs were born." they once served a purpose other than ego randy From randy at psg.com Sun Apr 4 17:58:11 2010 From: randy at psg.com (Randy Bush) Date: Mon, 05 Apr 2010 07:58:11 +0900 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <20100404153710.GA52140@reptiles.org> Message-ID: fwiw, i still run uucp for a very few remaining odd sites. randy From smb at cs.columbia.edu Sun Apr 4 18:01:30 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sun, 4 Apr 2010 19:01:30 -0400 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <4BB8B822.20705@cox.net> <1B8F9D77-2C18-4DE3-A814-9A49600308F4@cs.columbia.edu> Message-ID: <3826D079-B076-439C-8A9C-5494DF9DF30F@cs.columbia.edu> On Apr 4, 2010, at 6:55 07PM, Randy Bush wrote: >> the visibility of the path was the only thing ordinary users had to >> worry about. > > you forgot, "and thus sigs were born." they once served a purpose other > than ego Right, of course -- they had to show the uucp path from a well-known node. --Steve Bellovin, http://www.cs.columbia.edu/~smb From Valdis.Kletnieks at vt.edu Sun Apr 4 18:22:45 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 04 Apr 2010 19:22:45 -0400 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: Your message of "Sun, 04 Apr 2010 19:01:30 EDT." <3826D079-B076-439C-8A9C-5494DF9DF30F@cs.columbia.edu> References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <4BB8B822.20705@cox.net> <1B8F9D77-2C18-4DE3-A814-9A49600308F4@cs.columbia.edu> <3826D079-B076-439C-8A9C-5494DF9DF30F@cs.columbia.edu> Message-ID: <19546.1270423365@localhost> On Sun, 04 Apr 2010 19:01:30 EDT, Steven Bellovin said: > Right, of course -- they had to show the uucp path from a well-known node. I remember trying to debug a very messy mail routing problem some 25 years ago, which we finally traced back to the fact that pathalias was too smart by half, and some sites were too helpful. My user was trying to send mail to a path 'fluffybunny!whiterabbit!jellybean' or some such - but when the mail left Bitnet via a different gateway than it was expected, the gateway chose the closest fluffybunny to send it to - and when *that* machine forwarded to whiterabbit, and whiterabbit couldn't find jellybean in its UUCP tables, we were most mystified that the bounce messages came back with European timestamps for a box supposedly in the midwest US. There was much kicking of metal trash cans when I finally figured out what happened. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From joelja at bogus.com Sun Apr 4 18:32:21 2010 From: joelja at bogus.com (joel jaeggli) Date: Sun, 04 Apr 2010 19:32:21 -0400 Subject: legacy /8 Message-ID: Last time I checked, some of the state of the art 2004 era silicon I had laying around could forward v6 just fine in hardware. It's not so usefyl due to it's fib being a bit undersized for 330k routes plus v6, but hey, six years is long time. Christopher Morrow wrote: >On Sun, Apr 4, 2010 at 2:24 PM, David Conrad wrote: >> On Apr 3, 2010, at 10:46 PM, Michael Dillon wrote: > >>> The fact is that lack of fastpath support doesn't matter until IPv6 >>> traffic levels get high enough to need the fastpath. >> >> Yeah, fortunately, the fact that your router is burning CPU doing IPv6 has no impact on stuff like BGP convergence. > >also, for the record, there are parts of this ipv6 internet thing >where ... doing things in the slowpath is no longer feasible. > From morrowc.lists at gmail.com Sun Apr 4 19:10:49 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 4 Apr 2010 17:10:49 -0700 Subject: legacy /8 In-Reply-To: References: Message-ID: On Sun, Apr 4, 2010 at 4:32 PM, joel jaeggli wrote: > Last time I checked, some of the state of the art 2004 era silicon I had laying around could forward v6 just fine in hardware. ?It's not so usefyl due to it's fib being a bit undersized for 330k routes plus v6, but hey, six years is long time. 4948 (not 6yrs old, but... still forwards v6 in the slow-path, weee!) > Christopher Morrow wrote: > >>On Sun, Apr 4, 2010 at 2:24 PM, David Conrad wrote: >>> On Apr 3, 2010, at 10:46 PM, Michael Dillon wrote: >> >>>> The fact is that lack of fastpath support doesn't matter until IPv6 >>>> traffic levels get high enough to need the fastpath. >>> >>> Yeah, fortunately, the fact that your router is burning CPU doing IPv6 has no impact on stuff like BGP convergence. >> >>also, for the record, there are parts of this ipv6 internet thing >>where ... doing things in the slowpath is no longer feasible. >> > From bzs at world.std.com Sun Apr 4 19:20:29 2010 From: bzs at world.std.com (Barry Shein) Date: Sun, 4 Apr 2010 20:20:29 -0400 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <20100404153710.GA52140@reptiles.org> Message-ID: <19385.11469.542125.882532@world.std.com> I remember around 1987 when Helsinki (Univ I believe) hooked up Talinn, Estonia via uucp (including usenet), who then hooked up MSU (Moscow State Univ) and the traffic began flowing. You could just about see the wide-eyed disbelief by some as they saw for example alt.politics, you people just say almost *anything!*, with your real name and location attached, and NOTHING HAPPENS??? I still believe that had as much to do with the collapse of the Soviet Union as the million other politicians who wish to take credit. It's arguable that UUCP (and Usenet, email, etc that it carried) was one of the most powerful forces for change in modern history. All you needed was some freely available software, a very modest computer, a modem, a phone line, and like so many things in life, a friend. And then once you "got it", you looked towards connecting to the "real" internet, you knew just what you were after. -- -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 jmamodio at gmail.com Sun Apr 4 19:38:37 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 4 Apr 2010 19:38:37 -0500 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: <19385.11469.542125.882532@world.std.com> References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <20100404153710.GA52140@reptiles.org> <19385.11469.542125.882532@world.std.com> Message-ID: > I remember around 1987 when Helsinki (Univ I believe) hooked up > Talinn, Estonia via uucp (including usenet), who then hooked up MSU > (Moscow State Univ) and the traffic began flowing. I bet that there many histories, perhaps those that didn't have access to modern communications and vast resources were able to appreciate much more what was possible to do with uucp. I can tell for sure that in one instance it saved the life of a little kid in the north of Argentina. This kid had some rare disease and the rural doctor that was attending him didn't know how to treat him, but he had a pc an a modem and he was one of the nodes using the dos uucp implementation and he sent us an email (in the postmaster role I always got requests as if I were the index or 411 service on the networking those days) asking how to get in contact with somebody to get help. We were able via PAHO (Panamerican Health Org) to find somebody that had a contact at WHO (World Health Org) which helped us to locate some doctor familiar with that disease. We finally got in touch via email with a Japanese doc who help the Argentinean doc treat the little kid and he survived. This was not the classic send me $1 for the sick kid scam, it was very real. Regards Jorge From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Apr 4 20:10:57 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 5 Apr 2010 10:40:57 +0930 Subject: what about 48 bits? In-Reply-To: <20100404111728.2b5c9ecf@milhouse.peachfamily.net> References: <1A45C388-F50A-44E5-9A58-C20E72E5A495@cs.cmu.edu> <20100404111728.2b5c9ecf@milhouse.peachfamily.net> Message-ID: <20100405104057.28502441@opy.nosense.org> On Sun, 04 Apr 2010 11:17:28 -0400 John Peach wrote: > On Sun, 4 Apr 2010 11:10:56 -0400 > David Andersen wrote: > > > There are some classical cases of assigning the same MAC address to every machine in a batch, resetting the counter used to number them, etc.; unless shown otherwise, these are likely to be errors, not accidental collisions. > > > > -Dave > > > > On Apr 4, 2010, at 10:57 AM, jim deleskie wrote: > > > > > I've seen duplicate addresses in the wild in the past, I assume there > > > is some amount of reuse, even though they are suppose to be unique. > > > > > > -jim > > > > > > On Sun, Apr 4, 2010 at 11:53 AM, A.B. Jr. wrote: > > >> Hi, > > >> > > >> Lots of traffic recently about 64 bits being too short or too long. > > >> > > >> What about mac addresses? Aren't they close to exhaustion? Should be. Or it > > >> is assumed that mac addresses are being widely reused throughout the world? > > >> All those low cost switches and wifi adapters DO use unique mac addresses? > > >> > Sun, for one, used to assign the same MAC address to every NIC in the > same box. > That actually follows the original MAC addressing model - "48-bit Absolute Internet and Ethernet Host Numbers" http://ethernethistory.typepad.com/papers/HostNumbers.pdf As add-in cards needed their own address, because they couldn't be sure the host had one, and most likely didn't, I think that has evolved into unique MAC addresses per-interface rather than per-host. Regards, Mark. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Apr 4 20:27:46 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 5 Apr 2010 10:57:46 +0930 Subject: what about 48 bits? In-Reply-To: References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> Message-ID: <20100405105746.750257bf@opy.nosense.org> On Sun, 4 Apr 2010 14:05:50 -0700 Scott Howard wrote: > On Sun, Apr 4, 2010 at 1:51 PM, Matthew Kaufman wrote: > > > http://en.wikipedia.org/wiki/MAC_address > >> > >> The IEEE expects the MAC-48 space to be exhausted no sooner than the year > >> 2100[3]; EUI-64s are not expected to run out in the foreseeable future. > >> > >> > > > > And this is what happens when you can use 100% of the bits on "endpoint > > identity" and not waste huge sections of them on the decision bits for > > "routing topology". > > > > Having around 4 orders of magnitude more addresses probably doesn't hurt > either... > > Although even MAC-48 addresses are "wasteful" in that only 1/4 of them are > assignable to/by vendors, with the other 3/4 being assigned to multicast and > local addresses (the MAC equivalent of RFC1918) > Has anybody considered lobbying the IEEE to do a point to point version of Ethernet to gets rid of addressing fields? Assuming an average 1024 byte packet size, on a 10Gbps link they're wasting 100+ Mbps. 100GE / 1TE starts to make it even more worth doing. Actually the minimum 64 byte packet size could probably go too, as that was only there for collision detection. > Scott. From msokolov at ivan.Harhan.ORG Sun Apr 4 20:57:41 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Mon, 5 Apr 2010 01:57:41 GMT Subject: what about 48 bits? Message-ID: <1004050157.AA21864@ivan.Harhan.ORG> Mark Smith wrote: > Has anybody considered lobbying the IEEE to do a point to point version > of Ethernet to gets rid of addressing fields? [...] > Actually the minimum 64 byte packet size could probably go too, as that > was only there for collision detection. And maybe rename it to something else while you are at it? All those people who have hijacked the name "Ethernet" for PtP links (all those "Ethernet" UTP media are really PtP at the physical level, unlike real coaxial Ethernet) are despicable thieves - now those of us who are still using the original coaxial Ethernet in the shared bus mode are left without a clear, unique and distinctive name we once had to refer to what we use. MS From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Apr 4 21:16:37 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 5 Apr 2010 11:46:37 +0930 Subject: what about 48 bits? In-Reply-To: <1004050157.AA21864@ivan.Harhan.ORG> References: <1004050157.AA21864@ivan.Harhan.ORG> Message-ID: <20100405114637.30031fc4@opy.nosense.org> On Mon, 5 Apr 2010 01:57:41 GMT msokolov at ivan.Harhan.ORG (Michael Sokolov) wrote: > Mark Smith wrote: > > > Has anybody considered lobbying the IEEE to do a point to point version > > of Ethernet to gets rid of addressing fields? [...] > > Actually the minimum 64 byte packet size could probably go too, as that > > was only there for collision detection. > > And maybe rename it to something else while you are at it? All those > people who have hijacked the name "Ethernet" for PtP links (all those > "Ethernet" UTP media are really PtP at the physical level, unlike real > coaxial Ethernet) are despicable thieves - now those of us who are still > using the original coaxial Ethernet in the shared bus mode are left > without a clear, unique and distinctive name we once had to refer to > what we use. > Actually the IEEE have never called it "Ethernet", it's all been IEEE 802.3 / XXX{BASE|BROAD}-BLAH. "Ethernet", assuming version 1 and 2, strictly means thick coax, vampire taps and AUI connectors running at (half-duplex) 10Mbps. I saw some of it once. Regards, Mark. From jimb at jsbc.cc Sun Apr 4 21:22:36 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Sun, 04 Apr 2010 19:22:36 -0700 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: <19385.11469.542125.882532@world.std.com> References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <20100404153710.GA52140@reptiles.org> <19385.11469.542125.882532@world.std.com> Message-ID: <4BB9496C.6090809@jsbc.cc> On 4/4/2010 17:20, Barry Shein wrote: > I still believe that had as much to do with the collapse of the Soviet > Union as the million other politicians who wish to take credit. > > It's arguable that UUCP (and Usenet, email, etc that it carried) was > one of the most powerful forces for change in modern history. All you > needed was some freely available software, a very modest computer, a > modem, a phone line, and like so many things in life, a friend. > > And then once you "got it", you looked towards connecting to the > "real" internet, you knew just what you were after. > > I agree. I remember back in the 80s when I first got access to UseNet and UUCP based email thinking and saying things like "the net will change the world", because for the first time people from all over the globe were communicating fairly openly and inexpensively, and somehow the internet and UUCP seemed to come in "under the radar" back then. I had more than a few people scoff at me for thinking that way though. :-) From jmamodio at gmail.com Sun Apr 4 21:35:55 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 4 Apr 2010 21:35:55 -0500 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: <4BB9496C.6090809@jsbc.cc> References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <20100404153710.GA52140@reptiles.org> <19385.11469.542125.882532@world.std.com> <4BB9496C.6090809@jsbc.cc> Message-ID: > I agree. ?I remember back in the 80s when I first got access to UseNet > and UUCP based email thinking and saying things like "the net will > change the world", because for the first time people from all over the > globe were communicating fairly openly and inexpensively, and somehow > the internet and UUCP seemed to come in "under the radar" back then. ?I > had more than a few people scoff at me for thinking that way though. ?:-) Long hours and black magic, but true. I totally agree it was one of the factors that changed in the world. On a personal note it certainly changed my life. While my job had to do with information technology and telecommunications the Internet mambo jambo was just a side effect that ended being the enabling factor to permit and entire national community become part of global community and the inflection point to break the monopoly of international communications in several countries. No doubt that sooner or later it was going to happen with or without me, I just happened to be at the right space-time and surrounded with good friends and colleagues that thought it was a noble cause to go the extra mile and extra hours and we all tried to work in a cooperative fashion, something that over the past few years I feel has been lost. Cheers Jorge From joelja at bogus.com Sun Apr 4 21:41:57 2010 From: joelja at bogus.com (joel jaeggli) Date: Sun, 04 Apr 2010 19:41:57 -0700 Subject: legacy /8 In-Reply-To: References: Message-ID: <4BB94DF5.8080406@bogus.com> On 4/4/2010 5:10 PM, Christopher Morrow wrote: > On Sun, Apr 4, 2010 at 4:32 PM, joel jaeggli wrote: > >> Last time I checked, some of the state of the art 2004 era silicon I had laying around could forward v6 just fine in hardware. It's not so usefyl due to it's fib being a bit undersized for 330k routes plus v6, but hey, six years is long time. >> > 4948 (not 6yrs old, but... still forwards v6 in the > slow-path, weee!) > Yes it does. and the slow path is sloooooooooow on the that switch. but switches and routers did and do come in colors other than blue. :/ From robert at timetraveller.org Sun Apr 4 21:45:53 2010 From: robert at timetraveller.org (Robert Brockway) Date: Sun, 4 Apr 2010 22:45:53 -0400 (EDT) Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: <4BB9496C.6090809@jsbc.cc> References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <20100404153710.GA52140@reptiles.org> <19385.11469.542125.882532@world.std.com> <4BB9496C.6090809@jsbc.cc> Message-ID: On Sun, 4 Apr 2010, Jim Burwell wrote: > I agree. I remember back in the 80s when I first got access to UseNet > and UUCP based email thinking and saying things like "the net will > change the world", because for the first time people from all over the > globe were communicating fairly openly and inexpensively, and somehow > the internet and UUCP seemed to come in "under the radar" back then. I > had more than a few people scoff at me for thinking that way though. :-) I know exactly what you mean. I first connected got online in 1992 (late by the standards of some around here :) ). Right away I knew it was going to change everything. I tried to explain this to people but mostly got a blank stare in return. These days you hear people occassionally say that no one predicted the explosive impact of the Internet. I did, and so did a lot of others. I will say that I expected it was going to take us longer to get to this point (near ubiquitous network access in the developed world, and network technologies being widely adopted by government & business to deliver services). In any case, we're at the beginning of this revolution, not the end. I expect it will take several centuries for the full impact of the information revolution to become evident. Cheers, Rob -- Email: robert at timetraveller.org IRC: Solver Web: http://www.practicalsysadmin.com Open Source: The revolution that silently changed the world From morrowc.lists at gmail.com Sun Apr 4 21:48:48 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 4 Apr 2010 19:48:48 -0700 Subject: legacy /8 In-Reply-To: <4BB94DF5.8080406@bogus.com> References: <4BB94DF5.8080406@bogus.com> Message-ID: On Sun, Apr 4, 2010 at 7:41 PM, joel jaeggli wrote: > On 4/4/2010 5:10 PM, Christopher Morrow wrote: >> >> On Sun, Apr 4, 2010 at 4:32 PM, joel jaeggli ?wrote: >> >>> >>> Last time I checked, some of the state of the art 2004 era silicon I had >>> laying around could forward v6 just fine in hardware. ?It's not so usefyl >>> due to it's fib being a bit undersized for 330k routes plus v6, but hey, six >>> years is long time. >>> >> >> 4948 ?(not 6yrs old, but... still forwards v6 in the >> slow-path, weee!) >> > > Yes it does. and the slow path is sloooooooooow on the that switch. but > switches and routers did and do come in colors other than blue. but, but, but.. then it won't match! and seriously, I can't have another run in with the fashion police. In actual seriousness, my point is that plenty of this sort of gear is in the network, and will be for a time. It's sort of inexcusable that vendors put out gear 5 years ago that didn't do v6 in the fast path... oh well. -chris From ras at e-gerbil.net Sun Apr 4 21:57:42 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sun, 4 Apr 2010 21:57:42 -0500 Subject: what about 48 bits? In-Reply-To: <20100405105746.750257bf@opy.nosense.org> References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> <20100405105746.750257bf@opy.nosense.org> Message-ID: <20100405025742.GR75640@gerbil.cluepon.net> On Mon, Apr 05, 2010 at 10:57:46AM +0930, Mark Smith wrote: > > Has anybody considered lobbying the IEEE to do a point to point version > of Ethernet to gets rid of addressing fields? Assuming an average 1024 > byte packet size, on a 10Gbps link they're wasting 100+ Mbps. 100GE / > 1TE starts to make it even more worth doing. If you're lobbying to have the IEEE do something intelligent to Ethernet why don't you start with a freaking standardization of jumbo frames. The lack of a real standard and any type of negotiation protocol for two devices under different administrative control are all but guaranteeing end to end jumbo frame support will never be practical. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From joelja at bogus.com Sun Apr 4 22:01:36 2010 From: joelja at bogus.com (joel jaeggli) Date: Sun, 04 Apr 2010 20:01:36 -0700 Subject: legacy /8 In-Reply-To: <20100404104500.1c7b6d49@opy.nosense.org> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> <4BB780AB.6060006@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C73@RWC-EX1.corp.seven.com> <20100404104500.1c7b6d49@opy.nosense.org> Message-ID: <4BB95290.9030400@bogus.com> On 4/3/2010 6:15 PM, Mark Smith wrote: > Ever used IPX or Appletalk? If you haven't, then you don't know how > simple and capable networking can be. And those protocols were designed > more than 20 years ago, yet they're still more capable than IPv4. Zing, and there you have it! The hourglass is thin in the middle. One of if not the defining propteries of the ip protocol is what it doesn't do, which is virtually everything. From jimb at jsbc.cc Sun Apr 4 22:08:02 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Sun, 04 Apr 2010 20:08:02 -0700 Subject: what about 48 bits? In-Reply-To: <20100405114637.30031fc4@opy.nosense.org> References: <1004050157.AA21864@ivan.Harhan.ORG> <20100405114637.30031fc4@opy.nosense.org> Message-ID: <4BB95412.6090900@jsbc.cc> On 4/4/2010 19:16, Mark Smith wrote: <-snip-> > Actually the IEEE have never called it "Ethernet", it's all been IEEE > 802.3 / XXX{BASE|BROAD}-BLAH. > > "Ethernet", assuming version 1 and 2, strictly means thick coax, vampire > taps and AUI connectors running at (half-duplex) 10Mbps. I saw some of > it once. > I worked with it at my first job at a large government institution. Talk about painful and unweildy. We had parts of our network wired with 10base5 (thick ethernet) with vampire taps, and had some segments wired with transceivers which had a pair of threaded "type N connectors" (not sure if this is the proper name ... it's what my boss called them ... looked like oversized CATV F connectors). The xceiver boxes were pretty big (4-5 inches wide) and connected to the node via an AUI drop cable. The N connectors were easier to deal with than the vampire taps. To add a node, you just "spliced" a new xceiver box onto the line where you needed it by screwing a new length of cable into the new + existng xceivers, then connecting the AUI drop cable from the box to the node. Eventually we went to 10base2 (thin ethernet) and then like everyone else, 10baseT hubs. From LarrySheldon at cox.net Sun Apr 4 22:14:24 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 04 Apr 2010 22:14:24 -0500 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: <4BB89C0D.2000007@cox.net> References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> Message-ID: <4BB95590.40301@cox.net> On 4/4/2010 09:02, Larry Sheldon wrote: This attribution line is wrong--I meant to leave only the two line below it--for my purposes it did matter who said it. > On 4/3/2010 21:36, Joe Greco wrote: The line above should have been edited out leaving only these two. >>> What if TCP is removed ? and IP is completely re-worked in the same >>> 160-bit foot-print as IPv4 ? Would 64-bit Addressing last a few years ? > > I must have dozed off--what is the connection between the Subject: and > the recent traffic under it? [snip] My apologies to Mr. Greco -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From jmamodio at gmail.com Sun Apr 4 22:29:47 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 4 Apr 2010 22:29:47 -0500 Subject: what about 48 bits? In-Reply-To: <4BB95412.6090900@jsbc.cc> References: <1004050157.AA21864@ivan.Harhan.ORG> <20100405114637.30031fc4@opy.nosense.org> <4BB95412.6090900@jsbc.cc> Message-ID: > The N connectors were easier to deal with than the vampire taps. ?To add > a node, you just "spliced" a new xceiver box onto the line where you > needed it by screwing a new length of cable into the new + existng > xceivers, then connecting the AUI drop cable from the box to the node. I've to say it, the AUI cables were an absolute pain in the ass to deal with. We had also a thick coax with the vampire taps and AUI fan outs from Excellan. Dealing with the coax was not that bad since we made an inverted U and had a coax run on each of the two vertical raisers this particular building had. The biggest challenge was to go from the raiser using the existing horizontal conduits that were not that big, and run the AUI from the XCVR to the fanout unit and then from that unit to each desk. Before going to 10BaseT we used pre-standard LattisNet from SynOptics, getting rid of the AUI was a relief. Cheers Jorge From smb at cs.columbia.edu Sun Apr 4 22:40:27 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sun, 4 Apr 2010 23:40:27 -0400 Subject: what about 48 bits? In-Reply-To: References: <1004050157.AA21864@ivan.Harhan.ORG> <20100405114637.30031fc4@opy.nosense.org> <4BB95412.6090900@jsbc.cc> Message-ID: <982DC5C2-63A9-464F-9CB4-BE532C7A1E21@cs.columbia.edu> On Apr 4, 2010, at 11:29 47PM, Jorge Amodio wrote: >> The N connectors were easier to deal with than the vampire taps. To add >> a node, you just "spliced" a new xceiver box onto the line where you >> needed it by screwing a new length of cable into the new + existng >> xceivers, then connecting the AUI drop cable from the box to the node. > > I've to say it, the AUI cables were an absolute pain in the ass to deal with. > > We had also a thick coax with the vampire taps and AUI fan outs from > Excellan. Dealing with the coax was not that bad since we made an > inverted U and had a coax run on each of the two vertical raisers this > particular building had. > > The biggest challenge was to go from the raiser using the existing > horizontal conduits that were not that big, and run the AUI from the > XCVR to the fanout unit and then from that unit to each desk. > > Before going to 10BaseT we used pre-standard LattisNet from SynOptics, > getting rid of the AUI was a relief. > Oh, the thick coax and the AUIs were lots of fun. The 15-ping cables from the hosts to the AUIs were always coming loose, and the slide locks didn't help much. The vampire taps tended to either not make good enough contact or to break the center conductor. The N-connectors were easier to handle -- but cutting the cable and crimping on a pair took down the whole network. And then there was the time an electrician accidentally cut the coax and decided to splice it with black electrical tape... --Steve Bellovin, http://www.cs.columbia.edu/~smb From jmamodio at gmail.com Sun Apr 4 22:53:38 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 4 Apr 2010 22:53:38 -0500 Subject: what about 48 bits? In-Reply-To: <982DC5C2-63A9-464F-9CB4-BE532C7A1E21@cs.columbia.edu> References: <1004050157.AA21864@ivan.Harhan.ORG> <20100405114637.30031fc4@opy.nosense.org> <4BB95412.6090900@jsbc.cc> <982DC5C2-63A9-464F-9CB4-BE532C7A1E21@cs.columbia.edu> Message-ID: > And then there was the time an electrician accidentally cut the coax and decided to splice it with black electrical tape... He, he, we had all sorts of issues, ethernet was not a very well known technology yet. We had a radio antenna on the roof and when the guys doing the install saw a coax they assumed it was their 75 ohm drop to the radio equipment, never took the time to look at the labels on the cable, what a mess. At the Argentinean Embassy in WDC they had a pet dog that had the bad habit to chew on the thin ethernet cables, we didn't have any TDR tools so we had to befriend the damn dog to be able to follow him to find where the heck the cable was exposed and chewed. No doubt technology has evolved, for some people sshing from an iPod touch may feel like "yaaa another app" for me it feels amazing !! Cheers Jorge From bross at pobox.com Sun Apr 4 23:02:05 2010 From: bross at pobox.com (Brandon Ross) Date: Mon, 5 Apr 2010 00:02:05 -0400 (EDT) Subject: interop show network (was: legacy /8) Message-ID: On Sun, 4 Apr 2010, Jeroen van Aart wrote: > Someone in another thread mentioned interop show network. Which made me > curious and I did a bit of searching. I found the following article from 2008 > about the interop show: http://www.networkworld.com/community/node/27583 > > The show could setup an IPv6 only network in order to showcase it? That'd > free up a /8. Seriously? You do realize that the InteropNet actually has to provide a real service to the exhibitors and attendees of the show, right? This year's network will support v6, but a v6-only network is just not a practical way to supply real network connectivity to customers, yet. -- Brandon Ross AIM: BrandonNRoss Director of Network Engineering ICQ: 2269442 Xiocom Wireless Skype: brandonross Yahoo: BrandonNRoss From joelja at bogus.com Sun Apr 4 23:05:27 2010 From: joelja at bogus.com (joel jaeggli) Date: Sun, 04 Apr 2010 21:05:27 -0700 Subject: what about 48 bits? In-Reply-To: <20100405025742.GR75640@gerbil.cluepon.net> References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> <20100405105746.750257bf@opy.nosense.org> <20100405025742.GR75640@gerbil.cluepon.net> Message-ID: <4BB96187.6040703@bogus.com> On 4/4/2010 7:57 PM, Richard A Steenbergen wrote: > On Mon, Apr 05, 2010 at 10:57:46AM +0930, Mark Smith wrote: >> >> Has anybody considered lobbying the IEEE to do a point to point version >> of Ethernet to gets rid of addressing fields? Assuming an average 1024 >> byte packet size, on a 10Gbps link they're wasting 100+ Mbps. 100GE / >> 1TE starts to make it even more worth doing. > > If you're lobbying to have the IEEE do something intelligent to Ethernet > why don't you start with a freaking standardization of jumbo frames. The > lack of a real standard and any type of negotiation protocol for two > devices under different administrative control are all but guaranteeing > end to end jumbo frame support will never be practical. Not that I disagree, given that we use them rather a lot but 7.2usec (at 10Gbe) is sort of a long time to wait before a store and forward arch switch gets down to the task of figuring out what to do with the packet. The problem gets worse if mtu sizes bigger than 9k ever become popular, kind of like being stuck behind an elephant while boarding an elevator. From skandor at gmail.com Sun Apr 4 23:17:19 2010 From: skandor at gmail.com (A.B. Jr.) Date: Mon, 5 Apr 2010 01:17:19 -0300 Subject: what about 48 bits? In-Reply-To: References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> Message-ID: 2010/4/4 Scott Howard > On Sun, Apr 4, 2010 at 1:51 PM, Matthew Kaufman > wrote: > > > http://en.wikipedia.org/wiki/MAC_address > >> > >> The IEEE expects the MAC-48 space to be exhausted no sooner than the > year > >> 2100[3]; EUI-64s are not expected to run out in the foreseeable future. > >> > >> > > > > And this is what happens when you can use 100% of the bits on "endpoint > > identity" and not waste huge sections of them on the decision bits for > > "routing topology". > > > > Having around 4 orders of magnitude more addresses probably doesn't hurt > either... > > Although even MAC-48 addresses are "wasteful" in that only 1/4 of them are > assignable to/by vendors, with the other 3/4 being assigned to multicast > and > local addresses (the MAC equivalent of RFC1918) > > Scott. > Wasteful in many ways. While most of end user devices work with temporarily assigned IP addresses, or even with RFC1918 behind a NAT, very humble ethernet devices come from factory with a PERMANENTE unique mac address. And one of those devices are thrown away ? let?s say a cell phone with wifi, or a cheap NIC PC card - the mac address is lost forever. Doesn?t this sound not reasonable? A.b. -- From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Apr 4 23:23:41 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 5 Apr 2010 13:53:41 +0930 Subject: legacy /8 In-Reply-To: <4BB95290.9030400@bogus.com> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> <4BB780AB.6060006@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C73@RWC-EX1.corp.seven.com> <20100404104500.1c7b6d49@opy.nosense.org> <4BB95290.9030400@bogus.com> Message-ID: <20100405135341.640f4f7c@opy.nosense.org> On Sun, 04 Apr 2010 20:01:36 -0700 joel jaeggli wrote: > On 4/3/2010 6:15 PM, Mark Smith wrote: > > Ever used IPX or Appletalk? If you haven't, then you don't know how > > simple and capable networking can be. And those protocols were designed > > more than 20 years ago, yet they're still more capable than IPv4. > > Zing, and there you have it! The hourglass is thin in the middle. One of > if not the defining propteries of the ip protocol is what it doesn't do, > which is virtually everything. Well since it has become the only layer 3 protocol, shouldn't it be good enough or made good enough to do everything that's been done in the past and proven useful? IPv4 didn't succeed because it was significantly better than IPX or Appletalk. IPX has 32 bit network numbers (and 48 bit node addresses), so as a protocol it could have scaled to the Internet's size better than IPv4 has. However, the network effect kicked in - the Internet talks IPv4, so that's what people started running. People eventually seem to be rational about efficiency and said, "we're always going to have to run IPv4 because we always want to be connected to the Internet, so lets try to stop running multiple protocols that are nearly functionally equivalent." So Novell ported their services operating over TCP/IP, and Apple did the same. The thing that IPX and Appletalk did better than IPv4 was make networking much more convenient to operate. That was lost when they were abandoned. IPv6 will (hopefully) help bring them back. Regards, Mark. From morrowc.lists at gmail.com Sun Apr 4 23:24:26 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 4 Apr 2010 21:24:26 -0700 Subject: interop show network (was: legacy /8) In-Reply-To: References: Message-ID: On Sun, Apr 4, 2010 at 9:02 PM, Brandon Ross wrote: > On Sun, 4 Apr 2010, Jeroen van Aart wrote: > >> Someone in another thread mentioned interop show network. Which made me >> curious and I did a bit of searching. I found the following article from >> 2008 about the interop show: >> http://www.networkworld.com/community/node/27583 >> >> The show could setup an IPv6 only network in order to showcase it? That'd >> free up a /8. > > Seriously? ?You do realize that the InteropNet actually has to provide a > real service to the exhibitors and attendees of the show, right? ?This > year's network will support v6, but a v6-only network is just not a > practical way to supply real network connectivity to customers, yet. also, see previous 12 episodes of this conversation.. 1 /8 == ~3months in ARIN allocation timeframes. There is no cure, pls to be rolling out IPv6 2 years ago. -chris From scott at doc.net.au Sun Apr 4 23:29:44 2010 From: scott at doc.net.au (Scott Howard) Date: Sun, 4 Apr 2010 21:29:44 -0700 Subject: what about 48 bits? In-Reply-To: References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> Message-ID: On Sun, Apr 4, 2010 at 9:17 PM, A.B. Jr. wrote: > While most of end user devices work with temporarily assigned IP addresses, > or even with RFC1918 behind a NAT, very humble ethernet devices come from > factory with a PERMANENTE unique mac address. Just don't tell Greenpeace - I don't think we're quite at the state yet where we need to start recycling the MAC addresses from thrown out CPE routers. Plus I'm sure the CA government will be more than happy to add a $4/device recycling fee for anything sold with a MAC address if they find out about it. Scott (PS, I've run out of Popcorn - anyone got to share?) From LarrySheldon at cox.net Sun Apr 4 23:30:42 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 04 Apr 2010 23:30:42 -0500 Subject: what about 48 bits? In-Reply-To: References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> Message-ID: <4BB96772.3090102@cox.net> I keep seeing mention here of the "permanent" MAC address. Really? Permanent? Been a long time, but it seems like one of the fun things about having DECNet-phase IV on the network was its propensity for changing the MAC address to be the DECNet address. And it seems like the HP-UX machines (among others) could write what every they wanted to as addresses. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From dr at cluenet.de Sun Apr 4 23:31:13 2010 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 5 Apr 2010 06:31:13 +0200 Subject: legacy /8 In-Reply-To: <20100404.163125.41679142.sthaug@nethelp.no> References: <4BB8947E.3080502@redpill-linpro.com> <20100404.163125.41679142.sthaug@nethelp.no> Message-ID: <20100405043113.GA2940@srv03.cluenet.de> On Sun, Apr 04, 2010 at 04:31:25PM +0200, sthaug at nethelp.no wrote: > > Juniper. If you want to run OSPFv3 on their layer 3 switches, you need > > a quite expensive "advanced" licence. OSPFv2, on the other hand, is > > included in the base licence. Interesting. So much for their "IPv6 doesn't cost extra anymore!" claim they sport today. Going to have a chat with our AM/SE about that. :-) > It used to be considerably worse. As late as May 2009, Juniper charged > $10.000 (list price) for an "IPv6 Support on JunOS" on license (for high > end M/MX/T series), and the same amount for an E series IPv6 license. The ERX ("E-Series") license was actually $50.000 list last time I looked. It's $0 nowadays indeed. Well, I guess they got their share of extra margin from .gov and .co.cn/jp when JNPR really had a significant competetive lead in providing usable IPv6 implementations (at least on their own gear... IPv6 support on ERX was very limited until recently - can't comment on stability). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From oberman at es.net Mon Apr 5 00:26:52 2010 From: oberman at es.net (Kevin Oberman) Date: Sun, 04 Apr 2010 22:26:52 -0700 Subject: what about 48 bits? In-Reply-To: Your message of "Sun, 04 Apr 2010 23:30:42 CDT." <4BB96772.3090102@cox.net> Message-ID: <20100405052652.9F8BA1CC13@ptavv.es.net> > Date: Sun, 04 Apr 2010 23:30:42 -0500 > From: Larry Sheldon > > I keep seeing mention here of the "permanent" MAC address. > > Really? Permanent? > > Been a long time, but it seems like one of the fun things about having > DECNet-phase IV on the network was its propensity for changing the MAC > address to be the DECNet address. > > And it seems like the HP-UX machines (among others) could write what > every they wanted to as addresses. Almost every system can re-write the MAC address. It's in the original 802.3 and DIX (Blue Book) Ethernet standards. I have not run into a system in some time that lacked this capability. Works on Windows, MacOS, Linux, and BSD. That said, all 802.3 devices are expected to have a permanent MAC address in ROM. At initialization time, that address is always used until software can program in the new address. Made MOP-DL booting (DECnet equivalent of bootp) interesting. -- 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 gbonser at seven.com Mon Apr 5 00:43:06 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 4 Apr 2010 22:43:06 -0700 Subject: legacy /8 In-Reply-To: References: Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6C7B@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Owen DeLong > Sent: Saturday, April 03, 2010 9:13 PM > To: Zaid Ali > Cc: nanog at nanog.org > Subject: Re: legacy /8 > > > On Apr 3, 2010, at 2:49 PM, Zaid Ali wrote: > > > They are not glowing because applications are simply not moving to > IPv6. > > Google has two popular applications on IPv6, Netflix is on it way > there but > > what are other application companies doing about it? A popular > application > > like e-mail is so far behind [ref: > > http://eng.genius.com/blog/2009/09/14/email-on-ipv6/] and I still > encounter > > registrar's providing DNS service not supporting Quad A's. > > > Uh, netflix seems fully functional to me on IPv6. What do you think is > missing? Well, there are a lot of companies out there building server applications who don't have the human bandwidth to migrate the application. Things like application clusters that do a lot if internal multicast, for example, would need to change. My instincts say you are going to see v6 roll out in a lot of production networks with devices like load balancers that can have an IPv6 virtual IP balanced to v4 servers on the back end. In that sense people aren't really migrating to v6 so much as they are accommodating it. And the vendors have some real problems when it comes to v6 that derives from lack of resource allocation. I can put together a bodacious route server on a quad CPU (hex core) with almost 200Gig of RAM for less than the cost of a management module on a small-ish router and offload a lot of the BGP stuff from the routers. In fact, with a few minor tricks you can have your edge routers connected to several peers and not have the peers talking BGP to your routers at all, they are all talking to your "bodacious" route server to which you can add processing power / RAM as needed. At that point your edge routers have one single BGP peer, the route server. And I have actually used this sort of thing in production albeit "back in the day" when the routing table first started to explode beyond the capabilities of some purple cyclops layer 3 switches I was using at the time. That is the fundamental problem as I see it right now. The vendors do not want to ship the resources required until they need to (it isn't a problem until it is a problem) and they all end up behind the curve reacting to this crisis or that rather than getting ahead of the game and producing the router than can handle a serious number of 128-bit routes. It isn't that the routing policy is bad, it is that we continue to have to work around the limitations of the gear shipped from the vendors. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Apr 5 02:20:12 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 5 Apr 2010 16:50:12 +0930 Subject: CPE Ethernet switch suggestions In-Reply-To: <4BB4B5F9.5020503@kenweb.org> References: <4BB4B5F9.5020503@kenweb.org> Message-ID: <20100405165012.0a4d264b@opy.nosense.org> On Thu, 01 Apr 2010 11:04:25 -0400 ML wrote: > Lately I've been delivering triple play services over a single CAT5 drop > from a IDF to customers. We have been using small SOHO switches but > they've been turning into a bit of a hassle since we have to stage each > switch before deployment. > > I want remove the initial staging step by allowing the installer to just > plug the switch in and have the switch grab a config from a TFTP server > noted by a DHCP option. > > Features that I would absolutely need for the switch to be viable: > > > IGMP Snooping > Dot1q VLAN tagging > Preferably 8-ports > A decent set of rate limiting options (5/10/20Mbps) > Extra bonus if it can also be PoE powered > > > Does anyone on list know of such a dream CPE device? > > ES 2108G goes close to your requirements. Don't have a wall wart because PS is built in, come with rack mount wings out of the box, have 64 bit interface traffic counters, rate limiting is in 64Kbps increments, Cisco link CLI, serial console as well as managment via HTTPs and CLI over SSH, 802.1X, port bonding/etherchannel, and are both cheap and reliable. Not sure about TFTP config support though. http://www.zyxel.com/web/product_category.php?PC1indexflag=20040520161143&display=6857 From jim at reptiles.org Mon Apr 5 02:52:16 2010 From: jim at reptiles.org (Jim Mercer) Date: Mon, 5 Apr 2010 03:52:16 -0400 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: <4BB95590.40301@cox.net> References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <4BB95590.40301@cox.net> Message-ID: <20100405075216.GA16239@reptiles.org> i remember implementing quasi-QoS on uucp. after having our modem pool hogged too many times by a select few users, i put a script into our mail system. if the script determined an email was > X bytes (100k?), the message body was rewritten with: "Contents removed at LSUC, email is not a file transport protocol." and the mail was left to continue on its path. i kinda feel like adding the same script back into my servers. 8^) -- Jim Mercer jim at reptiles.org +92 336 520-4504 "I'm Prime Minister of Canada, I live here and I'm going to take a leak." - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, "Who are you and where are you going?" From franck at genius.com Mon Apr 5 01:37:09 2010 From: franck at genius.com (Franck Martin) Date: Mon, 5 Apr 2010 18:37:09 +1200 Subject: legacy /8 In-Reply-To: References: <4BB94DF5.8080406@bogus.com> Message-ID: <51A55B2A-BCCD-4056-95C8-EA34C71F20E4@genius.com> Do like the Chinese if you want a feature put out a billion dollar tender with the feature mandatory and they will rush to do it Toute connaissance est une r?ponse ? une question On 5/04/2010, at 14:48, Christopher Morrow wrote: > On Sun, Apr 4, 2010 at 7:41 PM, joel jaeggli wrote: >> On 4/4/2010 5:10 PM, Christopher Morrow wrote: >>> >>> On Sun, Apr 4, 2010 at 4:32 PM, joel jaeggli >>> wrote: >>> >>>> >>>> Last time I checked, some of the state of the art 2004 era >>>> silicon I had >>>> laying around could forward v6 just fine in hardware. It's not >>>> so usefyl >>>> due to it's fib being a bit undersized for 330k routes plus v6, >>>> but hey, six >>>> years is long time. >>>> >>> >>> 4948 (not 6yrs old, but... still forwards v6 in the >>> slow-path, weee!) >>> >> >> Yes it does. and the slow path is sloooooooooow on the that switch. >> but >> switches and routers did and do come in colors other than blue. > > but, but, but.. then it won't match! and seriously, I can't have > another run in with the fashion police. > > In actual seriousness, my point is that plenty of this sort of gear is > in the network, and will be for a time. It's sort of inexcusable that > vendors put out gear 5 years ago that didn't do v6 in the fast path... > oh well. > > -chris > From avg at kotovnik.com Mon Apr 5 04:47:56 2010 From: avg at kotovnik.com (Vadim Antonov) Date: Mon, 5 Apr 2010 02:47:56 -0700 (PDT) Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: <19385.11469.542125.882532@world.std.com> Message-ID: It wasn't Moscow State U. It was privately-owned network (called RELCOM) from the day one (which was in 1990, not 1987... in 1987 connecting a dial-up modem to phone network was still illegal in the USSR), built by DEMOS co-op (that company is still alive, by the way). Moscow State U was one of the first customers (the guy responsible for connecting MSU later founded Stalker Inc. which makes hi-perf e-mail servers). It was UUCP-based initially, though I decided to avoid pathalias (it being a horrible kludge) and wrote UUCP message router which translated domain hostnames into UUCP next-hops - this is why email to .SU never used bang paths. The ability to build dirt-cheap networks over crappy phone lines and using some no-name PCs as message and packet routers was noticed, see for example: "Developing Networks in Less Industrialized Nations" by Larry Press (EEE Computer, vol 28, No 6, June, 1995, pp 66-71) http://som.csudh.edu/cis/lpress/ieee.htm --vadim On Sun, 4 Apr 2010, Barry Shein wrote: > > I remember around 1987 when Helsinki (Univ I believe) hooked up > Talinn, Estonia via uucp (including usenet), who then hooked up MSU > (Moscow State Univ) and the traffic began flowing. > > You could just about see the wide-eyed disbelief by some as they saw > for example alt.politics, you people just say almost *anything!*, with > your real name and location attached, and NOTHING HAPPENS??? > > I still believe that had as much to do with the collapse of the Soviet > Union as the million other politicians who wish to take credit. > > It's arguable that UUCP (and Usenet, email, etc that it carried) was > one of the most powerful forces for change in modern history. All you > needed was some freely available software, a very modest computer, a > modem, a phone line, and like so many things in life, a friend. > > And then once you "got it", you looked towards connecting to the > "real" internet, you knew just what you were after. > > > From john at sackheads.org Mon Apr 5 07:30:58 2010 From: john at sackheads.org (John Payne) Date: Mon, 5 Apr 2010 08:30:58 -0400 Subject: Auto MDI/MDI-X + conference rooms + bored == loop In-Reply-To: References: <20100326220922.GH12189@angus.ind.WPI.EDU> <2D6A0E72-28BA-489D-A3C8-8D7BAAAD0002@delong.com> Message-ID: <3E2CF547-3805-426D-B7FA-90117B5D0394@sackheads.org> On Mar 26, 2010, at 9:24 PM, Mark Foster wrote: >> or reboot is problematic in many cases. Many systems drop link- >> state during reboot for a long-enough period that the bridge-port >> restarts its spanning tree process, making results across reboots >> consistently bad. > > Interesting; Windows tends to bring link up well-prior to the login > dialogue and ive never seen a dhcp lease fail such that the user has > had no lease by the time they try to login... Easy to make happen with 802.1X, default IOS timers and an unconfigured supplicant From steve at ibctech.ca Mon Apr 5 08:20:16 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 05 Apr 2010 09:20:16 -0400 Subject: legacy /8 In-Reply-To: <502AB654CA724523B8B377300EBE11A0@TAKA> References: <4BB65B39.8010902@mompl.net> <20100402210631.GA21373@puck.nether.net> <9D78CBC7F28F40C5AF04DD2C8A40B25B@TAKA> <20100402225241.GD21373@puck.nether.net> <502AB654CA724523B8B377300EBE11A0@TAKA> Message-ID: <4BB9E390.8070202@ibctech.ca> On 2010.04.02 19:29, John Palmer (NANOG Acct) wrote: > > ----- Original Message ----- From: "Majdi S. Abbas" > To: "John Palmer (NANOG Acct)" > Cc: "NANOG list" > Sent: Friday, April 02, 2010 5:52 PM > Subject: Re: legacy /8 > > >> On Fri, Apr 02, 2010 at 05:48:44PM -0500, John Palmer (NANOG Acct) wrote: >>> On the topic of IP4 exhaustion: 1/8, 2/8 and 5/8 have all been >>> assigned in the last 3 months yet I don't see them being allocated >>> out to customers (users) yet. >>> >>> Is this perhaps a bit of hoarding in advance of the complete >>> depletion of /8's? >> >> Doubt it. 1/8 is still being evaluated to determine just how usable >> portions of it are, thanks to silly people of the world that decided >> 1.1.1.x and the like were 1918 space. >> >> As for the others, the RIR requests it when they are running low, >> but certainly not exhausted, and as slow as people are to update their >> bogon filters, it sounds like general good practice not to assign out of >> a new /8 until pre-existing resources are exhausted. >> > > Was looking for the "allocated" file on the ARIN website, but can't > remember > where it is. They used to have a file with one line per allocation that > started > like this "arin|US|ipv4". Is that still public somewhere? If you are looking for what blocks have been allocated to ARIN by IANA, the file is maintained on the IANA site: http://www.iana.org/assignments/ipv4-address-space/ If you're referring to the IP space ARIN has issued out, I don't know if there is a single authoritative text list (at least I couldn't find one quickly). There is a mailing list maintained by ARIN that tracks daily issued blocks, but it appears to have archives going back only to late 2k8: http://lists.arin.net/mailman/listinfo/arin-issued Steve From berg at wins.net Mon Apr 5 08:37:43 2010 From: berg at wins.net (Russell Berg) Date: Mon, 5 Apr 2010 08:37:43 -0500 Subject: NANOG Digest, Vol 27, Issue 25 Message-ID: <5d1djufi9x63j7o1o1wlkxmn.1270474678118@email.android.com> "nanog-request at nanog.org" wrote: Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. RE: legacy /8 (George Bonser) 2. Re: legacy /8 (Randy Bush) 3. RE: legacy /8 (Frank Bulk) 4. RE: legacy /8 (Frank Bulk) 5. Re: legacy /8 (David Conrad) 6. Re: legacy /8 (Zaid Ali) 7. Re: legacy /8 (Mark Smith) 8. Fw: legacy /8 (Mark Smith) ---------------------------------------------------------------------- Message: 1 Date: Sat, 3 Apr 2010 12:09:51 -0700 From: "George Bonser" Subject: RE: legacy /8 To: Cc: nanog at nanog.org Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6C76 at RWC-EX1.corp.seven.com> Content-Type: text/plain; charset="us-ascii" > -----Original Message----- > From: marka at isc.org [mailto:marka at isc.org] > Sent: Saturday, April 03, 2010 11:42 AM > To: George Bonser > Cc: Larry Sheldon; nanog at nanog.org > Subject: Re: legacy /8 > > > And we would have still had the same problem of intercommunicating. > We know how to talk from IPv6 to IPv4 and get the reply traffic back. > The hard part is how to initiate connection from IPv4 to IPv6. The > same problem would exist in your "just expand the address bits world". > > Mark Actually, Mark, I hadn't said "just expand the address", I said to tunnel v4 in v4 which we already know how to do and most routers are already capable of doing. But yes, in the case of legacy devices that don't "speak" the new protocol, some sort of state for the flow would have to be maintained in that unit's first hop (or close to first hop) gateway. Simply increasing the address header on v4 to 128 bits would have fixed this problem years ago and got rid of such problems as NAT and we wouldn't be having this issue (and it would have been completely backwards compatible as 0s would be inserted into the new expanded address bits to put the legacy space in a special address range. I wouldn't expect to work out all the details over email on a weekend but I don't think it would take 10 years, either. The fundamental issue to me is that v6 solves a lot of problems that aren't really problems for most people and to get the fix that solves the problem you do have, you must accept a bunch of additional "fixes" for problems you don't have that makes the whole thing some big unwieldy contraption. That having been said, once the world has migrated to v6, we should have an easier go of it in the future as v6 is more easily extensible. But in the meantime, we are stuck with both protocols for probably the next 20 years or so as there are going to be places that are going to run v4 internally even if they communicate v6 externally. So ... "we are going to mandate that everyone use this new and better car but it will take different fuel, use different tires, won't fit in your garage and oh, it is incompatible with all existing roads unless you load it up on one of the old style vehicles piggy-back, but new roads are being built (here's a picture of one) and might someday be available where you live. And two years from now there will be none of the old cars left." But my daughter will need a car in three years and there are no such roads here. "Oh well! The new way is much better, it is for your own good, you will see. Trust me". ------------------------------ Message: 2 Date: Sun, 04 Apr 2010 05:36:26 +0900 From: Randy Bush Subject: Re: legacy /8 To: George Bonser Cc: North American Network Operators Group Message-ID: Content-Type: text/plain; charset=US-ASCII > No. But that isn't the point. The point is that v6 was a bad solution > to the problem. Rather than simply address the address depletion > problem, it also "solves" a lot of problems that nobody has while > creating a whole bunch more that we will have. it's known as "second system syndrome." and you neglect to add that ipv6 did not deal with the routing problems, which are rather intimately connected with addressing in both the ipv4 and the ipv6 models. randy ------------------------------ Message: 3 Date: Sat, 3 Apr 2010 16:22:12 -0500 From: "Frank Bulk" Subject: RE: legacy /8 To: Message-ID: Content-Type: text/plain; charset="iso-8859-1" If "every significant router on the market" supported IPv6 five years ago, why aren't transit links glowing with IPv6 connectivity? If it's not the hardware, than I'm guessing it's something else, like people or processes? Frank -----Original Message----- From: Michael Dillon [mailto:wavetossed at googlemail.com] Sent: Saturday, April 03, 2010 1:07 PM To: Larry Sheldon Cc: nanog at nanog.org Subject: Re: legacy /8 > Not often you hear something that has changed just about every aspect of > life and enabled things that could not be imagined at its outset ?called > a failure Sounds like you are describing the Roman Empire. It failed and that's why we now have an EU in its place. Things change. Time to move on. IPv4 has run out of addresses and we are nowhere near finished GROWING THE NETWORK. IPv6 was created to solve just this problem, and 10 years ago folks started deploying it in order to be ready. By 5 years ago, every significant router on the market supported IPv6. Now that we actually need IPv6 in order to continue network growth, most ISPs are in the fortunate position that their network hardware already supports it well enough, so the investment required is minimized. --Michael Dillon ------------------------------ Message: 4 Date: Sat, 3 Apr 2010 16:30:32 -0500 From: "Frank Bulk" Subject: RE: legacy /8 To: "'James Hess'" , "George Bonser" , Message-ID: Content-Type: text/plain; charset="us-ascii" If Google made the same strong statement with IPv6 as they have done with their 700 MHz bid or the Google-subsidized fiber project, it could make a significant difference. A few examples come to mind: - free or discounted advertising to vendors if delivered over IPv6: this would incent advertisers to have viewers access content over IPv6, even if it was just on mobile phones with certain apps. - free or discounted Google Apps if a certain percentage of client access was over IPv6, etc: this would incent enterprises (the non-profits are either free or discounted, so this example applies mostly to the for-profits) to find native IPv6 access because it provides an immediate and direct savings Frank -----Original Message----- From: James Hess [mailto:mysidia at gmail.com] Sent: Saturday, April 03, 2010 1:08 PM To: George Bonser Cc: nanog at nanog.org Subject: Re: legacy /8 I suppose if Google announced tomorrow, that search engine access over IPv4 is going to be discontinued in 12 months, and you will have to connect using IPv6, then IPv4 might become legacy....... They could have posted that on April 1, with impunity too :) Enterprises may take a long time to move, there are so many participants involved, it is difficult to fathom them all acting at once, at least, until some major content providers, major search engines, etc, announce they will _stop_ providing services over V4. -- -J ------------------------------ Message: 5 Date: Sat, 3 Apr 2010 11:35:56 -1000 From: David Conrad Subject: Re: legacy /8 To: frnkblk at iname.com Cc: nanog at nanog.org Message-ID: Content-Type: text/plain; charset=us-ascii On Apr 3, 2010, at 11:22 AM, Frank Bulk wrote: > If "every significant router on the market" supported IPv6 five years ago, > why aren't transit links glowing with IPv6 connectivity? If it's not the > hardware, than I'm guessing it's something else, like people or processes? Or the fact that "supporting IPv6" could (and as far I could tell did until very recently) mean minimalistic process switching of packets without any of the 'niceties' of filtering, management, monitoring, etc. support. It also ignores the fact that there is a bit more to providing Internet service than simply running routers. However, historically we had: 1) why should ISPs pay to deploy IPv6 when their customers aren't asking for it? 2) why should customers ask for IPv6 when there is no content available via it? 3) why should content providers make their content available over IPv6 when they can't get it from their ISPs and none of their customers are asking for it? It may be that IPv4 free pool run out will result in costs for obtaining IPv4 to rise sufficiently to address (1). Or we could have multi-layer NAT. Regards, -drc ------------------------------ Message: 6 Date: Sat, 03 Apr 2010 14:49:57 -0700 From: Zaid Ali Subject: Re: legacy /8 To: , Message-ID: Content-Type: text/plain; charset="ISO-8859-1" They are not glowing because applications are simply not moving to IPv6. Google has two popular applications on IPv6, Netflix is on it way there but what are other application companies doing about it? A popular application like e-mail is so far behind [ref: http://eng.genius.com/blog/2009/09/14/email-on-ipv6/] and I still encounter registrar's providing DNS service not supporting Quad A's. I feel talking to network operators is preaching to the choir, the challenge is helping content providers think about moving to IPv6. I think we will only see success once we are able to successfully work with content providers but they are quite busy now building real technology like the "Cloud" Zaid On 4/3/10 2:22 PM, "Frank Bulk" wrote: > If "every significant router on the market" supported IPv6 five years ago, > why aren't transit links glowing with IPv6 connectivity? If it's not the > hardware, than I'm guessing it's something else, like people or processes? > > Frank > > -----Original Message----- > From: Michael Dillon [mailto:wavetossed at googlemail.com] > Sent: Saturday, April 03, 2010 1:07 PM > To: Larry Sheldon > Cc: nanog at nanog.org > Subject: Re: legacy /8 > >> Not often you hear something that has changed just about every aspect of >> life and enabled things that could not be imagined at its outset ?called >> a failure > > Sounds like you are describing the Roman Empire. It failed and that's why > we now have an EU in its place. > > Things change. Time to move on. > > IPv4 has run out of addresses and we are nowhere near finished GROWING > THE NETWORK. IPv6 was created to solve just this problem, and 10 years > ago folks started deploying it in order to be ready. By 5 years ago, every > significant router on the market supported IPv6. Now that we actually need > IPv6 in order to continue network growth, most ISPs are in the fortunate > position that their network hardware already supports it well enough, so > the investment required is minimized. > > --Michael Dillon > > ------------------------------ Message: 7 Date: Sun, 4 Apr 2010 10:45:00 +0930 From: Mark Smith Subject: Re: legacy /8 To: "George Bonser" Cc: nanog at nanog.org Message-ID: <20100404104500.1c7b6d49 at opy.nosense.org> Content-Type: text/plain; charset=US-ASCII On Sat, 3 Apr 2010 11:25:48 -0700 "George Bonser" wrote: > > > > -----Original Message----- > > From: Larry Sheldon [mailto:LarrySheldon at cox.net] > > Sent: Saturday, April 03, 2010 10:54 AM > > Cc: nanog at nanog.org > > Subject: Re: legacy /8 > > > > > > That is the parachute's fault? > > > > Really? > > -- > > > No. But that isn't the point. The point is that v6 was a bad solution > to the problem. Rather than simply address the address depletion > problem, it also "solves" a lot of problems that nobody has while > creating a whole bunch more that we will have. Ever used IPX or Appletalk? If you haven't, then you don't know how simple and capable networking can be. And those protocols were designed more than 20 years ago, yet they're still more capable than IPv4. I used to teach Novell CNE courses around the mid 90s. Of the 7 courses, one of them was a two day course on a networking protocol. That networking protocol *wasn't* IPX - it was TCP/IP. IPX just worked, but you had to spend two days explaining TCP/IP. Even though I'd been using TCP/IP for a number of years before then, it still to me 5 attempts at teaching that course before I was completely happy with how I'd explained subnets, and had that feedback from students. I think IPv6 has not just learnt from the history of IPv4, it has also learnt from the history of other protocols. > Rather than simply > address the problem that was on the horizon, the group took the > opportunity to complicate it with a lot of other contraptions and saw > that as being a "good thing" that apparently we and the vendors are just > too dumb to realize or something. And they made v4 incompatible with v6 > rather really addressing the problem. They saw simply extending the > header with additional address bits to be a "bad thing" for some reason > when that is really all that was needed and so they went on building > their mousetrap and we have the mother of all internet protocols that > slices and dices and even makes Julien fries when all we needed was a > bigger potato peeler. > > I am not saying we can change it at this point but I am saying we should > learn from it and never, ever, do things this way again. > > > > > > > ------------------------------ Message: 8 Date: Sun, 4 Apr 2010 10:46:14 +0930 From: Mark Smith Subject: Fw: legacy /8 To: NANOG List Message-ID: <20100404104614.6bff3a1a at opy.nosense.org> Content-Type: text/plain; charset="us-ascii" Hi, Vint Cerf kindly sent through some more explanation. Regards, Mark. Begin forwarded message: Date: Sat, 3 Apr 2010 08:17:28 -0400 From: Vint Cerf To: Mark Smith Cc: Andrew Gray <3356 at blargh.com>, NANOG List Subject: Re: legacy /8 When the Internet design work began, there were only a few fairly large networks around. ARPANET was one. The Packet Radio and Packet Satellite networks were still largely nascent. Ethernet had been implemented in one place: Xerox PARC. We had no way to know whether the Internet idea was going to work. We knew that the NCP protocol was inadequate for lossy network operation (think: PRNET and Ethernet in particular). This was a RESEARCH project. We assumed that national scale networks were expensive so there would not be too many of them. And we certainly did not think there would be many built for a proof of concept. So 8 bits seemed reasonable. Later, with local networks becoming popular, we shifted to the class A-D address structure and when class B was near exhaustion, the NSFNET team (I think specifically Hans-Werner Braun but perhaps others also) came up with CIDR and the use of masks to indicate the size of the "network" part of the 32 bit address structure. By 1990 (7 years after the operational start of the Internet and 17 years since its basic design), it seemed clear that the 32 bit space would be exhausted and the long debate about IPng that became IPv6 began. CIDR slowed the rate of consumption through more efficient allocation of network addresses but now, in 2010, we face imminent exhaustion of the 32 bit structure and must move to IPv6. Part of the reason for not changing to a larger address space sooner had to do with the fact that there were a fairly large number of operating systems in use and every one of them would have had to be modified to run a new TCP and IP protocol. So the "hacks" seemed the more convenient alternative. There had been debates during the 1976 year about address size and proposals ranged from 32 to 128 bit to variable length address structures. No convergence appeared and, as the program manager at DARPA, I felt it necessary to simply declare a choice. At the time (1977), it seemed to me wasteful to select 128 bits and variable length address structures led to a lot of processing overhead per packet to find the various fields of the IP packet format. So I chose 32 bits. vint On Fri, Apr 2, 2010 at 10:42 PM, Mark Smith < nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote: > On Fri, 02 Apr 2010 15:38:26 -0700 > Andrew Gray <3356 at blargh.com> wrote: > > > Jeroen van Aart writes: > > > > > Cutler James R wrote: > > >> I also just got a fresh box of popcorn. I will sit by and wait > > > > > > I honestly am not trying to be a troll. It's just everytime I glance > over > > > the IANA IPv4 Address Space Registry I feel rather annoyed about all > those > > > /8s that were assigned back in the day without apparently realising we > > > might run out. > > > > > > It was explained to me that many companies with /8s use it for their > > > internal network and migrating to 10/8 instead is a major pain. > > > > You know, I've felt the same irritation before, but one thing I am > wondering > > and perhaps some folks around here have been around long enough to know - > > what was the original thinking behind doing those /8s? > > > > I understand that they were A classes and assigned to large companies, > etc. > > but was it just not believed there would be more than 126(-ish) of these > > entities at the time? Or was it thought we would move on to larger > address > > space before we did? Or was it that things were just more free-flowing > back > > in the day? Why were A classes even created? RFC 791 at least doesn't > seem > > to provide much insight as to the 'whys'. > > > > That's because RFC791 is a long way from the original design > assumptions of the Internet Protocols. > > "A Protocol for Packet Network Intercommunication", Vinton G. Cerf and > Robert E. Kahn, 1974, says - > > "The choice for network identification (8 bits) allows up to 256 > distinct networks. This size seems sufficient for the foreseeable > future." > > That view seems to have persisted up until at least RFC761, January > 1980, which still specified the single 8 bit network, 24 bit node > address format. RFC791, September 1981, introduces classes. So > somewhere within that period it was recognised that 256 networks wasn't > going to be enough. I'm not sure why the 32 bit address size was > persisted with at that point - maybe it was because there would be > significant performance loss in handling addresses greater than what > was probably the most common host word size at the time. > > If you start looking into the history of IPv4 addressing, and arguably > why it is so hard to understand and teach compared to other > protocols such as Novell's IPX, Appletalk etc., everything that has been > added to allow increasing the use of IP (classes, subnets, classless) > while avoiding increasing the address size past 32 bits is a series of > very neat hacks. IPv4 is a 1970s protocol that has had to cope with > dramatic and unforeseen success. It's not a state of the art protocol > any more, and shouldn't be used as an example of how things should be > done today (As a minimum, I think later protocols like Novell's IPX and > Appletalk are far better candidates). It is, however, a testament to how > successfully something can be hacked over time to continue to work far, > far beyond it's original design parameters and assumptions. > > (IMO, if you want to understand the design philosophies of IPv6 you're > better off studying IPX and Appletalk than using your IPv4 knowledge. > I think IPv6 is a much closer relative to those protocols than it is to > IPv4. For example, router anycast addresses was implemented and used in > Appletalk.) > > Possibly Vint Cerf might be willing to clear up some of these questions > about the origins of IPv4 addressing. > > Regards, > Mark. > > -------------- next part -------------- When the Internet design work began, there were only a few fairly large networks around. ARPANET was one. The Packet Radio and Packet Satellite networks were still largely nascent. Ethernet had been implemented in one place: Xerox PARC. We had no way to know whether the Internet idea was going to work. We knew that the NCP protocol was inadequate for lossy network operation (think: PRNET and Ethernet in particular). This was a RESEARCH project. We assumed that national scale networks were expensive so there would not be too many of them. And we certainly did not think there would be many built for a proof of concept. So 8 bits seemed reasonable. Later, with local networks becoming popular, we shifted to the class A-D address structure and when class B was near exhaustion, the NSFNET team (I think specifically Hans-Werner Braun but perhaps others also) came up with CIDR and the use of masks to indicate the size of the "network" part of the 32 bit address structure. By 1990 (7 years after the operational start of the Internet and 17 years since its basic design), it seemed clear that the 32 bit space would be exhausted and the long debate about IPng that became IPv6 began. CIDR slowed the rate of consumption through more efficient allocation of network addresses but now, in 2010, we face imminent exhaustion of the 32 bit structure and must move to IPv6. Part of the reason for not changing to a larger address space sooner had to do with the fact that there were a fairly large number of operating systems in use and every one of them would have had to be modified to run a new TCP and IP protocol. So the "hacks" seemed the more convenient alternative. There had been debates during the 1976 year about address size and proposals ranged from 32 to 128 bit to variable length address structures. No convergence appeared and, as the program manager at DARPA, I felt it necessary to simply declare a choice. At the time (1977), it seemed to me wasteful to select 128 bits and variable length address structures led to a lot of processing overhead per packet to find the various fields of the IP packet format. So I chose 32 bits. vint On Fri, Apr 2, 2010 at 10:42 PM, Mark Smith <[1]nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote: On Fri, 02 Apr 2010 15:38:26 -0700 Andrew Gray <[2]3356 at blargh.com> wrote: > Jeroen van Aart writes: > > > Cutler James R wrote: > >> I also just got a fresh box of popcorn. I will sit by and wait > > > > I honestly am not trying to be a troll. It's just everytime I glance over > > the IANA IPv4 Address Space Registry I feel rather annoyed about all those > > /8s that were assigned back in the day without apparently realising we > > might run out. > > > > It was explained to me that many companies with /8s use it for their > > internal network and migrating to 10/8 instead is a major pain. > > You know, I've felt the same irritation before, but one thing I am wondering > and perhaps some folks around here have been around long enough to know - > what was the original thinking behind doing those /8s? > > I understand that they were A classes and assigned to large companies, etc. > but was it just not believed there would be more than 126(-ish) of these > entities at the time? Or was it thought we would move on to larger address > space before we did? Or was it that things were just more free-flowing back > in the day? Why were A classes even created? RFC 791 at least doesn't seem > to provide much insight as to the 'whys'. > That's because RFC791 is a long way from the original design assumptions of the Internet Protocols. "A Protocol for Packet Network Intercommunication", Vinton G. Cerf and Robert E. Kahn, 1974, says - "The choice for network identification (8 bits) allows up to 256 distinct networks. This size seems sufficient for the foreseeable future." That view seems to have persisted up until at least RFC761, January 1980, which still specified the single 8 bit network, 24 bit node address format. RFC791, September 1981, introduces classes. So somewhere within that period it was recognised that 256 networks wasn't going to be enough. I'm not sure why the 32 bit address size was persisted with at that point - maybe it was because there would be significant performance loss in handling addresses greater than what was probably the most common host word size at the time. If you start looking into the history of IPv4 addressing, and arguably why it is so hard to understand and teach compared to other protocols such as Novell's IPX, Appletalk etc., everything that has been added to allow increasing the use of IP (classes, subnets, classless) while avoiding increasing the address size past 32 bits is a series of very neat hacks. IPv4 is a 1970s protocol that has had to cope with dramatic and unforeseen success. It's not a state of the art protocol any more, and shouldn't be used as an example of how things should be done today (As a minimum, I think later protocols like Novell's IPX and Appletalk are far better candidates). It is, however, a testament to how successfully something can be hacked over time to continue to work far, far beyond it's original design parameters and assumptions. (IMO, if you want to understand the design philosophies of IPv6 you're better off studying IPX and Appletalk than using your IPv4 knowledge. I think IPv6 is a much closer relative to those protocols than it is to IPv4. For example, router anycast addresses was implemented and used in Appletalk.) Possibly Vint Cerf might be willing to clear up some of these questions about the origins of IPv4 addressing. Regards, Mark. References 1. mailto:nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org 2. mailto:3356 at blargh.com ------------------------------ _______________________________________________ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog End of NANOG Digest, Vol 27, Issue 25 ************************************* From rubensk at gmail.com Mon Apr 5 09:25:19 2010 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 5 Apr 2010 11:25:19 -0300 Subject: CPE Ethernet switch suggestions In-Reply-To: <4BB4B5F9.5020503@kenweb.org> References: <4BB4B5F9.5020503@kenweb.org> Message-ID: Although also being a small SOHO switch, may be Netgear GS-108T can suit your needs. > I want remove the initial staging step by allowing the installer to just > plug the switch in and have the switch grab a config from a TFTP server > noted by a DHCP option. Not quite, it can download config from TFTP but only thru the web interface. No CLI. One thought: writing a script that the DHCP server would run to log into a switch and grab a config. > IGMP Snooping > Dot1q VLAN tagging > Preferably 8-ports Check check check. > A decent set of rate limiting options (5/10/20Mbps) Humm... it has 4, 10 and 20 Mbps. In the future you can also have 40M/60M/100M/200M/400M/1000M. > Extra bonus if it can also be PoE powered Not from factory, but you might build a PoE power adapter to replace the wall adapter it comes with. The annoying thing about it's the "factory default" button which users love to press when there is an outage "to see if it works again". Cover it before sending such a unit to field. Rubens From msokolov at ivan.Harhan.ORG Mon Apr 5 10:21:34 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Mon, 5 Apr 2010 15:21:34 GMT Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? Message-ID: <1004051521.AA22864@ivan.Harhan.ORG> Jim Mercer wrote: > if the script determined an email was > X bytes (100k?), the message body > was rewritten with: > > "Contents removed at LSUC, email is not a file transport protocol." > and the mail was left to continue on its path. > > i kinda feel like adding the same script back into my servers. I have my Sendmail configured to cut off anything past 256 KB in the collect phase. At first I had it configured to reject the whole message (close the SMTP connection while the junk is still spewing), but people started assuming that my E-mail address was bad instead of realizing that they were sending oversize junk, so I've changed it to cut off and discard the excess fat, but still let the first 256 KB through so I at least see that someone tried to send me something. Files are meant to be FTPed, not E-mailed. If someone is too stupid to use a real command line FTP client to upload a file to my FTP drop box, I make them use www.yousendit.com. MS From lowen at pari.edu Mon Apr 5 10:49:52 2010 From: lowen at pari.edu (Lamar Owen) Date: Mon, 5 Apr 2010 11:49:52 -0400 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: References: Message-ID: <201004051149.52621.lowen@pari.edu> On Saturday 03 April 2010 09:38:46 pm IPv3.com wrote: > What is "The Internet" TCP/IP or UNIX-to-UNIX ? 'The Internet' is a collective internetworking of several thousand autonomous systems, using a common protocol, that masquerades as a unified whole. Whether this protocol is 1822, NCP, or IPvX is irrelevant. -- On the UUCP memory lane side of this thread, I had a site in the uucp maps way back when, used smail on a Tandy 6000, then an AT&T 3B1, took a stripped-down feed (a full feed at 9600 over InterLATA long distance was brutal, even when a full feed was only 40MB per day), and had both a '.uucp' pseudo-FQDN as well as a bang path from uunet as such. Ran C-News on both the T6K and the 3B1....whew, that's a long time ago. My uucp upstream had leased line uucp links to more than one upstream. His upstream links were active pretty much all of the time, and I do for one remember doing multihop bang path uucp using HoneyDanBer on the 3B1 many moons ago. Sort of a poor-man's FTP archive access. He for a while took full feeds on Sun 3 gear, which was an upgrade from the Tandy 6000 that previously had had 9600bps leased line links, and was how I found him in the first place, being a T6K user. Many software archives were available with bang-path uucp; with pathalias and the uucp-maps loaded you could even do, IIRC, uunet-homed bang-path uucp. And when all but your own path were on leased lines, the transfer happened pretty much immediately, at least for small stuff. Then he got leased line SLIP links, and got his own real FQDN. He's still out there, and still offers UNIX shell access....nanook, you listening? There was business in uucp linkage back in the day; uunet made its start that way, remember? As to the sendmail 'hack;' well, uucp was and is just another email transport, like SMTP or Netmail/Echomail, is. Nothing really hackish about it. So, since, through uucp 'proxies' to ftp archives (a uucp to IP gateway of sorts), was I 'on the Internet' or not? Yes and no.....but then I got SLIP access, thanks to Karn's KA9Q NOS ported to 3B1, and the rest, as they say, was history. Still have my first editions of 'Managing UUCP and Usenet' and 'Using UUCP and USenet' packed away somewhere.... From bogstad at pobox.com Mon Apr 5 10:54:06 2010 From: bogstad at pobox.com (Bill Bogstad) Date: Mon, 5 Apr 2010 11:54:06 -0400 Subject: what about 48 bits? In-Reply-To: <4BB96187.6040703@bogus.com> References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> <20100405105746.750257bf@opy.nosense.org> <20100405025742.GR75640@gerbil.cluepon.net> <4BB96187.6040703@bogus.com> Message-ID: On Mon, Apr 5, 2010 at 12:05 AM, joel jaeggli wrote: > On 4/4/2010 7:57 PM, Richard A Steenbergen wrote: >> >> On Mon, Apr 05, 2010 at 10:57:46AM +0930, Mark Smith wrote: >>> >>> Has anybody considered lobbying the IEEE to do a point to point version >>> of Ethernet to gets rid of addressing fields? Assuming an average 1024 >>> byte packet size, on a 10Gbps link they're wasting 100+ Mbps. 100GE / >>> 1TE starts to make it even more worth doing. >> >> If you're lobbying to have the IEEE do something intelligent to Ethernet >> why don't you start with a freaking standardization of jumbo frames. The >> lack of a real standard and any type of negotiation protocol for two >> devices under different administrative control are all but guaranteeing >> end to end jumbo frame support will never be practical. > > Not that I disagree, given that we use them rather a lot but 7.2usec (at > 10Gbe) is sort of a long time to wait before a store and forward arch switch > gets down to the task of figuring out what to do with the packet. The > problem gets worse if mtu sizes bigger than 9k ever become popular, ?kind of > like being stuck behind an elephant while boarding an elevator. I didn't run the numbers, but my guesstimate is that would be roughly half the latency that a max sized standard packet would have taken on a 1Gbe switch. It sound reasonable to me that at some point during the march from 10->100->1000->10000 mbit/sec a decision could have been made that one of those upgrades would only decrease max. per hop packet latency by a factor of 2 rather then 10. Particularly since when first introduced, each speed increment was typically used for aggregating a bunch of slower speed links which meant that the actual minimum total latency was already being constrained by the latency on those slower links anyway. OTOH, I totally buy the argument on the difficulty of frame size negotiation and backward compatibility. I think that one of the reasons for the continuing success of "Ethernet" technologies has been implementation simplicity and 100% compatibility above the level of the NIC. Bill Bogstad From zeusdadog at gmail.com Mon Apr 5 11:09:02 2010 From: zeusdadog at gmail.com (Jay Nakamura) Date: Mon, 5 Apr 2010 12:09:02 -0400 Subject: what about 48 bits? In-Reply-To: References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> <20100405105746.750257bf@opy.nosense.org> <20100405025742.GR75640@gerbil.cluepon.net> <4BB96187.6040703@bogus.com> Message-ID: > negotiation and backward compatibility. ?I think that one of the > reasons for the continuing success of "Ethernet" technologies has been > implementation simplicity and 100% compatibility above the level of > the NIC. I would have attributed the success of Ethernet to price! From LarrySheldon at cox.net Mon Apr 5 11:12:16 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 05 Apr 2010 11:12:16 -0500 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: <1004051521.AA22864@ivan.Harhan.ORG> References: <1004051521.AA22864@ivan.Harhan.ORG> Message-ID: <4BBA0BE0.7070203@cox.net> On 4/5/2010 10:21, Michael Sokolov wrote: > Jim Mercer wrote: > >> if the script determined an email was > X bytes (100k?), the message body >> was rewritten with: >> >> "Contents removed at LSUC, email is not a file transport protocol." >> and the mail was left to continue on its path. >> >> i kinda feel like adding the same script back into my servers. > > I have my Sendmail configured to cut off anything past 256 KB in the > collect phase. At first I had it configured to reject the whole message > (close the SMTP connection while the junk is still spewing), but people > started assuming that my E-mail address was bad instead of realizing > that they were sending oversize junk, so I've changed it to cut off and > discard the excess fat, but still let the first 256 KB through so I at > least see that someone tried to send me something. > > Files are meant to be FTPed, not E-mailed. If someone is too stupid to > use a real command line FTP client to upload a file to my FTP drop box, > I make them use www.yousendit.com. At Creighton the VP for IT explained to me that the President of the University was too stupid to use FTP. So we had to rebuild the mail system to send his Power Point Presentation the 150 yards to the President's Office. (I don't remember how big it was--a two-hour presentation as I recall.) With CC's to most of the known universe. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From jlewis at lewis.org Mon Apr 5 11:13:35 2010 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 5 Apr 2010 12:13:35 -0400 (EDT) Subject: interop show network (was: legacy /8) In-Reply-To: References: Message-ID: On Sun, 4 Apr 2010, Christopher Morrow wrote: > also, see previous 12 episodes of this conversation.. 1 /8 == ~3months > in ARIN allocation timeframes. Does a trade show really need 16M IPv4 addresses though? How many other /8's were assigned way back when IPv4 was being given out so freely that ARIN would laugh at if that org applied today for that /8? If we could recover them all, how many more years of IPv4 allocations would that buy us? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From brandon.galbraith at gmail.com Mon Apr 5 11:17:05 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Mon, 5 Apr 2010 11:17:05 -0500 Subject: interop show network (was: legacy /8) In-Reply-To: References: Message-ID: On Mon, Apr 5, 2010 at 11:13 AM, Jon Lewis wrote: > > If we could recover them all, how many more years of IPv4 allocations would > that buy us? > > Not enough. > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgpfor PGP public key_________ > > -- Brandon Galbraith Voice: 630.492.0464 From jbfixurpc at gmail.com Mon Apr 5 11:21:21 2010 From: jbfixurpc at gmail.com (Joe) Date: Mon, 5 Apr 2010 12:21:21 -0400 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: <1004051521.AA22864@ivan.Harhan.ORG> Message-ID: <000801cad4dc$093b8630$4401a8c0@jgbpc> I think its generally agreed that FTP is used for file transfers, but unfortunately the option exists to attach files within an email thanks in part to MS/AOL/Compuserve and numerous others long ago. I believe its due in part to ease of use for those that aren't technically inclined to know better, and make things "easier" for them (harder on others). Kind of like cattle, if you leave a hole (or make a hole) in the fence eventually it will be used and the only thing you can do is build a fence outside of the hole to keep the heard from getting to far. -Joe > -----Original Message----- > From: Michael Sokolov [mailto:msokolov at ivan.Harhan.ORG] > Sent: Monday, April 05, 2010 11:22 AM > To: nanog at nanog.org > Subject: Re: What is "The Internet" TCP/IP or UNIX-to-UNIX ? > > > Jim Mercer wrote: > > > if the script determined an email was > X bytes (100k?), > the message > > body was rewritten with: > > > > "Contents removed at LSUC, email is not a file transport protocol." > > and the mail was left to continue on its path. > > > > i kinda feel like adding the same script back into my servers. > > I have my Sendmail configured to cut off anything past 256 KB > in the collect phase. At first I had it configured to reject > the whole message (close the SMTP connection while the junk > is still spewing), but people started assuming that my E-mail > address was bad instead of realizing that they were sending > oversize junk, so I've changed it to cut off and discard the > excess fat, but still let the first 256 KB through so I at > least see that someone tried to send me something. > > Files are meant to be FTPed, not E-mailed. If someone is too > stupid to use a real command line FTP client to upload a file > to my FTP drop box, I make them use www.yousendit.com. > > MS > From Joel.Snyder at Opus1.COM Mon Apr 5 11:28:51 2010 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Mon, 05 Apr 2010 09:28:51 -0700 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? (Jim Mercer) In-Reply-To: References: Message-ID: <4BBA0FC3.2000109@opus1.com> >The ability to build dirt-cheap networks over crappy phone lines >and using some no-name PCs as message and packet routers was >noticed, see for example: "Developing Networks in Less >Industrialized Nations" by Larry Press Heck, I even wrote my PhD dissertation (http://www.opus1.com/www/jms/diss.html) on it. And among the 848 references, this "Antonov" character (avg at hq.demos.su) even gets quoted three times (assuming you're not also V.S.Antonov who wrote "Interfacing Tasks of Systems SM and ES Computers and Ways of Their Solution" in 1983). jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From smb at cs.columbia.edu Mon Apr 5 11:42:43 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 5 Apr 2010 12:42:43 -0400 Subject: what about 48 bits? In-Reply-To: References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> <20100405105746.750257bf@opy.nosense.org> <20100405025742.GR75640@gerbil.cluepon.net> <4BB96187.6040703@bogus.com> Message-ID: <2B39543C-7EF5-48AE-9E54-3E8A0C714204@cs.columbia.edu> On Apr 5, 2010, at 12:09 02PM, Jay Nakamura wrote: >> negotiation and backward compatibility. I think that one of the >> reasons for the continuing success of "Ethernet" technologies has been >> implementation simplicity and 100% compatibility above the level of >> the NIC. > > I would have attributed the success of Ethernet to price! > > You've got the causality wrong -- it wasn't cheap, way back when. --Steve Bellovin, http://www.cs.columbia.edu/~smb From NANOG at Aquillar.com Mon Apr 5 11:46:44 2010 From: NANOG at Aquillar.com (Peter Boone) Date: Mon, 5 Apr 2010 12:46:44 -0400 Subject: Wireless bridge In-Reply-To: <23ab01c9f07f$b7aa6480$26ff2d80$@com> References: <005c01c9f015$852ae490$8f80adb0$@com> <877585b00906180753s47617a64la780d7ac1f8c05ca@mail.gmail.com> <09ef01c9f02d$221f21f0$665d65d0$@com> <1245341463.1310.22.camel@legolas.orthanc.ca> <0e9401c9f033$24f4a160$6edde420$@com> <23ab01c9f07f$b7aa6480$26ff2d80$@com> Message-ID: <07d901cad4df$934e7af0$b9eb70d0$@com> Hi NANOG, I promised to post an update down the line on what happened with my wireless situation. Here it is. I purchased 2x Ubiquity Bullet2's (2.4 GHz) and utilized our existing antennas. It has been working extremely well, pushing a stable 54 Mbps over the link without issue. Signal strength is consistently -40 dBm +/- 2 dBm, from about -80 dBm before! Total cost included 2x Bullets, 2x PoE adaptors, and approx 40 ft of STP cat5: $120. I have yet to see what happens in a big thunderstorm, but I extrapolate that they will be able to handle the EMP without going haywire like before. They have worked very well through conditions that our last setup would not. Thanks again for the input everyone! Peter -----Original Message----- From: Peter Boone [mailto:NANOG at Aquillar.com] Sent: June-18-09 9:46 PM To: nanog at nanog.org Subject: RE: Wireless bridge OK, from reading all the excellent feedback I've got on and off list I've attempted to compile a "quick" summary of findings/ideas/products so far. - RouterBoard is no good for this type of application. - Get a unit with radio/antenna integrated, PoE from inside the building (outdoor rated cat5, shielded I assume), lightning suppression for the PoE (properly grounded), and ensure the mast is properly grounded. - Get off the 2.4 GHz range. Move up to 5. As for licensed vs. unlicensed, I'm getting mixed input. I'm fairly certain that if the price is right and the frequency is 5GHz+, it won't be a factor. Also, I'll be very glad to separate the bridge from the client access points so that allows for more options. Every solution at this range can easily do 20+ Mbps so throughput is no longer a factor. - Products that support ARQ are highly recommended. - I'm hearing the same products mentioned over and over: - Motorola - Ubiquiti - Aironet (Cisco) - Aruba A number of individuals recommended products from other brands at low cost that meet these mentioned requirements too. I'm not going to bother with a spectrum analyzer. In the current implementation we tried channels 1, 6 and 11 for a few days at a time and found 1 to be the most reliable. Done. At this point an analyzer will tell me what I already suspect: there's a problem. I've researched the Fresnel zones and calculated out a few things with rough numbers and worst case. For one, the Fresnel zone is disrupted most if the obstruction is closer to the endpoints (e.g. antennas). In this case, this is fine as the antenna are mounted at the outermost corner of the buildings as close as possible to the other buildings, approximately 3 floors in the air. Other buildings become a factor near the middle. Based on channel 1's wavelength of 0.12438 m, and assuming 1 km apart (for simplicity sake. It's actually less), the Fresnel zone is largest in the center at approx 5.6 m radius. That could definitely be obstructed by rooftops, I'll have to take another look though. This radius cuts in half when the frequency is doubled, thus more evidence in favour of the 5 GHz+ range. Cool. Or we could just go with a good line of sight optical solution but they look too expensive, and this area can have very unforgiving fog/wind to disrupt things further. What if we tilt each existing antenna up towards the sky 10-20 degrees? Please correct me if I'm wrong. The current antennas are plates. I'm pretty sure they are polarized. I used to have a product sheet on these but a Google search doesn't turn up any useful results anymore (SmartAnt PCW24-03014-BFL). The way they are mounted to the poles might make it difficult to try rotating them 90 degrees, but worth another look. The coax between the AP and antennas are no longer than 30 feet. I've often wondered if a Pringle or Coffee Cantenna would work better than these! For right now I'll have the coax line and ends inspected for damage/softspots, check the grounding, and cover/re-cover the ends in large amounts of rubber/electric tape. I think we might try the Ubiquiti Bullet2 for approx $100 per side (PoE supply/lightning suppression, wiring included) and see what happens! If that doesn't work, no major loss and we'll move up to something more serious (the PoE and wiring will already be ready to go). I will have to look into pricing on some of these suggestions and figure out if we should even bother getting a Bullet but instead go straight to a better all-in-one solution. Thank you guys very much for the tips. Feel free to keep them coming! Peter From owen at delong.com Sun Apr 4 20:51:11 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 4 Apr 2010 18:51:11 -0700 Subject: What is "The Internet" TCP/IP or UNIX-to-UNIX ? In-Reply-To: References: <201004040236.o342at51023284@aurora.sol.net> <4BB89C0D.2000007@cox.net> <4BB8B822.20705@cox.net> <1B8F9D77-2C18-4DE3-A814-9A49600308F4@cs.columbia.edu> Message-ID: <7E9CE98A-15FF-45A3-8AF1-F2A17C48DC88@delong.com> On Apr 4, 2010, at 12:18 PM, Steven Bellovin wrote: > > On Apr 4, 2010, at 3:08 16PM, Lyndon Nerenberg wrote: > >>> File transfer wasn't multihop >> >> It was, for at least some versions (V2 and later?), if the intermediate site(s) allowed execution of the uucp command. 25 years on the brain is fuzzy on the details ... > > > You could certainly add uux and uux to the list of legal remote commands, but I confess that my memory is also dim about whether > > uucp file a!b!c > > would be translated automatically. It has indeed been a while... > IIRC, uucp file a!b!c did not work, only uucp file a!b. Email, OTOH, was roughly translated automatically to uucp {qf,df} b!{qf,df} and the other side knew to unpack qf/df and do the right thing. Owen From owen at delong.com Sun Apr 4 20:55:58 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 4 Apr 2010 18:55:58 -0700 Subject: Juniper's artificial feature blocking (was legacy /8) In-Reply-To: References: <1004041933.AA21122@ivan.Harhan.ORG> Message-ID: <70774BB9-7663-4D96-81B6-48392FB582CA@delong.com> On Apr 4, 2010, at 2:07 PM, James Hess wrote: > On Sun, Apr 4, 2010 at 2:33 PM, Michael Sokolov > wrote: >> feature blocking seems to negate that. I mean, how could their >> disabled-until-you-pay blocking of "premium features" be effective if a >> user can get to the underlying Unix OS, shell, file system, processes, > > Probably signed binaries, veriexec with a signature list of allowed > executables, proprietary system daemons, hardware drivers, and > read-only filesystems. Protections may be in hardware, and you do not > have source code. You can in JunOS "start shell user root" as > much as you like and get a root shell on various platforms, but some > functions are limited. > Most of their license keys are implemented as nag-ware. If you don't mind logs full of "Use of this feature requires a license..." messages, then, it's between you and your lawyers as long as you don't get caught. Owen From rubensk at gmail.com Mon Apr 5 12:12:48 2010 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 5 Apr 2010 14:12:48 -0300 Subject: Juniper's artificial feature blocking (was legacy /8) In-Reply-To: <1004041933.AA21122@ivan.Harhan.ORG> References: <1004041933.AA21122@ivan.Harhan.ORG> Message-ID: On Sun, Apr 4, 2010 at 4:33 PM, Michael Sokolov wrote: > Tore Anderson wrote: > >> Juniper. ?If you want to run OSPFv3 on their layer 3 switches, you need >> a quite expensive "advanced" licence. ?OSPFv2, on the other hand, is >> included in the base licence. > > Really? ?My level of respect for Juniper has just dropped a few notches > after reading this NANOG post - I didn't know that they were engaged in > such DRM-like feature blocking practices. > (...) > The reason I ask is because I've been considering building my own PIM > for their J-series, a PIM that would terminate Nokia/Covad's flavor of > SDSL/2B1Q at the physical layer and present an ATM interface to JunOS, > optionally supporting NxSDSL bonding with MLPPPoA. ?I have no love for > routers that aren't 100% FOSS, but I couldn't find any other existing > router platform which could be extended with 3rd-party physical > interface modules, and designing and building my own base router chassis > is not a viable option if I want to actually have something built before > the Sun swells into a red giant and engulfs the Earth. At least for IPv6 features, that feature gap only happens with Juniper EX. All other Juniper gear has, according to them, IPv6 feature parity within all license levels and packages. Rubens From zeusdadog at gmail.com Mon Apr 5 12:29:20 2010 From: zeusdadog at gmail.com (Jay Nakamura) Date: Mon, 5 Apr 2010 13:29:20 -0400 Subject: what about 48 bits? In-Reply-To: <2B39543C-7EF5-48AE-9E54-3E8A0C714204@cs.columbia.edu> References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> <20100405105746.750257bf@opy.nosense.org> <20100405025742.GR75640@gerbil.cluepon.net> <4BB96187.6040703@bogus.com> <2B39543C-7EF5-48AE-9E54-3E8A0C714204@cs.columbia.edu> Message-ID: >> I would have attributed the success of Ethernet to price! >> >> > You've got the causality wrong -- it wasn't cheap, way back when. I remember back in '93~94ish (I think) you could get a off brand 10BT card for less than $100, as oppose to Token Ring which was $300~400. I can't remember anything else that was cheaper back then. If you go back before that, I don't know. -Jay From Valdis.Kletnieks at vt.edu Mon Apr 5 12:43:52 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 05 Apr 2010 13:43:52 -0400 Subject: what about 48 bits? In-Reply-To: Your message of "Mon, 05 Apr 2010 13:29:20 EDT." References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> <20100405105746.750257bf@opy.nosense.org> <20100405025742.GR75640@gerbil.cluepon.net> <4BB96187.6040703@bogus.com> <2B39543C-7EF5-48AE-9E54-3E8A0C714204@cs.columbia.edu> Message-ID: <13353.1270489432@localhost> On Mon, 05 Apr 2010 13:29:20 EDT, Jay Nakamura said: > >> I would have attributed the success of Ethernet to price! > >> > >> > > You've got the causality wrong -- it wasn't cheap, way back when. > > I remember back in '93~94ish (I think) you could get a off brand 10BT > card for less than $100, as oppose to Token Ring which was $300~400. > I can't remember anything else that was cheaper back then. If you go > back before that, I don't know. Steve is talking mid-80s pricing, not mid-90s. By '93 or so, the fact that Ethernet was becoming ubiquitous had already forced the price down. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From smb at cs.columbia.edu Mon Apr 5 12:51:23 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 5 Apr 2010 13:51:23 -0400 Subject: what about 48 bits? In-Reply-To: <13353.1270489432@localhost> References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> <20100405105746.750257bf@opy.nosense.org> <20100405025742.GR75640@gerbil.cluepon.net> <4BB96187.6040703@bogus.com> <2B39543C-7EF5-48AE-9E54-3E8A0C714204@cs.columbia.edu> <13353.1270489432@localhost> Message-ID: <0CEC3B65-F639-4B0D-AC0E-F3AF99779EEB@cs.columbia.edu> On Apr 5, 2010, at 1:43 52PM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 05 Apr 2010 13:29:20 EDT, Jay Nakamura said: >>>> I would have attributed the success of Ethernet to price! >>>> >>>> >>> You've got the causality wrong -- it wasn't cheap, way back when. >> >> I remember back in '93~94ish (I think) you could get a off brand 10BT >> card for less than $100, as oppose to Token Ring which was $300~400. >> I can't remember anything else that was cheaper back then. If you go >> back before that, I don't know. > > Steve is talking mid-80s pricing, not mid-90s. By '93 or so, the fact > that Ethernet was becoming ubiquitous had already forced the price down. Yup. 10 years earlier, a 3Com Ethernet card for a Vax cost about $1500, if memory serves. --Steve Bellovin, http://www.cs.columbia.edu/~smb From bclark at spectraaccess.com Mon Apr 5 13:01:58 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Mon, 05 Apr 2010 14:01:58 -0400 Subject: Wireless bridge In-Reply-To: <07d901cad4df$934e7af0$b9eb70d0$@com> References: <005c01c9f015$852ae490$8f80adb0$@com> <877585b00906180753s47617a64la780d7ac1f8c05ca@mail.gmail.com> <09ef01c9f02d$221f21f0$665d65d0$@com> <1245341463.1310.22.camel@legolas.orthanc.ca> <0e9401c9f033$24f4a160$6edde420$@com> <23ab01c9f07f$b7aa6480$26ff2d80$@com> <07d901cad4df$934e7af0$b9eb70d0$@com> Message-ID: <4BBA2596.9070505@spectraaccess.com> Peter Boone wrote: I purchased 2x Ubiquity Bullet2's (2.4 GHz) and utilized our existing antennas. It has been working extremely well, pushing a stable 54 Mbps over the link without issue. Signal strength is consistently -40 dBm +/- 2 dBm, from about -80 dBm before! Total cost included 2x Bullets, 2x PoE adaptors, and approx 40 ft of STP cat5: $120. I have yet to see what happens in a big thunderstorm, but I extrapolate that they will be able to handle the EMP without going haywire like before. They have worked very well through conditions that our last setup would not. Thanks again for the input everyone! Peter More an FYI as I'm not overly familiar with Ubiquity's, but I believe -40dBm is kind of a hot signal which means they are screaming at each other, are you seeing any physical errors, specifically CRC's?. Won't necessarily affect overall throughput, but -60dBm is the sweet spot...too much of a signal is just as bad as not enough...sort of like that Sienfield episode of the the close talker :). Bret From leo.vegoda at icann.org Mon Apr 5 13:04:07 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 5 Apr 2010 11:04:07 -0700 Subject: interop show network (was: legacy /8) In-Reply-To: References: Message-ID: <11C01471-4245-4D1D-8628-A9F8C7203E92@icann.org> On 5 Apr 2010, at 9:13, Jon Lewis wrote: > On Sun, 4 Apr 2010, Christopher Morrow wrote: [...] > If we could recover them all, how many more years of IPv4 allocations > would that buy us? We allocate RIRs approximately one /8 per month. So you'd have to reclaim 12 /8s to extend the allocation pool by one year. Regards, Leo From nick at foobar.org Mon Apr 5 13:34:29 2010 From: nick at foobar.org (Nick Hilliard) Date: Mon, 05 Apr 2010 19:34:29 +0100 Subject: what about 48 bits? In-Reply-To: <0CEC3B65-F639-4B0D-AC0E-F3AF99779EEB@cs.columbia.edu> References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> <20100405105746.750257bf@opy.nosense.org> <20100405025742.GR75640@gerbil.cluepon.net> <4BB96187.6040703@bogus.com> <2B39543C-7EF5-48AE-9E54-3E8A0C714204@cs.columbia.edu> <13353.1270489432@localhost> <0CEC3B65-F639-4B0D-AC0E-F3AF99779EEB@cs.columbia.edu> Message-ID: <4BBA2D35.6070805@foobar.org> On 05/04/2010 18:51, Steven Bellovin wrote: > Yup. 10 years earlier, a 3Com Ethernet card for a Vax cost about $1500, if memory serves. To be fair, everything for a vax was somewhat pricey. And slow. On an even more unrelated note, does anyone remember the day that CMU-TEK tcp/ip stopped working some time in the early 1990s? That was a load of fun. Nick From karim.adel at gmail.com Mon Apr 5 14:48:33 2010 From: karim.adel at gmail.com (Kasper Adel) Date: Mon, 5 Apr 2010 21:48:33 +0200 Subject: Common statistics from your NOC Message-ID: Hello, I want to collect experience from the Gurus on this mailer on how they make use of the data they can get from NOC. what i mean by data, trouble tickets opened internally or with vendors. I wonder what would be common or even uncommon type of statistics that a network operator would like to poll from their NOC to help them in: 1) Optimizing and tuning operations 2) Optimizing and tuning engineering Example on point 1: If we were to put all tickets in an excel sheet and take a holistic look at the type of technology or product, we can see that out of 100 incidents, there were 50 cases related to routing protocols, this would yield that either more training is needed for operations team or that the design is flawed. Example on point 2: 20 incidents appeared to be related to new configuration lines that when added, a conflict was seen, so the take away would be that engineering needs a lab. Excuse my poor English, unicast replies are welcomed. Regards, Kim From mike-nanog at tiedyenetworks.com Mon Apr 5 15:01:33 2010 From: mike-nanog at tiedyenetworks.com (Mike) Date: Mon, 05 Apr 2010 13:01:33 -0700 Subject: Wireless bridge In-Reply-To: <4BBA2596.9070505@spectraaccess.com> References: <005c01c9f015$852ae490$8f80adb0$@com> <877585b00906180753s47617a64la780d7ac1f8c05ca@mail.gmail.com> <09ef01c9f02d$221f21f0$665d65d0$@com> <1245341463.1310.22.camel@legolas.orthanc.ca> <0e9401c9f033$24f4a160$6edde420$@com> <23ab01c9f07f$b7aa6480$26ff2d80$@com> <07d901cad4df$934e7af0$b9eb70d0$@com> <4BBA2596.9070505@spectraaccess.com> Message-ID: <4BBA419D.6060809@tiedyenetworks.com> No, you are not pushing a stable '54mbps over the link without issue'. More likely, if you cared to look, you are getting somewhere around 30-35mbps, HALF DUPLEX. The '54mbps' advertised on the shiny sales brochure, is a signaling rate and not a measure of thruput. Mike- Bret Clark wrote: > Peter Boone wrote: > > > I purchased 2x Ubiquity Bullet2's (2.4 GHz) and utilized our existing > antennas. It has been working extremely well, pushing a stable 54 Mbps over > the link without issue. Signal strength is consistently -40 dBm +/- 2 dBm, > from about -80 dBm before! Total cost included 2x Bullets, 2x PoE adaptors, > and approx 40 ft of STP cat5: $120. I have yet to see what happens in a big > thunderstorm, but I extrapolate that they will be able to handle the EMP > without going haywire like before. They have worked very well through > conditions that our last setup would not. > > Thanks again for the input everyone! > > Peter > > More an FYI as I'm not overly familiar with Ubiquity's, but I believe > -40dBm is kind of a hot signal which means they are screaming at each > other, are you seeing any physical errors, specifically CRC's?. Won't > necessarily affect overall throughput, but -60dBm is the sweet > spot...too much of a signal is just as bad as not enough...sort of like > that Sienfield episode of the the close talker :). > Bret > From jlewis at lewis.org Mon Apr 5 15:36:26 2010 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 5 Apr 2010 16:36:26 -0400 (EDT) Subject: what about 48 bits? In-Reply-To: References: Message-ID: On Sun, 4 Apr 2010, A.B. Jr. wrote: > Hi, > > Lots of traffic recently about 64 bits being too short or too long. > > What about mac addresses? Aren't they close to exhaustion? Should be. Or it > is assumed that mac addresses are being widely reused throughout the world? > All those low cost switches and wifi adapters DO use unique mac addresses? Since they only really need to be unique per broadcast domain, it doesn't really matter. You can I could use the same MAC addresses on all our home gear, and never know it. For manufacturers, it's probably reasonably safe to reuse MAC addresses they put on 10mbit ISA ethernet cards...if they were a manufacturer back then. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bzs at world.std.com Mon Apr 5 15:58:59 2010 From: bzs at world.std.com (Barry Shein) Date: Mon, 5 Apr 2010 16:58:59 -0400 Subject: what about 48 bits? In-Reply-To: <0CEC3B65-F639-4B0D-AC0E-F3AF99779EEB@cs.columbia.edu> References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> <20100405105746.750257bf@opy.nosense.org> <20100405025742.GR75640@gerbil.cluepon.net> <4BB96187.6040703@bogus.com> <2B39543C-7EF5-48AE-9E54-3E8A0C714204@cs.columbia.edu> <13353.1270489432@localhost> <0CEC3B65-F639-4B0D-AC0E-F3AF99779EEB@cs.columbia.edu> Message-ID: <19386.20243.22301.173990@world.std.com> On April 5, 2010 at 13:51 smb at cs.columbia.edu (Steven Bellovin) wrote: > > Yup. 10 years earlier, a 3Com Ethernet card for a Vax cost about $1500, if memory serves. Early-mid 80s? I'd say at least twice that, I don't think there were too many cards for Vaxes and similar for less than $5K. An NIU20 for DECSYSTEM-20 was a 3U box, it was just a single ethernet interface, and cost around $15-20K. About the same price for an IBM370 (specifically, 3090) ethernet box which included a PC/AT and sat on a box about the size of a dorm cube refrigerator which, if you opened it up, contained a chunk of Unibus backplane in which was a (I think 3COM?) ethernet board (and power supply etc.), some common Vax ethernet card. Weird, the whole thing was basically a kludged together Unibus to bus/tag channel adapter or maybe even 3274 using something like an IRMA board? I knew it well because it crashed a lot and operations decided I was the only one who had the magic voodoo to bring it back to life which as I remember was to POWER-CYCLE IT! Well, sometimes you had to power-cycle it more than once to get it all to synch. And we had to put coins in those boxes to get our packets through! If you wanted an email it cost a dime, FTP was 75cents for the first 100KB and 10c for each KB thereafter...ok, that may not be entirely accurate. -b From smb at cs.columbia.edu Mon Apr 5 16:02:39 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 5 Apr 2010 17:02:39 -0400 Subject: what about 48 bits? In-Reply-To: <19386.20243.22301.173990@world.std.com> References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> <20100405105746.750257bf@opy.nosense.org> <20100405025742.GR75640@gerbil.cluepon.net> <4BB96187.6040703@bogus.com> <2B39543C-7EF5-48AE-9E54-3E8A0C714204@cs.columbia.edu> <13353.1270489432@localhost> <0CEC3B65-F639-4B0D-AC0E-F3AF99779EEB@cs.columbia.edu> <19386.20243.22301.173990@world.std.com> Message-ID: <2EC1881D-7AE2-462E-81EC-F8ADBEEFA177@cs.columbia.edu> On Apr 5, 2010, at 4:58 59PM, Barry Shein wrote: > > On April 5, 2010 at 13:51 smb at cs.columbia.edu (Steven Bellovin) wrote: >> >> Yup. 10 years earlier, a 3Com Ethernet card for a Vax cost about $1500, if memory serves. > > Early-mid 80s? I'd say at least twice that, I don't think there were > too many cards for Vaxes and similar for less than $5K. It could have been $3K, but I don't think it was higher. > > An NIU20 for DECSYSTEM-20 was a 3U box, it was just a single ethernet > interface, and cost around $15-20K. > > About the same price for an IBM370 (specifically, 3090) ethernet box > which included a PC/AT and sat on a box about the size of a dorm cube > refrigerator which, if you opened it up, contained a chunk of Unibus > backplane in which was a (I think 3COM?) ethernet board (and power > supply etc.), some common Vax ethernet card. Weird, the whole thing > was basically a kludged together Unibus to bus/tag channel adapter or > maybe even 3274 using something like an IRMA board? I knew it well > because it crashed a lot and operations decided I was the only one who > had the magic voodoo to bring it back to life which as I remember was > to POWER-CYCLE IT! Well, sometimes you had to power-cycle it more than > once to get it all to synch. I remember the design, but never used it. > > And we had to put coins in those boxes to get our packets through! If > you wanted an email it cost a dime, FTP was 75cents for the first > 100KB and 10c for each KB thereafter...ok, that may not be entirely > accurate. > Of course not -- you forgot about the credit card reader option. --Steve Bellovin, http://www.cs.columbia.edu/~smb From Valdis.Kletnieks at vt.edu Mon Apr 5 16:08:23 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 05 Apr 2010 17:08:23 -0400 Subject: what about 48 bits? In-Reply-To: Your message of "Mon, 05 Apr 2010 16:36:26 EDT." References: Message-ID: <22710.1270501703@localhost> On Mon, 05 Apr 2010 16:36:26 EDT, Jon Lewis said: > Since they only really need to be unique per broadcast domain, it doesn't > really matter. You can I could use the same MAC addresses on all our home > gear, and never know it. For manufacturers, it's probably reasonably safe > to reuse MAC addresses they put on 10mbit ISA ethernet cards...if they > were a manufacturer back then. Until you buy 25 cards with the same MAC address and deploy them all across your enterprise - the problem can go un-noticed for *weeks* as long as two boxes aren't squawking on the same subnet at the same time(*). Of course, you never stop to actually *check* that two cards in different machines have the same address, because That Never Happens, and you spin your wheels trying to figure out why your switching gear is confused about the MAC addresses it's seeing (and it always takes 3 or 4 tickets before one actually includes the message "Duplicate MAC address detected" in the problem report..) (*) And as Murphy predicts, whenever it happens, one of the two offenders will give up in disgust, power off the machine, and go on coffee break so the arp cache has timed out by the time you start trying to work the trouble ticket. ;) (Yes, we're mostly older and wiser now, and more willing to include "the damned hardware is posessed by an Imp of Perversity" in our troubleshooting analysis. Had an SL8500 tape library last week that reported 'Drive State: Unpowered' and 'Drive Status: Not Communicating' and still reported 'Drive Health: Good'. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nonobvious at gmail.com Mon Apr 5 16:10:07 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Mon, 5 Apr 2010 14:10:07 -0700 Subject: what about 48 bits? In-Reply-To: <0CEC3B65-F639-4B0D-AC0E-F3AF99779EEB@cs.columbia.edu> References: <20100405105746.750257bf@opy.nosense.org> <20100405025742.GR75640@gerbil.cluepon.net> <4BB96187.6040703@bogus.com> <2B39543C-7EF5-48AE-9E54-3E8A0C714204@cs.columbia.edu> <13353.1270489432@localhost> <0CEC3B65-F639-4B0D-AC0E-F3AF99779EEB@cs.columbia.edu> Message-ID: On Mon, Apr 5, 2010 at 10:51 AM, Steven Bellovin wrote: > On Apr 5, 2010, at 1:43 52PM, Valdis.Kletnieks at vt.edu wrote: >> Steve is talking mid-80s pricing, not mid-90s. ?By '93 or so, the fact >> that Ethernet was becoming ubiquitous had already forced the price down. > > Yup. ?10 years earlier, a 3Com Ethernet card for a Vax cost about $1500, if memory serves. $1500 is what I remember also (forget if that was the Interlan NI1010 or the DEUNA / DELUA), plus of course the cost of whatever Unibus you're burning the bandwidth on. Serial was cheaper, but most of the competition wasn't. I assume Datakit boards had a regular list price for customers other than intra-Bell? -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From patrick at ianai.net Mon Apr 5 16:26:53 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 5 Apr 2010 17:26:53 -0400 Subject: what about 48 bits? In-Reply-To: <22710.1270501703@localhost> References: <22710.1270501703@localhost> Message-ID: On Apr 5, 2010, at 5:08 PM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 05 Apr 2010 16:36:26 EDT, Jon Lewis said: > >> Since they only really need to be unique per broadcast domain, it doesn't >> really matter. You can I could use the same MAC addresses on all our home >> gear, and never know it. For manufacturers, it's probably reasonably safe >> to reuse MAC addresses they put on 10mbit ISA ethernet cards...if they >> were a manufacturer back then. > > Until you buy 25 cards with the same MAC address and deploy them all across > your enterprise I don't think that's possible given that Jon was suggesting. I'm 3COM, I made ISA 10Base2 / 10Base5 cards in the 90s. I run out of MAC addresses. Instead of going to get more - if I even can! - I recycle those MAC addresses, figuring the 10GE PCI-X cards I'm making now have 0.000% chance of being on the same b-cast domain as one of those old ISA cards. Even if I am wrong, the max collision possibility is 2, not 25. Seems reasonable. If I am wrong, I'll apologize profusely, refund the price of the 10G card I gave the customer, ship him a new one free, so he gets two he can use (assuming he has more than one b-cast domain), which would probably make the customer happy. Wanna bet how many times 3COM would have to ship free 10GE cards? -- TTFN, patrick > - the problem can go un-noticed for *weeks* as long as two > boxes aren't squawking on the same subnet at the same time(*). Of course, you > never stop to actually *check* that two cards in different machines have the > same address, because That Never Happens, and you spin your wheels trying to > figure out why your switching gear is confused about the MAC addresses it's > seeing (and it always takes 3 or 4 tickets before one actually includes the > message "Duplicate MAC address detected" in the problem report..) > > (*) And as Murphy predicts, whenever it happens, one of the two offenders will > give up in disgust, power off the machine, and go on coffee break so the arp > cache has timed out by the time you start trying to work the trouble ticket. ;) > > (Yes, we're mostly older and wiser now, and more willing to include "the damned > hardware is posessed by an Imp of Perversity" in our troubleshooting analysis. > Had an SL8500 tape library last week that reported 'Drive State: Unpowered' and > 'Drive Status: Not Communicating' and still reported 'Drive Health: Good'. > From Valdis.Kletnieks at vt.edu Mon Apr 5 16:53:25 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 05 Apr 2010 17:53:25 -0400 Subject: what about 48 bits? In-Reply-To: Your message of "Mon, 05 Apr 2010 17:26:53 EDT." References: <22710.1270501703@localhost> Message-ID: <24733.1270504405@localhost> On Mon, 05 Apr 2010 17:26:53 EDT, "Patrick W. Gilmore" said: > I'm 3COM, I made ISA 10Base2 / 10Base5 cards in the 90s. I run out of > MAC addresses. Instead of going to get more - if I even can! - I > recycle those MAC addresses There were several cases of production run errors from multiple vendors, where the MAC address went 14, 15, 16, 17, 17, 17, 17, *thwack*, 18, 19.... -------------- 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 Apr 5 17:40:14 2010 From: franck at genius.com (Franck Martin) Date: Tue, 6 Apr 2010 10:40:14 +1200 (FJT) Subject: what about 48 bits? In-Reply-To: <6663229.798.1270505936926.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <22010447.800.1270507210631.JavaMail.franck@franck-martins-macbook-pro.local> ----- "Valdis Kletnieks" wrote: > On Mon, 05 Apr 2010 17:26:53 EDT, "Patrick W. Gilmore" said: > > I'm 3COM, I made ISA 10Base2 / 10Base5 cards in the 90s. I run out > of > > MAC addresses. Instead of going to get more - if I even can! - I > > recycle those MAC addresses > > There were several cases of production run errors from multiple > vendors, > where the MAC address went 14, 15, 16, 17, 17, 17, 17, *thwack*, 18, > 19.... And to make the problem worse, they are likely to end up in the same shop, and you get them when you purchase several of them. From NANOG at Aquillar.com Mon Apr 5 17:41:40 2010 From: NANOG at Aquillar.com (Peter Boone) Date: Mon, 5 Apr 2010 18:41:40 -0400 Subject: Wireless bridge In-Reply-To: <4BBA419D.6060809@tiedyenetworks.com> References: <005c01c9f015$852ae490$8f80adb0$@com> <877585b00906180753s47617a64la780d7ac1f8c05ca@mail.gmail.com> <09ef01c9f02d$221f21f0$665d65d0$@com> <1245341463.1310.22.camel@legolas.orthanc.ca> <0e9401c9f033$24f4a160$6edde420$@com> <23ab01c9f07f$b7aa6480$26ff2d80$@com> <07d901cad4df$934e7af0$b9eb70d0$@com> <4BBA2596.9070505@spectraaccess.com> <4BBA419D.6060809@tiedyenetworks.com> Message-ID: <081c01cad511$296e8670$7c4b9350$@com> Hi Mike, Sorry for the misunderstanding, allow me to paraphrase: the link does not drop, actual throughput is now faster than our internet connection, and transfers have not been interrupted, so we are happy. As I mentioned, our previous setup could only work reliably when locked at 6 Mbps, and even then there were interruptions and mysterious downtime, so a 54 Mbps theoretical max rate has been a godsend. Also, there were no "shiny sales brochures" involved in the decision, the Bullet2's were the most cost-effective solution to get the job done, and at minimal loss if the odd problems were not actually solved (see the archive of this thread from June 2009 for details). Bret, You are correct, the Bullets are on max output power right now so they are loud, and I just found that Ubiquiti recommends aiming for -50 to -70 dBm "for stable links". I always looked at the hot signal issue like a bad quality speaker turned up too loud; where in this case the speaker is the wireless radio. Since there have been no wireless errors and (aside from a small number of expected Invalid Network ID errors) and the dBm is high I figure the signal is loud and clear on each end, but I'll be sure to tweak the power output. There have actually been more error packets on the wire than in the air (0.000001% of LAN packets). Regards, Peter -----Original Message----- From: Mike [mailto:mike-nanog at tiedyenetworks.com] Sent: April-05-10 4:02 PM To: Bret Clark Cc: nanog at nanog.org Subject: Re: Wireless bridge No, you are not pushing a stable '54mbps over the link without issue'. More likely, if you cared to look, you are getting somewhere around 30-35mbps, HALF DUPLEX. The '54mbps' advertised on the shiny sales brochure, is a signaling rate and not a measure of thruput. Mike- Bret Clark wrote: > Peter Boone wrote: > > > I purchased 2x Ubiquity Bullet2's (2.4 GHz) and utilized our existing > antennas. It has been working extremely well, pushing a stable 54 Mbps over > the link without issue. Signal strength is consistently -40 dBm +/- 2 dBm, > from about -80 dBm before! Total cost included 2x Bullets, 2x PoE adaptors, > and approx 40 ft of STP cat5: $120. I have yet to see what happens in a big > thunderstorm, but I extrapolate that they will be able to handle the EMP > without going haywire like before. They have worked very well through > conditions that our last setup would not. > > Thanks again for the input everyone! > > Peter > > More an FYI as I'm not overly familiar with Ubiquity's, but I believe > -40dBm is kind of a hot signal which means they are screaming at each > other, are you seeing any physical errors, specifically CRC's?. Won't > necessarily affect overall throughput, but -60dBm is the sweet > spot...too much of a signal is just as bad as not enough...sort of like > that Sienfield episode of the the close talker :). > Bret > From steve at ibctech.ca Mon Apr 5 17:49:17 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 05 Apr 2010 18:49:17 -0400 Subject: legacy /8 In-Reply-To: <4BB9E390.8070202@ibctech.ca> References: <4BB65B39.8010902@mompl.net> <20100402210631.GA21373@puck.nether.net> <9D78CBC7F28F40C5AF04DD2C8A40B25B@TAKA> <20100402225241.GD21373@puck.nether.net> <502AB654CA724523B8B377300EBE11A0@TAKA> <4BB9E390.8070202@ibctech.ca> Message-ID: <4BBA68ED.6020505@ibctech.ca> On 2010.04.05 09:20, Steve Bertrand wrote: > On 2010.04.02 19:29, John Palmer (NANOG Acct) wrote: >> Was looking for the "allocated" file on the ARIN website, but can't >> remember >> where it is. They used to have a file with one line per allocation that >> started >> like this "arin|US|ipv4". Is that still public somewhere? > > If you are looking for what blocks have been allocated to ARIN by IANA, > the file is maintained on the IANA site: > > http://www.iana.org/assignments/ipv4-address-space/ After digging a little bit more, and to further my own post, ARIN does maintain a list within its website that contains its IANA allocated blocks for both IPv4 and IPv6: https://www.arin.net/knowledge/ip_blocks.html After a quick review, it seems as though there are numerous blocks left out of this list when comparing it to the aforementioned IANA list. Perhaps it is due to certain blocks being legacy (?). If ARIN does have a single text file, I haven't found it. Should be trivial to copy/dump though. Steve From LarrySheldon at cox.net Mon Apr 5 18:28:09 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 05 Apr 2010 18:28:09 -0500 Subject: what about 48 bits? In-Reply-To: References: Message-ID: <4BBA7209.5070008@cox.net> On 4/5/2010 15:36, Jon Lewis wrote: > On Sun, 4 Apr 2010, A.B. Jr. wrote: > >> Hi, >> >> Lots of traffic recently about 64 bits being too short or too long. >> >> What about mac addresses? Aren't they close to exhaustion? Should be. Or it >> is assumed that mac addresses are being widely reused throughout the world? >> All those low cost switches and wifi adapters DO use unique mac addresses? > > Since they only really need to be unique per broadcast domain, it doesn't > really matter. You can I could use the same MAC addresses on all our home > gear, and never know it. For manufacturers, it's probably reasonably safe > to reuse MAC addresses they put on 10mbit ISA ethernet cards...if they > were a manufacturer back then. Seems like they have be unique within a DHCP "domain". And you'd have to pretty much outlaw mobiles. Wouldn't you? (Is there an accepted bit of nomenclature for all of the networks that forward DHCP traffic to a given cluster of servers?) -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From joelja at bogus.com Mon Apr 5 23:56:55 2010 From: joelja at bogus.com (joel jaeggli) Date: Tue, 06 Apr 2010 00:56:55 -0400 Subject: what about 48 bits? In-Reply-To: References: <22710.1270501703@localhost> Message-ID: <4BBABF17.1030007@bogus.com> On 4/5/2010 5:26 PM, Patrick W. Gilmore wrote: > On Apr 5, 2010, at 5:08 PM, Valdis.Kletnieks at vt.edu wrote: >> On Mon, 05 Apr 2010 16:36:26 EDT, Jon Lewis said: >> >>> Since they only really need to be unique per broadcast domain, it >>> doesn't really matter. You can I could use the same MAC >>> addresses on all our home gear, and never know it. For >>> manufacturers, it's probably reasonably safe to reuse MAC >>> addresses they put on 10mbit ISA ethernet cards...if they were a >>> manufacturer back then. >> >> Until you buy 25 cards with the same MAC address and deploy them >> all across your enterprise > > I don't think that's possible given that Jon was suggesting. > > I'm 3COM, I made ISA 10Base2 / 10Base5 cards in the 90s. I run out > of MAC addresses. Instead of going to get more - if I even can! - I > recycle those MAC addresses, figuring the 10GE PCI-X cards I'm making > now have 0.000% chance of being on the same b-cast domain as one of > those old ISA cards. > > Even if I am wrong, the max collision possibility is 2, not 25. > > Seems reasonable. If I am wrong, I'll apologize profusely, refund > the price of the 10G card I gave the customer, ship him a new one > free, so he gets two he can use (assuming he has more than one b-cast > domain), which would probably make the customer happy. Wanna bet how > many times 3COM would have to ship free 10GE cards? 3com is now HP and i doubt very much that either company would bother with that approach... That said, the volume production run for a circa 1992 isa bus ethernet nic (or the enitre sun microsystems product line for that matter) is propably two orders of magnitude lower than say the minimum volume production of mini-pci-express wireless card that goes into a laptop, and laptops might have two or three mac addresses. From ssrigha at gmail.com Tue Apr 6 02:20:26 2010 From: ssrigha at gmail.com (shake righa) Date: Tue, 6 Apr 2010 10:20:26 +0300 Subject: IPv6 Newbie Message-ID: I have several queries in regards to ipv6 different documentation state that clients be given /64 with ISP's beign given /48 from assigned global /32. Can one subnet to include /127 for point to point connections? Is there any newbie guide for ipv6 subnetting? Regards, Shake From wavetossed at googlemail.com Tue Apr 6 02:44:52 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Tue, 6 Apr 2010 08:44:52 +0100 Subject: IPv6 Newbie In-Reply-To: References: Message-ID: > different documentation state that clients be given /64 with ISP's beign > given /48 from assigned global /32. That should be that ISPs are given a global /32 from which they assign /48s to clients. The client would assign a /64 to each LAN segment. > Can one subnet to include /127 for point to point connections? The best advice is to use a /64 unless you have read and understood RFC 3627 http://tools.ietf.org/html/rfc3627 > Is there any newbie guide for ipv6 subnetting? http://www.getipv6.info/index.php/IPv6_Addressing_Plans --Michael Dillon From ssrigha at gmail.com Tue Apr 6 02:54:06 2010 From: ssrigha at gmail.com (shake righa) Date: Tue, 6 Apr 2010 10:54:06 +0300 Subject: IPv6 Newbie In-Reply-To: References: Message-ID: Thanks On Tue, Apr 6, 2010 at 10:44 AM, Michael Dillon wrote: > > different documentation state that clients be given /64 with ISP's beign > > given /48 from assigned global /32. > > That should be that ISPs are given a global /32 from which they > assign /48s to clients. The client would assign a /64 to each LAN segment. > > > Can one subnet to include /127 for point to point connections? > > The best advice is to use a /64 unless you have read and understood > RFC 3627 http://tools.ietf.org/html/rfc3627 > > > Is there any newbie guide for ipv6 subnetting? > > http://www.getipv6.info/index.php/IPv6_Addressing_Plans > > --Michael Dillon > From sthaug at nethelp.no Tue Apr 6 02:57:41 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 06 Apr 2010 09:57:41 +0200 (CEST) Subject: IPv6 Newbie In-Reply-To: References: Message-ID: <20100406.095741.74713545.sthaug@nethelp.no> > > Can one subnet to include /127 for point to point connections? > > The best advice is to use a /64 unless you have read and understood > RFC 3627 http://tools.ietf.org/html/rfc3627 RFC 3627 *and* the following Internet draft: http://tools.ietf.org/search/draft-kohno-ipv6-prefixlen-p2p-01 The problem with ping-pong on point to point links is real. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From ljakab at ac.upc.edu Tue Apr 6 03:03:04 2010 From: ljakab at ac.upc.edu (Lorand Jakab) Date: Tue, 06 Apr 2010 10:03:04 +0200 Subject: IPv6 Newbie In-Reply-To: References: Message-ID: <4BBAEAB8.5050908@ac.upc.edu> On 04/06/10 09:20, shake righa wrote: > Can one subnet to include /127 for point to point connections? > There was a recent thread here on this topic, see http://www.merit.edu/mail.archives/nanog/msg04500.html Lorand Jakab -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From tim at pelican.org Tue Apr 6 04:08:34 2010 From: tim at pelican.org (Tim Franklin) Date: Tue, 6 Apr 2010 09:08:34 +0000 (GMT) Subject: As the "NANOG Community" Moves to IPv6... In-Reply-To: <8363278.01270544775332.JavaMail.root@jennyfur.pelican.org> Message-ID: <4848122.21270544914951.JavaMail.root@jennyfur.pelican.org> > P.S. Does anyone else think that perhaps "ipv3.com" == "Guillaume > FORTAINE"? It's spewing semi-coherent proposals for unworkable alternative addressing schemes. Sounds more like Jim Fleming to me. Perhaps we start comparing IPv3 to IPv8 and see if we get a reaction? ;) Regards, Tim. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Apr 6 04:47:01 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Tue, 6 Apr 2010 19:17:01 +0930 Subject: IPv6 Newbie In-Reply-To: <20100406.095741.74713545.sthaug@nethelp.no> References: <20100406.095741.74713545.sthaug@nethelp.no> Message-ID: <20100406191701.443d1548@opy.nosense.org> On Tue, 06 Apr 2010 09:57:41 +0200 (CEST) sthaug at nethelp.no wrote: > > > Can one subnet to include /127 for point to point connections? > > > > The best advice is to use a /64 unless you have read and understood > > RFC 3627 http://tools.ietf.org/html/rfc3627 > > RFC 3627 *and* the following Internet draft: > > http://tools.ietf.org/search/draft-kohno-ipv6-prefixlen-p2p-01 > > The problem with ping-pong on point to point links is real. > Only if you disable Neighbor Discovery. > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > From shoshon at shoshon.ro Tue Apr 6 07:18:37 2010 From: shoshon at shoshon.ro (Bogdan) Date: Tue, 06 Apr 2010 15:18:37 +0300 Subject: cisco snmptrapd Message-ID: <4BBB269D.7050703@shoshon.ro> hello does anyone have a working configuration regarding cisco sending snmp traps on tcn ? i mean the actual info that i am seeing in the sh span vlan xx detail which is like this: Number of topology changes 15 last change occurred 00:22:27 ago from GigabitEthernet0/32 i have configured the mibs from cisco, i can receive other useful info (interface up/down is working ok) but on snmp-server enable traps bridge, when i generate a tcn i receive: Subject: trap received from : SNMPv2-SMI::mib-2.17.0.2 Host: (UDP: [10.255.10.222]:64858) DISMAN-EVENT-MIB::sysUpTimeInstance 0:3:55:38.13 SNMPv2-MIB::snmpTrapOID.0 SNMPv2-SMI::mib-2.17.0.2 SNMPv2-SMI::enterprises.9.9.82.1.11.4.1.1.1 1 IF-MIB::ifName.10132 Gi0/32 Host: (UDP: [10.255.10.222]:64858) DISMAN-EVENT-MIB::sysUpTimeInstance 0:3:55:38.14 SNMPv2-MIB::snmpTrapOID.0 SNMPv2-SMI::mib-2.17.0.2 SNMPv2-SMI::enterprises.9.9.82.1.11.4.1.1.0 0 IF-MIB::ifName.10132 Gi0/32 the test switch is 3560G and the i use snmptrapd from a fedora thanks Bogdan From patrick at ianai.net Tue Apr 6 10:30:16 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 6 Apr 2010 11:30:16 -0400 Subject: FCC dealt major blow in net neutrality ruling favoring Comcast Message-ID: <42DF9B4B-8614-43F9-802D-9586AA7AD0FB@ianai.net> Seems on-topic, even though policy related. -- TTFN, patrick From tme at americafree.tv Tue Apr 6 10:49:44 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 6 Apr 2010 11:49:44 -0400 Subject: Comcast wins Web traffic court fight against FCC Message-ID: <7D559319-D294-41AA-9A8E-F0F7809DFADF@americafree.tv> This seems relevant. Decided April 6, 2010 Because the Commission has failed to tie its assertion of ancillary authority over Comcast's Internet service to any "statutorily mandated responsibility," Am. Library, 406 F.3d at 692, we grant the petition for review and vacate the Order. So ordered. Court decision here : http://pacer.cadc.uscourts.gov/common/opinions/201004/08-1291-1238302.pdf Analysis http://www.reuters.com/article/idUSN0622428720100406 Regards Marshall From sthaug at nethelp.no Tue Apr 6 10:54:17 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 06 Apr 2010 17:54:17 +0200 (CEST) Subject: IPv6 Newbie In-Reply-To: <20100406191701.443d1548@opy.nosense.org> References: <20100406.095741.74713545.sthaug@nethelp.no> <20100406191701.443d1548@opy.nosense.org> Message-ID: <20100406.175417.74715766.sthaug@nethelp.no> > > > > Can one subnet to include /127 for point to point connections? > > > > > > The best advice is to use a /64 unless you have read and understood > > > RFC 3627 http://tools.ietf.org/html/rfc3627 > > > > RFC 3627 *and* the following Internet draft: > > > > http://tools.ietf.org/search/draft-kohno-ipv6-prefixlen-p2p-01 > > > > The problem with ping-pong on point to point links is real. > > Only if you disable Neighbor Discovery. You don't have to disable it. "Small, unknown" vendors like Cisco and Juniper have IPv6 ND disabled on point to point links, and (at least for Juniper) there is no option to turn it on. The problem with ping-pong on point to point links is still very real. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From rs at seastrom.com Tue Apr 6 11:01:47 2010 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 06 Apr 2010 12:01:47 -0400 Subject: interop show network (was: legacy /8) In-Reply-To: (Christopher Morrow's message of "Sun, 4 Apr 2010 21:24:26 -0700") References: Message-ID: <86r5mswowk.fsf@seastrom.com> Christopher Morrow writes: > also, see previous 12 episodes of this conversation.. 1 /8 == ~3months > in ARIN allocation timeframes. 1 /8 at global IANA free pool runout time (which is the only reasonable way to think about it...) will buy us about 24 days on a global consumption basis... assuming there isn't an end times land rush. -r From bmanning at vacation.karoshi.com Tue Apr 6 11:08:41 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 6 Apr 2010 16:08:41 +0000 Subject: interop show network (was: legacy /8) In-Reply-To: <86r5mswowk.fsf@seastrom.com> References: <86r5mswowk.fsf@seastrom.com> Message-ID: <20100406160841.GC12993@vacation.karoshi.com.> On Tue, Apr 06, 2010 at 12:01:47PM -0400, Robert E. Seastrom wrote: > > Christopher Morrow writes: > > > also, see previous 12 episodes of this conversation.. 1 /8 == ~3months > > in ARIN allocation timeframes. > > 1 /8 at global IANA free pool runout time (which is the only > reasonable way to think about it...) will buy us about 24 days on a > global consumption basis... assuming there isn't an end times land > rush. > > -r > so... just for grins, how do all those w/ bits leftover from their "overly generous" inital allocations (they forced me to take a /20 when all i really needed was a /28 multihomed) find partners who are willing to use the rest of those bits to get the delegation in question up to a comfortable 85% utilization? are you and Marty going to open up a matching service? co-op "match.com" or "e-harmony"? craigslist? --bill From marty.anstey at sunwave.net Tue Apr 6 12:17:21 2010 From: marty.anstey at sunwave.net (Marty Anstey) Date: Tue, 06 Apr 2010 10:17:21 -0700 Subject: Books for the NOC guys... In-Reply-To: <4BB62CC1.3010204@foobar.org> References: <86wrwqukcm.fsf@seastrom.com> <28028.1270215582@localhost> <4BB62CC1.3010204@foobar.org> Message-ID: <4BBB6CA1.80800@sunwave.net> Nick Hilliard wrote: > "PHP stinks on the command line and text processing" > This is a bit of a broad sweeping statement! Can you elaborate on what your definition of how PHP "stinks" in this context? We have dozens of CLI scripts all written in PHP, some of which have been running for years and never given us any grief. We specifically chose PHP as the scripting language to standardize on to replace PERL because it was simple to learn and extremely powerful. I came from a PERL (and C/Pascal/Assembler) background so I found the PHP language stylings a natural fit when I discovered it in 2001, and have been using it for most of my scripting needs ever since. PHP adopts a lot of "PERL-isms" which I find very comfortable. Occasionally I do hear of someone deriding PHP, and naturally I would like to hear their side of the story. Often, I find it is due to lack of experience with PHP CLI scripting, or perhaps just PHP's capabilities in general. M From sfouant at shortestpathfirst.net Tue Apr 6 12:48:39 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Tue, 6 Apr 2010 13:48:39 -0400 Subject: As the "NANOG Community" Moves to IPv6... In-Reply-To: <4848122.21270544914951.JavaMail.root@jennyfur.pelican.org> References: <8363278.01270544775332.JavaMail.root@jennyfur.pelican.org> <4848122.21270544914951.JavaMail.root@jennyfur.pelican.org> Message-ID: <009f01cad5b1$6502a400$2f07ec00$@net> > -----Original Message----- > From: Tim Franklin [mailto:tim at pelican.org] > Sent: Tuesday, April 06, 2010 5:09 AM > To: NANOG list > Subject: Re: As the "NANOG Community" Moves to IPv6... > > > P.S. Does anyone else think that perhaps "ipv3.com" == "Guillaume > > FORTAINE"? > > It's spewing semi-coherent proposals for unworkable alternative > addressing schemes. Sounds more like Jim Fleming to me. Perhaps we > start comparing IPv3 to IPv8 and see if we get a reaction? ;) WHOIS results for ipv3.com: Domain Name: ipv3.com Registered at http://www.dynadot.com Registrant: Jim Fleming 1163 E. Ogden Ave. 705-205 Naperville, IL 60563 United States Stefan Fouant, CISSP, JNCIEx2 www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From marty.anstey at sunwave.net Tue Apr 6 13:05:27 2010 From: marty.anstey at sunwave.net (Marty Anstey) Date: Tue, 06 Apr 2010 11:05:27 -0700 Subject: Books for the NOC guys... In-Reply-To: <4BBB7218.6060802@neuropunks.org> References: <86wrwqukcm.fsf@seastrom.com> <28028.1270215582@localhost> <4BB62CC1.3010204@foobar.org> <4BBB6CA1.80800@sunwave.net> <4BBB7218.6060802@neuropunks.org> Message-ID: <4BBB77E7.2010202@sunwave.net> Max Gribov wrote: > On 04/06/2010 01:17 PM, Marty Anstey wrote: >> Nick Hilliard wrote: >> >>> "PHP stinks on the command line and text processing" >>> >>> >> This is a bit of a broad sweeping statement! Can you elaborate on what >> your definition of how PHP "stinks" in this context? >> > > well, try to parse ~60mb csv file doing some simple tweaks to the > input and then insert it into the database, and watch how much ram > your script will use, as well as how long it will take vs perl.. > for me, it takes about 5 hours and eats up to 1gb of ram (configured > memory limit for php for me) > > Hi Max, While I appreciate where you're coming from, I've never had that issue. It sounds like you're trying to load the entire script into RAM and then parse it. Regardless of the language you are using, you'll still essentially get the same result. > that said, php is awesome otherwise, been using it for last 2 years > strictly in 'enterprise' deployment.. > id just say perl is faster and more efficient for batch scripts. I can't speak specifically to the performance differences for comparible operations in PHP and PERL as I have never done a side-by-side comparison myself. But FWIW, I have parsed multi-gigabyte files with PHP on the command line and it's never been markedly "slow". Sure, it's not pure C but it's never been so slow that i've thought - "heck, this would be a lot faster with PERL"... Just my $0.02... Cheers, -Marty From mike at mtcc.com Tue Apr 6 13:15:48 2010 From: mike at mtcc.com (Michael Thomas) Date: Tue, 06 Apr 2010 11:15:48 -0700 Subject: Books for the NOC guys... In-Reply-To: <4BBB77E7.2010202@sunwave.net> References: <86wrwqukcm.fsf@seastrom.com> <28028.1270215582@localhost> <4BB62CC1.3010204@foobar.org> <4BBB6CA1.80800@sunwave.net> <4BBB7218.6060802@neuropunks.org> <4BBB77E7.2010202@sunwave.net> Message-ID: <4BBB7A54.7020307@mtcc.com> On 04/06/2010 11:05 AM, Marty Anstey wrote: >> that said, php is awesome otherwise, been using it for last 2 years >> strictly in 'enterprise' deployment.. >> id just say perl is faster and more efficient for batch scripts. > > I can't speak specifically to the performance differences for comparible > operations in PHP and PERL as I have never done a side-by-side > comparison myself. But FWIW, I have parsed multi-gigabyte files with PHP > on the command line and it's never been markedly "slow". Sure, it's not > pure C but it's never been so slow that i've thought - "heck, this would > be a lot faster with PERL"... One data point that I can speak to is the difference in parsing XML using the expat library between python and PHP for very large files. Python was quite a bit faster than PHP, but I can't recall the exact magnitude (2x? 10x? it's been too long but it was pretty significant). That said, performance is only one reason to use a language over others. PHP programmers are probably 10x more plentiful than python programmers, as another metric. So it very much depends on the larger picture. Mike, who hasn't found the CLI interface to PHP particularly better or worse than others From michael.holstein at csuohio.edu Tue Apr 6 13:40:09 2010 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Tue, 06 Apr 2010 14:40:09 -0400 Subject: FCC dealt major blow in net neutrality ruling favoring Comcast In-Reply-To: <42DF9B4B-8614-43F9-802D-9586AA7AD0FB@ianai.net> References: <42DF9B4B-8614-43F9-802D-9586AA7AD0FB@ianai.net> Message-ID: <4BBB8009.1060408@csuohio.edu> > > > Seems on-topic, even though policy related. > Between that and the ACTA foolishness .. seems to be a good time to get into the VPN business. /rant Michael Holstein Cleveland State University From Peter.AshwoodSmith at huawei.com Tue Apr 6 14:29:38 2010 From: Peter.AshwoodSmith at huawei.com (Peter Ashwood-Smith) Date: Tue, 06 Apr 2010 15:29:38 -0400 Subject: Auto MDI/MDI-X + conference rooms + bored == loop / 802.1aq Shortest Path Bridging Message-ID: <007301cad5bf$800c9ae0$e085c10a@china.huawei.com> These standards do drag on don't they. I'd suggest that customers need to come along and crack the whip a bit to help keep us grounded and moving.good excuse to travel somewhere warm ;) On the 802.1aq comment, we are doing MIBs/cleanup now so it should be out by end of this year so its probably time for an 802.1aq tutorial at NANOG. Peter Ashwood-Smith. _____ From: James Hess Date: Fri, 26 Mar 2010 23:13:11 -0500 _____ On Fri, Mar 26, 2010 at 9:29 PM, Chuck Anderson wrote: So basically, the problem is the core switches implement a proprietary loop-prevention protocol that sends "beacon" frames out every 500ms, and if a certain number of these special frames come back (exceeds --> loop first, but I'm beginning to think that this protocol is crap and I should just disable it and let the core ride out the loop in the Ah, nasty.. it seems like you definitely should want to keep the beacon frames from getting injected then. Taking down core links ought to be harder than 1 user emitting a few frames. A malicious user, or a naive user with a malicious trojan on their computer could try to send fake beacons, to cause trouble. I for one might start thinking if the beacons can be sunk from end user ports by brute force, using a Layer 2 ACL. I wonder if RFC 5556, IETF TRILL specs, or 802.1aq/802.1Qbb / Datacenter Ethernet / Bridging standards and more robust standards-based loop avoidance standards will ever get finalized, considering they have been drafts for over 5 years, it seems like the standardization is very sluggish. A new protocol is probably the right solution, but it might not be ready until 2015 at this rate. Anyone know if Auto MDI/MDI-X is inherent or required in 1000Base-T? It would be nice if I could shut it off. Auto MDI/MDI-X is an optional feature in the 1000BaseT standard. Automatic negotiation of speeds and duplex, is mandatory due to 802.3ab, but not auto-crossover You can get that here http://standards.ieee.org/getieee802/802.3.html Clause 40.4.4 in IEEE 802.3-2008 -- Section Three states the following: "40.4.4 Automatic MDI/MDI-X Configuration Automatic MDI/MDI-X Configuration is intended to eliminate the need for crossover cables between simi lar devices. Implementation of an automatic MDI/MDI-X configuration is optional for 1000BASE-T devices. If an automatic configuration method is used, it shall comply with the following specifications. The assignment of pin-outs for a 1000BASE-T crossover function cable is shown in Table40-12 in 40.8. " From jlewis at lewis.org Tue Apr 6 14:53:00 2010 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 6 Apr 2010 15:53:00 -0400 (EDT) Subject: what about 48 bits? In-Reply-To: References: <22710.1270501703@localhost> Message-ID: On Mon, 5 Apr 2010, Patrick W. Gilmore wrote: >> Until you buy 25 cards with the same MAC address and deploy them all across >> your enterprise > > I don't think that's possible given that Jon was suggesting. Given what I was suggesting, no...but there have been multiple cases of a vendor screwing up and producing large runs of devices/cards all with the same MAC address. IIRC, there was a batch of Netgear PCI NICs where you might find all the NICs in a multipack box had the same MAC address. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From rs at seastrom.com Tue Apr 6 15:14:37 2010 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 06 Apr 2010 16:14:37 -0400 Subject: Books for the NOC guys... In-Reply-To: <4BBB77E7.2010202@sunwave.net> (Marty Anstey's message of "Tue, 06 Apr 2010 11:05:27 -0700") References: <86wrwqukcm.fsf@seastrom.com> <28028.1270215582@localhost> <4BB62CC1.3010204@foobar.org> <4BBB6CA1.80800@sunwave.net> <4BBB7218.6060802@neuropunks.org> <4BBB77E7.2010202@sunwave.net> Message-ID: <867hokjq36.fsf@seastrom.com> Marty Anstey writes: > Max Gribov wrote: >> On 04/06/2010 01:17 PM, Marty Anstey wrote: >>> Nick Hilliard wrote: >>> >>>> "PHP stinks on the command line and text processing" >>> >>> This is a bit of a broad sweeping statement! Can you elaborate on what >>> your definition of how PHP "stinks" in this context? >> >> well, try to parse ~60mb csv file doing some simple tweaks to the >> input and then insert it into the database, and watch how much ram >> your script will use, as well as how long it will take vs perl.. >> for me, it takes about 5 hours and eats up to 1gb of ram (configured >> memory limit for php for me) > > While I appreciate where you're coming from, I've never had that issue. > It sounds like you're trying to load the entire script into RAM and then > parse it. Regardless of the language you are using, you'll still > essentially get the same result. As it happens, the loadup script I wrote that parses ARIN bulk whois dump data and loads it into an SQL database is both written in PHP and about an order of magnitude faster than its predecessor which was written by someone else in perl. Helps that I knew enough to LOCK TABLES... :-) -r From henry at AegisInfoSys.com Tue Apr 6 15:26:16 2010 From: henry at AegisInfoSys.com (Henry Yen) Date: Tue, 6 Apr 2010 16:26:16 -0400 Subject: ping "eu.level3.net" Message-ID: <20100406162616.T25919@AegisInfoSys.com> Anyone from "eu.level3.net" who can respond to an e-mail (inbound) misconfiguration? -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From bonomi at mail.r-bonomi.com Tue Apr 6 16:23:41 2010 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Tue, 6 Apr 2010 16:23:41 -0500 (CDT) Subject: what about 48 bits? Message-ID: <201004062123.o36LNfqb013365@mail.r-bonomi.com> > From: Steven Bellovin > Date: Mon, 5 Apr 2010 13:51:23 -0400 > Cc: NANOG > > On Apr 5, 2010, at 1:43 52PM, Valdis.Kletnieks at vt.edu wrote: > > > On Mon, 05 Apr 2010 13:29:20 EDT, Jay Nakamura said: > >>>> I would have attributed the success of Ethernet to price! > >>>>=20 > >>>>=20 > >>> You've got the causality wrong -- it wasn't cheap, way back when. > >>=20 > >> I remember back in '93~94ish (I think) you could get a off brand 10BT > >> card for less than $100, as oppose to Token Ring which was $300~400. > >> I can't remember anything else that was cheaper back then. If you go > >> back before that, I don't know. > >=20 > > Steve is talking mid-80s pricing, not mid-90s. By '93 or so, the fact > > that Ethernet was becoming ubiquitous had already forced the price = > down. > > Yup. 10 years earlier, a 3Com Ethernet card for a Vax cost about $1500, = > if memory serves. That ball-park anyway -- ethernet for VMEbus or VERSAbus was in the same price range. Just a _few_ years later, ARCnet was one of several signficantly less expensive alternatives for limited-size (both in number of hosts, and distance) LANS. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Apr 6 18:09:43 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 7 Apr 2010 08:39:43 +0930 Subject: IPv6 Newbie In-Reply-To: <20100406.175417.74715766.sthaug@nethelp.no> References: <20100406.095741.74713545.sthaug@nethelp.no> <20100406191701.443d1548@opy.nosense.org> <20100406.175417.74715766.sthaug@nethelp.no> Message-ID: <20100407083943.55d4bd99@opy.nosense.org> On Tue, 06 Apr 2010 17:54:17 +0200 (CEST) sthaug at nethelp.no wrote: > > > > > Can one subnet to include /127 for point to point connections? > > > > > > > > The best advice is to use a /64 unless you have read and understood > > > > RFC 3627 http://tools.ietf.org/html/rfc3627 > > > > > > RFC 3627 *and* the following Internet draft: > > > > > > http://tools.ietf.org/search/draft-kohno-ipv6-prefixlen-p2p-01 > > > > > > The problem with ping-pong on point to point links is real. > > > > Only if you disable Neighbor Discovery. > > You don't have to disable it. "Small, unknown" vendors like Cisco and > Juniper As you've already resorted to insulting me, this is my last response. I don't think you're correct. > have IPv6 ND disabled on point to point links, and (at least > for Juniper) there is no option to turn it on. > > The problem with ping-pong on point to point links is still very real. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no From nanog2 at adns.net Tue Apr 6 18:36:51 2010 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Tue, 6 Apr 2010 18:36:51 -0500 Subject: interop show network (was: legacy /8) References: <11C01471-4245-4D1D-8628-A9F8C7203E92@icann.org> Message-ID: <94EAA35022084CBBB0DF2896193940E9@TAKA> When do you think that 1/8, 2/8 and 50/8 will start showing up as live, assigned addresses. I don't see any of them coming in on my core routers yet. ----- Original Message ----- From: "Leo Vegoda" To: "Jon Lewis" Cc: Sent: Monday, April 05, 2010 1:04 PM Subject: Re: interop show network (was: legacy /8) On 5 Apr 2010, at 9:13, Jon Lewis wrote: > On Sun, 4 Apr 2010, Christopher Morrow wrote: [...] > If we could recover them all, how many more years of IPv4 allocations > would that buy us? We allocate RIRs approximately one /8 per month. So you'd have to reclaim 12 /8s to extend the allocation pool by one year. Regards, Leo From jfbeam at gmail.com Tue Apr 6 19:10:14 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 06 Apr 2010 20:10:14 -0400 Subject: IPv6 Newbie In-Reply-To: References: Message-ID: On Tue, 06 Apr 2010 03:20:26 -0400, shake righa wrote: > Can one subnet to include /127 for point to point connections? That's the equiv of a /31 in IPv4. Do you use /31's for p-t-p links in your IPv4 network(s)? (Yes, I've used /31's before, but only to represent 2 /32's. And even that was silly.) --Ricky From stephen at sprunk.org Tue Apr 6 21:39:44 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 06 Apr 2010 21:39:44 -0500 Subject: what about 48 bits? In-Reply-To: <13353.1270489432@localhost> References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> <20100405105746.750257bf@opy.nosense.org> <20100405025742.GR75640@gerbil.cluepon.net> <4BB96187.6040703@bogus.com> <2B39543C-7EF5-48AE-9E54-3E8A0C714204@cs.columbia.edu> <13353.1270489432@localhost> Message-ID: <4BBBF070.6000403@sprunk.org> On 05 Apr 2010 12:43, Valdis.Kletnieks at vt.edu wrote: > On Mon, 05 Apr 2010 13:29:20 EDT, Jay Nakamura said: > >>>> I would have attributed the success of Ethernet to price! >>>> >>> You've got the causality wrong -- it wasn't cheap, way back when. >>> >> I remember back in '93~94ish (I think) you could get a off brand 10BT >> card for less than $100, as oppose to Token Ring which was $300~400. >> I can't remember anything else that was cheaper back then. If you go >> back before that, I don't know. >> > Steve is talking mid-80s pricing, not mid-90s. By '93 or so, the fact > that Ethernet was becoming ubiquitous had already forced the price down. > Ah, but what _caused_ Ethernet to become ubiquitous, given the price was initially comparable? The only explanation I can think of is the raft of cheap NE2000 knock-offs that hit the market in the late 1980s, which gave Ethernet a major price advantage over Token Ring (the chips for which all vendors _had_ to buy from IBM at ridiculous cost). That, in turn, led to mass adoption and further economies of scale, pushing the price lower and lower in a virtuous cycle. Still, lots of shops stuck with TR well into the mid- and even late 1990s because Ethernet didn't perform as well as TR under moderate to high utilization by multiple hosts, not to mention IBM's insistence that TR was required for SNA. It wasn't until Ethernet switching came out, mostly solving CSMA/CD's performance problems and eventually leading to full-duplex operation, that it was entirely obvious which was going to win, and I spent several years doing almost nothing but helping large enterprises convert to Ethernet (usually with the help of DLSw). By that point, off-brand Ethernet chips cost _less than 1%_ of what IBM's TR chips did, thanks to competition and sheer volume, so vendors had started including them "for free" on every PC and server, and that was the final nail in TR's coffin. (LocalTalk, ARCnet, and a variety of other physical layers suffered a similar fate, but unlike IBM, their backers quickly switched to Ethernet when they realized they couldn't compete with it on price _or_ on performance given their limited volumes, so those deaths were more sudden and absolute than TR's.) As to why no other technology has managed to dislodge Ethernet, though, I think it's fairly clear that's because the various successors to 10BaseT have all maintained the same connector and the same framing, which makes for trivial upgrades that deliver regular (and significant) performance improvements as customers' equipment replacement cycle turns. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From joelja at bogus.com Tue Apr 6 22:02:12 2010 From: joelja at bogus.com (joel jaeggli) Date: Tue, 06 Apr 2010 23:02:12 -0400 Subject: what about 48 bits? In-Reply-To: <4BBBF070.6000403@sprunk.org> References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> <20100405105746.750257bf@opy.nosense.org> <20100405025742.GR75640@gerbil.cluepon.net> <4BB96187.6040703@bogus.com> <2B39543C-7EF5-48AE-9E54-3E8A0C714204@cs.columbia.edu> <13353.1270489432@localhost> <4BBBF070.6000403@sprunk.org> Message-ID: <4BBBF5B4.8000906@bogus.com> On 4/6/2010 10:39 PM, Stephen Sprunk wrote: > On 05 Apr 2010 12:43, Valdis.Kletnieks at vt.edu wrote: >> On Mon, 05 Apr 2010 13:29:20 EDT, Jay Nakamura said: >> >>>>> I would have attributed the success of Ethernet to price! >>>>> >>>> You've got the causality wrong -- it wasn't cheap, way back when. >>>> >>> I remember back in '93~94ish (I think) you could get a off brand 10BT >>> card for less than $100, as oppose to Token Ring which was $300~400. >>> I can't remember anything else that was cheaper back then. If you go >>> back before that, I don't know. >>> >> Steve is talking mid-80s pricing, not mid-90s. By '93 or so, the fact >> that Ethernet was becoming ubiquitous had already forced the price down. >> > > Ah, but what _caused_ Ethernet to become ubiquitous, given the price was > initially comparable? Early standardization. > The only explanation I can think of is the raft > of cheap NE2000 knock-offs that hit the market in the late 1980s, which > gave Ethernet a major price advantage over Token Ring (the chips for > which all vendors _had_ to buy from IBM at ridiculous cost). Metcalf didn't make computers, whereas IBM and Datapoint did, protecting their captive markets cost both of them quite dearly. From pfunix at gmail.com Wed Apr 7 00:14:51 2010 From: pfunix at gmail.com (Beavis) Date: Tue, 6 Apr 2010 23:14:51 -0600 Subject: Best Practice: 2routers, 2isp, 1AS Message-ID: Greetings! Want to ask out anybody on the list about a "best practice" of the setup below: - 2 ISP's (A & B) - 2 Routers (A & B) I want Router-A for ISP-A, Router-B for ISP-B and have Router-A & Router-B talk and be able to pass routes on each side in an event of a physical failure on one of the Routers. I was planning at first to setup a multi-home BGP, but I want to have physical redundancy as well. ASCII-diag =--[RouterA]--isp1(bgp) L | A iBGP N | =--[RouterB]--isp2(bgp) Any recommendation would awesomely appreciated. -B -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From bfeeny at mac.com Wed Apr 7 00:25:37 2010 From: bfeeny at mac.com (Brian Feeny) Date: Wed, 07 Apr 2010 01:25:37 -0400 Subject: Best Practice: 2routers, 2isp, 1AS In-Reply-To: References: Message-ID: <8BCB5625-633C-4786-93DA-F0715D8015B0@mac.com> There are alot more questions that need to be asked. Like how much address space do you have to announce? What routes are you getting from each ISP? Assuming you are an end user, and knowing the very limited information I know at this point, I would make sure that these two routers LAN interfaces are in some sort of transit vlan/subnet with my downstream router, which would also be participating in iBGP. Alternately you could have that router do VRRP/HSRP with your two border routers, but I prefer iBGP. I would then setup both routers using OER (Optimized Edge Routing, i think now known as Performance Based Routing), to handle outbound. You could just announce your /24 out each provider (assuming that's what you had) to handle inbound, or if you have larger than that you could announce the aggregate out both and more specifics out each to do some type of balancing. Its hard to say there is a best practice here, as there are so many scenarios. I will say that I like OeR/PfR for edge customers who are dual homed. BGP is very arbitrary, and its nice to have some real metrics that mean something to play with :) Brian On Apr 7, 2010, at 1:14 AM, Beavis wrote: > Greetings! > > Want to ask out anybody on the list about a "best practice" of the > setup below: > > - 2 ISP's (A & B) > - 2 Routers (A & B) > > I want Router-A for ISP-A, Router-B for ISP-B and have Router-A & > Router-B talk and be able to pass routes on each side in an event of a > physical failure on one of the Routers. > > I was planning at first to setup a multi-home BGP, but I want to have > physical redundancy as well. > > ASCII-diag > > =--[RouterA]--isp1(bgp) > L | > A iBGP > N | > =--[RouterB]--isp2(bgp) > > Any recommendation would awesomely appreciated. > > -B > > > -- > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > From randy at psg.com Wed Apr 7 00:39:21 2010 From: randy at psg.com (Randy Bush) Date: Wed, 07 Apr 2010 14:39:21 +0900 Subject: IPv6 Newbie In-Reply-To: References: Message-ID: >> Can one subnet to include /127 for point to point connections? > That's the equiv of a /31 in IPv4. Do you use /31's for p-t-p links in > your IPv4 network(s)? of course randy From pfunix at gmail.com Wed Apr 7 00:42:17 2010 From: pfunix at gmail.com (Beavis) Date: Tue, 6 Apr 2010 23:42:17 -0600 Subject: Best Practice: 2routers, 2isp, 1AS In-Reply-To: <8BCB5625-633C-4786-93DA-F0715D8015B0@mac.com> References: <8BCB5625-633C-4786-93DA-F0715D8015B0@mac.com> Message-ID: thanks for the reply brian. :) sorry for a bit lack on the info, I was thinking of using VRRP. but my 2 links are running on different interface-types isp1 runs via ethernet while the other is on an ATM interface. I only have 1 router that has an ATM interface. setting it to VRRP would cause me problems if it was a physical failure. I have a small /24 to advertise on my AS. I'll go and check on the "Performance Based Routing" you recommend. thanks, -b On Tue, Apr 6, 2010 at 11:25 PM, Brian Feeny wrote: > > There are alot more questions that need to be asked. ?Like how much address space do you have to announce? What routes are you getting from each ISP? > > Assuming you are an end user, and knowing the very limited information I know at this point, I would make sure that these two routers LAN interfaces are in some sort of transit vlan/subnet with my downstream router, which would also be participating in iBGP. ?Alternately you could have that router do VRRP/HSRP with your two border routers, but I prefer iBGP. > > I would then setup both routers using OER (Optimized Edge Routing, i think now known as Performance Based Routing), to handle outbound. ?You could just announce your /24 out each provider (assuming that's what you had) to handle inbound, or if you have larger than that you could announce the aggregate out both and more specifics out each to do some type of balancing. > > Its hard to say there is a best practice here, as there are so many scenarios. ?I will say that I like OeR/PfR for edge customers who are dual homed. ?BGP is very arbitrary, and its nice to have some real metrics that mean something to play with :) > > Brian > > > On Apr 7, 2010, at 1:14 AM, Beavis wrote: > >> Greetings! >> >> ? Want to ask out anybody on the list about a "best practice" of the >> setup below: >> >> - 2 ISP's (A & B) >> - 2 Routers (A & B) >> >> I want Router-A for ISP-A, Router-B for ISP-B and have Router-A & >> Router-B talk and be able to pass routes on each side in an event of a >> physical failure on one of the Routers. >> >> I was planning at first to setup a multi-home BGP, but I want to have >> physical redundancy as well. >> >> ASCII-diag >> >> =--[RouterA]--isp1(bgp) >> L ? ?| >> A ? iBGP >> N ? ?| >> =--[RouterB]--isp2(bgp) >> >> Any recommendation would awesomely appreciated. >> >> -B >> >> >> -- >> () ?ascii ribbon campaign - against html e-mail >> /\ ?www.asciiribbon.org ? - against proprietary attachments >> > > -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From sthaug at nethelp.no Wed Apr 7 01:25:22 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 07 Apr 2010 08:25:22 +0200 (CEST) Subject: IPv6 Newbie In-Reply-To: <20100407083943.55d4bd99@opy.nosense.org> References: <20100406191701.443d1548@opy.nosense.org> <20100406.175417.74715766.sthaug@nethelp.no> <20100407083943.55d4bd99@opy.nosense.org> Message-ID: <20100407.082522.74676857.sthaug@nethelp.no> > > You don't have to disable it. "Small, unknown" vendors like Cisco and > > Juniper > > I don't think you're correct. > > have IPv6 ND disabled on point to point links, and (at least > > for Juniper) there is no option to turn it on. I encourage people to verify this for themselves. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From lists at internetpolicyagency.com Wed Apr 7 03:03:40 2010 From: lists at internetpolicyagency.com (Roland Perry) Date: Wed, 7 Apr 2010 09:03:40 +0100 Subject: what about 48 bits? In-Reply-To: <4BBBF070.6000403@sprunk.org> References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> <20100405105746.750257bf@opy.nosense.org> <20100405025742.GR75640@gerbil.cluepon.net> <4BB96187.6040703@bogus.com> <2B39543C-7EF5-48AE-9E54-3E8A0C714204@cs.columbia.edu> <13353.1270489432@localhost> <4BBBF070.6000403@sprunk.org> Message-ID: In article <4BBBF070.6000403 at sprunk.org>, Stephen Sprunk writes >Ah, but what _caused_ Ethernet to become ubiquitous, given the price was >initially comparable? For me, as an SME user, I started using Ethernet when Dlink introduced an ISA card [DE205] which had a 4-port hub built in (actually 5-port if you counted the internal one), at not a great deal more than a normal 10Base-T card. I think it was about $250, when a typical desktop PC was $2500. So all I needed to build my network was one of those, some cable, and add-in Ethernet cards for each other PC I wanted to bring into the LAN. As icing on the cake, they also had a Centronics-port dongle to hook up almost all laptops very easily, and in an emergency you could even use it on a desktop. Price was a major feature, but interoperability and backwards compatibility were the tipping points. -- Roland Perry From jgreco at ns.sol.net Wed Apr 7 05:23:55 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 7 Apr 2010 05:23:55 -0500 (CDT) Subject: what about 48 bits? In-Reply-To: from "Roland Perry" at Apr 07, 2010 09:03:40 AM Message-ID: <201004071023.o37ANtww018405@aurora.sol.net> > For me, as an SME user, I started using Ethernet when Dlink introduced > an ISA card [DE205] which had a 4-port hub built in (actually 5-port if > you counted the internal one), at not a great deal more than a normal > 10Base-T card. I think it was about $250, when a typical desktop PC was > $2500. > > [...] > > Price was a major feature, but interoperability and backwards > compatibility were the tipping points. Ah, yes, backwards compatibility: implementing the fantastic feature of breaking the network... we all remember the fun of what happened when someone incorrectly unhooked a 10base2 network segment; D-Link managed to one-up that on the theoretically more-robust 10baseT/UTP by introducing a card that'd break your network when you powered off the attached PC. Designer of that deserved to be whipped with some RG-58. :-) ... 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 lists at internetpolicyagency.com Wed Apr 7 05:43:41 2010 From: lists at internetpolicyagency.com (Roland Perry) Date: Wed, 7 Apr 2010 11:43:41 +0100 Subject: what about 48 bits? In-Reply-To: <201004071023.o37ANtww018405@aurora.sol.net> References: <201004071023.o37ANtww018405@aurora.sol.net> Message-ID: In article <201004071023.o37ANtww018405 at aurora.sol.net>, Joe Greco writes >>interoperability and backwards compatibility were the tipping points. > >Ah, yes, backwards compatibility: implementing the fantastic feature of >breaking the network... By "backwards compatibility" I mean the ability to use the new LAN from a laptop that didn't have an Ethernet connection built in, and didn't have an optional [proprietary] internal Ethernet card available either. Later on, of course, you would get PCMCIA cards and USB dongles rather than Centronics-port dongles. But the market for these remained dominated by the Ethernet standard, rather than others. >we all remember the fun of what happened when >someone incorrectly unhooked a 10base2 network segment; D-Link managed >to one-up that on the theoretically more-robust 10baseT/UTP by >introducing a card that'd break your network when you powered off the >attached PC. That tale of woe doesn't really sound like it's the fault of backwards compatibility. Didn't the operational status of the LAX immigration department fall to zero for almost a whole day, once; as a result of a rogue network card crashing the LAN? -- Roland Perry From jgreco at ns.sol.net Wed Apr 7 06:18:57 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 7 Apr 2010 06:18:57 -0500 (CDT) Subject: what about 48 bits? In-Reply-To: from "Roland Perry" at Apr 07, 2010 11:43:41 AM Message-ID: <201004071118.o37BIvK1022393@aurora.sol.net> > In article <201004071023.o37ANtww018405 at aurora.sol.net>, Joe Greco > writes > > >>interoperability and backwards compatibility were the tipping points. > > > >Ah, yes, backwards compatibility: implementing the fantastic feature of > >breaking the network... > > By "backwards compatibility" I mean the ability to use the new LAN from > a laptop that didn't have an Ethernet connection built in, and didn't > have an optional [proprietary] internal Ethernet card available either. There are a lot of things to target with the term, I was picking conveniently. :-) > >we all remember the fun of what happened when > >someone incorrectly unhooked a 10base2 network segment; D-Link managed > >to one-up that on the theoretically more-robust 10baseT/UTP by > >introducing a card that'd break your network when you powered off the > >attached PC. > > That tale of woe doesn't really sound like it's the fault of backwards > compatibility. No, but I remember network people talking gleefully about the benefits of 10baseT (and come on - it has lots), and how it fixed the "someone needed to move a PC and disconnected the cables from the T rather than the T from the NIC" problem... and along came D-Link (and some other vendors I think) with the brilliant idea of a host-integrated hub. Now, remember, some network guys walked around with new-in-bag BNC T's in their pocket because they'd run across someone who disappeared a T every month or two, and there's great power in turning your back, twiddling for a few seconds, and then being able to holler "Network's back up!"... Unfortunately, power-cycling crashed PC's is (was?) pretty common, and many users are (were?) also trained to shut off PC's when done, so here you've introduced something that is by-design going to fail periodically. Not just if-and-when someone decides to move a computer and screws it up. Of course, if someone actually removes the PC in question, and does not realize that the network actually feeds _through_ the PC, um, well, you cannot just whip a T out of your pocket to "fix" the network. To me, this is a Dilbert-class engineering failure. I would imagine that if you could implement a hub on the network card, the same chip(s) would work in an external tin can with a separate power supply. Designing a product that actually exhibits a worse failure mode than 10base2 is ... strange to me. I was sarcastically referring to this as "backwards compatibility", possibly also with New Enhanced Features, ha ha. > Didn't the operational status of the LAX immigration > department fall to zero for almost a whole day, once; as a result of a > rogue network card crashing the LAN? Probably. Not my area of the country. There are plenty of examples of networking disasters. ;-) ... 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 jtk at cymru.com Wed Apr 7 07:29:08 2010 From: jtk at cymru.com (John Kristoff) Date: Wed, 7 Apr 2010 07:29:08 -0500 Subject: what about 48 bits? In-Reply-To: <4BBBF5B4.8000906@bogus.com> References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> <20100405105746.750257bf@opy.nosense.org> <20100405025742.GR75640@gerbil.cluepon.net> <4BB96187.6040703@bogus.com> <2B39543C-7EF5-48AE-9E54-3E8A0C714204@cs.columbia.edu> <13353.1270489432@localhost> <4BBBF070.6000403@sprunk.org> <4BBBF5B4.8000906@bogus.com> Message-ID: <20100407072908.55893c7c@t61p> On Tue, 06 Apr 2010 23:02:12 -0400 joel jaeggli wrote: > > Ah, but what _caused_ Ethernet to become ubiquitous, given the > > price was initially comparable? > > Early standardization. In one of my other favorite books, Gigabit Ethernet, Rich Seifert says: "[...] IBM was the only computer *systems* manufacturer actively promoting a Token Ring-based strategy. Ultimately, the reason we build networks is to attach the computers that supports the users' applications. Network equipment vendors provide products to support the interconnection of the computers, but the network is the means, not the end. Ethernet had the necessary broad support from many computer systems manufacturers from the very beginning, including not only the original DIX consortium, but also major players like Sun Microsystems, Hewlett-Packard, and dozens of others." John From heather.schiller at verizonbusiness.com Wed Apr 7 08:57:46 2010 From: heather.schiller at verizonbusiness.com (Schiller, Heather A (HeatherSkanks)) Date: Wed, 07 Apr 2010 13:57:46 +0000 Subject: interop show network (was: legacy /8) In-Reply-To: <94EAA35022084CBBB0DF2896193940E9@TAKA> References: <11C01471-4245-4D1D-8628-A9F8C7203E92@icann.org> <94EAA35022084CBBB0DF2896193940E9@TAKA> Message-ID: Might want to double check you aren't filtering, as parts of 1/8 and 2/8 have been intermittently announced by RIR's in debogonizing efforts over the last few months. Routing wise, this really isn't different from the space being assigned - better to clear up any filtering and identify routing problems or renumbering efforts you may need now before the space gets allocated, probably later this year. In fact, parts of 2/8 are being announced right now for debogon-izing: route-views>sh ip bgp 2.0.0.0/8 longer-prefixes BGP table version is 2323163774, local router ID is 128.223.51.103 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 2.0.0.0/16 194.85.102.33 0 3277 3267 30132 12654 I --Heather -----Original Message----- From: John Palmer (NANOG Acct) [mailto:nanog2 at adns.net] Sent: Tuesday, April 06, 2010 7:37 PM To: nanog at nanog.org Subject: Re: interop show network (was: legacy /8) When do you think that 1/8, 2/8 and 50/8 will start showing up as live, assigned addresses. I don't see any of them coming in on my core routers yet. ----- Original Message ----- From: "Leo Vegoda" To: "Jon Lewis" Cc: Sent: Monday, April 05, 2010 1:04 PM Subject: Re: interop show network (was: legacy /8) On 5 Apr 2010, at 9:13, Jon Lewis wrote: > On Sun, 4 Apr 2010, Christopher Morrow wrote: [...] > If we could recover them all, how many more years of IPv4 allocations > would that buy us? We allocate RIRs approximately one /8 per month. So you'd have to reclaim 12 /8s to extend the allocation pool by one year. Regards, Leo From dylan.ebner at crlmed.com Wed Apr 7 09:06:25 2010 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Wed, 7 Apr 2010 14:06:25 +0000 Subject: Best Practice: 2routers, 2isp, 1AS In-Reply-To: References: <8BCB5625-633C-4786-93DA-F0715D8015B0@mac.com> Message-ID: <017265BF3B9640499754DD48777C3D206859F8F96D@MBX9.EXCHPROD.USA.NET> You can still use vrrp in the inside. We have a similar configuration to what you have defined. Two routers, 4 ISPs, BGP annoucing 2 /24's. We get partial routes and prepend on 3 of the isps to only use our primary. Our primary is delivered via fiber and the backup isps are delivered via copper ethernet. We use interface tracking with reachability to determine if we are having a problem with one of our downstreams. This way, if we still have a link light, but no traffic flow we can detect and adjust accordingly. Dylan -----Original Message----- From: Beavis [mailto:pfunix at gmail.com] Sent: Wednesday, April 07, 2010 12:42 AM To: nanog at nanog.org Subject: Re: Best Practice: 2routers, 2isp, 1AS thanks for the reply brian. :) sorry for a bit lack on the info, I was thinking of using VRRP. but my 2 links are running on different interface-types isp1 runs via ethernet while the other is on an ATM interface. I only have 1 router that has an ATM interface. setting it to VRRP would cause me problems if it was a physical failure. I have a small /24 to advertise on my AS. I'll go and check on the "Performance Based Routing" you recommend. thanks, -b On Tue, Apr 6, 2010 at 11:25 PM, Brian Feeny wrote: > > There are alot more questions that need to be asked. ?Like how much address space do you have to announce? What routes are you getting from each ISP? > > Assuming you are an end user, and knowing the very limited information I know at this point, I would make sure that these two routers LAN interfaces are in some sort of transit vlan/subnet with my downstream router, which would also be participating in iBGP. ?Alternately you could have that router do VRRP/HSRP with your two border routers, but I prefer iBGP. > > I would then setup both routers using OER (Optimized Edge Routing, i think now known as Performance Based Routing), to handle outbound. ?You could just announce your /24 out each provider (assuming that's what you had) to handle inbound, or if you have larger than that you could announce the aggregate out both and more specifics out each to do some type of balancing. > > Its hard to say there is a best practice here, as there are so many scenarios. ?I will say that I like OeR/PfR for edge customers who are dual homed. ?BGP is very arbitrary, and its nice to have some real metrics that mean something to play with :) > > Brian > > > On Apr 7, 2010, at 1:14 AM, Beavis wrote: > >> Greetings! >> >> ? Want to ask out anybody on the list about a "best practice" of the >> setup below: >> >> - 2 ISP's (A & B) >> - 2 Routers (A & B) >> >> I want Router-A for ISP-A, Router-B for ISP-B and have Router-A & >> Router-B talk and be able to pass routes on each side in an event of a >> physical failure on one of the Routers. >> >> I was planning at first to setup a multi-home BGP, but I want to have >> physical redundancy as well. >> >> ASCII-diag >> >> =--[RouterA]--isp1(bgp) >> L ? ?| >> A ? iBGP >> N ? ?| >> =--[RouterB]--isp2(bgp) >> >> Any recommendation would awesomely appreciated. >> >> -B >> >> >> -- >> () ?ascii ribbon campaign - against html e-mail >> /\ ?www.asciiribbon.org ? - against proprietary attachments >> > > -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From lear at cisco.com Wed Apr 7 09:09:25 2010 From: lear at cisco.com (Eliot Lear) Date: Wed, 07 Apr 2010 16:09:25 +0200 Subject: interop show network (was: legacy /8) In-Reply-To: References: Message-ID: <4BBC9215.40207@cisco.com> On 4/5/10 6:02 AM, Brandon Ross wrote: > Seriously? You do realize that the InteropNet actually has to provide > a real service to the exhibitors and attendees of the show, right? > This year's network will support v6, but a v6-only network is just not > a practical way to supply real network connectivity to customers, yet. > I remember the days of Ron Natalie running around with a cherry picker in San Jose, and the whole point of the network being to test interoperability, so that things would and did break (and then we fixed them). If v6 is even close to ready, wouldn't it be sad that this sort of testing isn't done at interop? Or is it just sad that v6 isn't so close to being ready? Or is it both? From bross at pobox.com Wed Apr 7 09:12:48 2010 From: bross at pobox.com (Brandon Ross) Date: Wed, 7 Apr 2010 10:12:48 -0400 (EDT) Subject: interop show network (was: legacy /8) In-Reply-To: <4BBC9215.40207@cisco.com> References: <4BBC9215.40207@cisco.com> Message-ID: On Wed, 7 Apr 2010, Eliot Lear wrote: > If v6 is even close to ready, wouldn't it be sad that this sort of > testing isn't done at interop? Or is it just sad that v6 isn't so close > to being ready? Or is it both? The suggestion was to run a "v6 only network". Does anyone on the NANOG list believe that v6 is at all ready to be run without any v4 underpinnings and provide a real service to a customer base? -- Brandon Ross From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Apr 7 09:21:16 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 7 Apr 2010 23:51:16 +0930 Subject: FCC dealt major blow in net neutrality ruling favoring Comcast In-Reply-To: <42DF9B4B-8614-43F9-802D-9586AA7AD0FB@ianai.net> References: <42DF9B4B-8614-43F9-802D-9586AA7AD0FB@ianai.net> Message-ID: <20100407235116.7773cab2@opy.nosense.org> On Tue, 6 Apr 2010 11:30:16 -0400 "Patrick W. Gilmore" wrote: > > > Seems on-topic, even though policy related. > It seems to me that "Net Neutrality" has been conflagrated into meaning both of two separate things: (a) congestion management (b) restricting access to certain websites etc., such that an SP creates a Walled Garden, that either the customer or the content provider is expected to pay to or to provide access too. I'm not against (a), because fundamental assumptions of the Internet/TCP were short and brusty traffic, which implies end-nodes sharing network resources, and only dominating them for relatively short periods. P2P destroys (and yes, that is intentionally a strong word) that assumption. OTOH, (b) is something I completely object to. ISPs are a conduit, not a controller of content. So, there's the problem. According to the above, I'm both for, and against, Network Neutrality. One thing which would significantly help this argument for or against Network Neutrality is defining exactly what it is. Regards, Mark. From streiner at cluebyfour.org Wed Apr 7 09:34:43 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 7 Apr 2010 10:34:43 -0400 (EDT) Subject: interop show network (was: legacy /8) In-Reply-To: <4BBC9215.40207@cisco.com> References: <4BBC9215.40207@cisco.com> Message-ID: On Wed, 7 Apr 2010, Eliot Lear wrote: > I remember the days of Ron Natalie running around with a cherry picker in San > Jose, and the whole point of the network being to test interoperability, so > that things would and did break (and then we fixed them). If v6 is even > close to ready, wouldn't it be sad that this sort of testing isn't done at > interop? Or is it just sad that v6 isn't so close to being ready? Or is it > both? The lack of v6 readiness for a long time (and to some extent today) seems to have been locked in a vicious circle. Many users haven't been pushing vendors for v6 capabilities in their products (software and hardware) because they either didn't know about it, and/or didn't perceive it as important. OS developers seemed to be the most ahead of the curve on this, with usable v6 stacks available for most modern OSen for several years, and close to a decade in some cases. Many providers for a long time weren't implementing v6 because, while many knew it needed to happen, customers weren't pushing for it, and many network equipment vendors didn't have solid v6 implementations. Content providers would also fall into this bucket. Many vendors for a long time weren't making v6 development and support a priority because customers weren't pushing for it, so they didn't see a financial reason to do so. jms From lowen at pari.edu Wed Apr 7 09:24:51 2010 From: lowen at pari.edu (Lamar Owen) Date: Wed, 7 Apr 2010 10:24:51 -0400 Subject: Hubs on a NIC (was:Re: what about 48 bits?) In-Reply-To: <201004071118.o37BIvK1022393@aurora.sol.net> References: <201004071118.o37BIvK1022393@aurora.sol.net> Message-ID: <201004071024.51507.lowen@pari.edu> On Wednesday 07 April 2010 07:18:57 am Joe Greco wrote: > To me, this is a Dilbert-class engineering failure. I would imagine that > if you could implement a hub on the network card, the same chip(s) would > work in an external tin can with a separate power supply. Designing a > product that actually exhibits a worse failure mode than 10base2 is ... > strange to me. I have in my gear museum a fairly large box with a couple of this type of 'hub on a card' installed. And in this particular case, it made perfect sense, as the box is an Evergreen Systems CAPserver, and has 16 486 single-board computers tied to two 8-port hub cards (two ports on each modular plug, too), with....wait for it... a 10Base-2 uplink. These were used mostly for remote network access and remote desktop access. If you want more data on this old and odd box, see http://www.bomara.com/Eversys/capserver2300.htm I can see a hub card being useful in an old NetWare server setting, though, since if the server went down you might as well not have a network in the first place, in that use case. From cgrundemann at gmail.com Wed Apr 7 09:42:01 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 7 Apr 2010 08:42:01 -0600 Subject: FCC dealt major blow in net neutrality ruling favoring Comcast In-Reply-To: <20100407235116.7773cab2@opy.nosense.org> References: <42DF9B4B-8614-43F9-802D-9586AA7AD0FB@ianai.net> <20100407235116.7773cab2@opy.nosense.org> Message-ID: On Wed, Apr 7, 2010 at 08:21, Mark Smith wrote: > So, there's the problem. According to the above, I'm both for, and > against, Network Neutrality. > > One thing which would significantly help this argument for or against > Network Neutrality is defining exactly what it is. ISOC has gone a step further and stopped using the term "network neutrality" in general. This is due in large part to the problem you described quite well here - the term is loaded with emotion and largely undefined. They are now using the phrase "Open Internetworking" to describe their stance on the issue. For what it's worth, here is a good document recently published which defines that stance: http://www.isoc.org/pubpolpillar/usercentricity/20100222-Inter-Networking.pdf ~Chris I am the founding chair of the Colorado Chapter of the Internet Society - CO ISOC > Regards, > Mark. > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From bmanning at vacation.karoshi.com Wed Apr 7 09:48:34 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 7 Apr 2010 14:48:34 +0000 Subject: interop show network (was: legacy /8) In-Reply-To: References: <4BBC9215.40207@cisco.com> Message-ID: <20100407144834.GA28901@vacation.karoshi.com.> On Wed, Apr 07, 2010 at 10:12:48AM -0400, Brandon Ross wrote: > On Wed, 7 Apr 2010, Eliot Lear wrote: > > >If v6 is even close to ready, wouldn't it be sad that this sort of > >testing isn't done at interop? Or is it just sad that v6 isn't so close > >to being ready? Or is it both? > > The suggestion was to run a "v6 only network". Does anyone on the NANOG > list believe that v6 is at all ready to be run without any v4 > underpinnings and provide a real service to a customer base? > > -- > Brandon Ross very - very close. if you have fewer than 50,000 nodes in your net, and its not topologically dense, then you -can- run a native IPv6 net w/o dual stack (save on the edge translator and the DNS (and DHCP - if you have the patches)) for all of them. I've done it - on several networks. --bill From mike at mtcc.com Wed Apr 7 09:50:43 2010 From: mike at mtcc.com (Michael Thomas) Date: Wed, 07 Apr 2010 07:50:43 -0700 Subject: what about 48 bits? In-Reply-To: <201004071118.o37BIvK1022393@aurora.sol.net> References: <201004071118.o37BIvK1022393@aurora.sol.net> Message-ID: <4BBC9BC3.6090500@mtcc.com> On 04/07/2010 04:18 AM, Joe Greco wrote: > To me, this is a Dilbert-class engineering failure. I would imagine that > if you could implement a hub on the network card, the same chip(s) would > work in an external tin can with a separate power supply. Designing a > product that actually exhibits a worse failure mode than 10base2 is ... > strange to me. This reminds of me of the failure-mode-within-a-failure-mode of 10b2 with vaxstation2000's using vms's vaxcluster software. Unplugging the 10b2 gave you a window of about 10 seconds before one by one every vaxstation2000 would bugcheck. I was always rather astonished that nobody at DEC either noticed it, or thought it was a very big deal because the bug survived a long time. Mike From mike at mtcc.com Wed Apr 7 09:51:07 2010 From: mike at mtcc.com (Michael Thomas) Date: Wed, 07 Apr 2010 07:51:07 -0700 Subject: what about 48 bits? In-Reply-To: <201004071118.o37BIvK1022393@aurora.sol.net> References: <201004071118.o37BIvK1022393@aurora.sol.net> Message-ID: <4BBC9BDB.9000302@mtcc.com> On 04/07/2010 04:18 AM, Joe Greco wrote: > To me, this is a Dilbert-class engineering failure. I would imagine that > if you could implement a hub on the network card, the same chip(s) would > work in an external tin can with a separate power supply. Designing a > product that actually exhibits a worse failure mode than 10base2 is ... > strange to me. This reminds of me of the failure-mode-within-a-failure-mode of 10b2 with vaxstation2000's using vms's vaxcluster software. Unplugging the 10b2 gave you a window of about 10 seconds before one by one every vaxstation2000 would bugcheck. I was always rather astonished that nobody at DEC either noticed it, or thought it was a very big deal because the bug survived a long time. Mike From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Apr 7 09:52:46 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 8 Apr 2010 00:22:46 +0930 Subject: interop show network (was: legacy /8) In-Reply-To: References: <4BBC9215.40207@cisco.com> Message-ID: <20100408002246.20cfe5b8@opy.nosense.org> On Wed, 7 Apr 2010 10:12:48 -0400 (EDT) Brandon Ross wrote: > On Wed, 7 Apr 2010, Eliot Lear wrote: > > > If v6 is even close to ready, wouldn't it be sad that this sort of > > testing isn't done at interop? Or is it just sad that v6 isn't so close > > to being ready? Or is it both? > > The suggestion was to run a "v6 only network". Does anyone on the NANOG > list believe that v6 is at all ready to be run without any v4 > underpinnings and provide a real service to a customer base? > I do. (And no, I'm not fantasising, my day work is involving working on productising it, and mostly that's involving supplementary things, not the essentials of a providing an IPv6 capable service). > -- > Brandon Ross > From sthaug at nethelp.no Wed Apr 7 09:56:22 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 07 Apr 2010 16:56:22 +0200 (CEST) Subject: interop show network In-Reply-To: References: <4BBC9215.40207@cisco.com> Message-ID: <20100407.165622.74703341.sthaug@nethelp.no> > The suggestion was to run a "v6 only network". Does anyone on the NANOG > list believe that v6 is at all ready to be run without any v4 > underpinnings and provide a real service to a customer base? If you're an MPLS provider (as we are), the lack of IPv6 LDP is a major showstopper. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jgreco at ns.sol.net Wed Apr 7 10:03:16 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 7 Apr 2010 10:03:16 -0500 (CDT) Subject: Hubs on a NIC (was:Re: what about 48 bits?) In-Reply-To: <201004071024.51507.lowen@pari.edu> from "Lamar Owen" at Apr 07, 2010 10:24:51 AM Message-ID: <201004071503.o37F3HPI030585@aurora.sol.net> > On Wednesday 07 April 2010 07:18:57 am Joe Greco wrote: > > To me, this is a Dilbert-class engineering failure. I would imagine that > > if you could implement a hub on the network card, the same chip(s) would > > work in an external tin can with a separate power supply. Designing a > > product that actually exhibits a worse failure mode than 10base2 is ... > > strange to me. > > I have in my gear museum a fairly large box with a couple of this type of 'hub > on a card' installed. And in this particular case, it made perfect sense, as > the box is an Evergreen Systems CAPserver, and has 16 486 single-board > computers tied to two 8-port hub cards (two ports on each modular plug, too), > with....wait for it... a 10Base-2 uplink. These were used mostly for remote > network access and remote desktop access. > > If you want more data on this old and odd box, see > http://www.bomara.com/Eversys/capserver2300.htm > > I can see a hub card being useful in an old NetWare server setting, though, > since if the server went down you might as well not have a network in the first > place, in that use case. Certainly. I can come up with a bunch of reasonable-use scenarios too, but most of the people here will have run into that awful situation where a product is used in a manner that isn't "Recommended". In this case, I know that some of these cards were marketed in the same manner that workgroup hubs/switches are marketed; you would daisy-chain these stupid things so that your PC would feed the cubes right around you and then have an uplink and downlink a few cubes to the next "hub". Remember, it was this strange time when people were uncertain about how networks were going to evolve, and what the next thing would be, and even then, 10baseT was being deployed over Cat3 (sometimes recycled/ repurposed), so any sort of "enabling" gadget such as these cards had a tendency to be abused in various ways. Two ports on each modular plug, though.... (shudder) ;-) ... 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 tim at pelican.org Wed Apr 7 10:06:41 2010 From: tim at pelican.org (Tim Franklin) Date: Wed, 7 Apr 2010 15:06:41 +0000 (GMT) Subject: what about 48 bits? In-Reply-To: <5778892.01270652655911.JavaMail.root@jennyfur.pelican.org> Message-ID: <31616530.21270652801888.JavaMail.root@jennyfur.pelican.org> > This reminds of me of the failure-mode-within-a-failure-mode of 10b2 > with vaxstation2000's using vms's vaxcluster software. Unplugging the > 10b2 gave you a window of about 10 seconds before one by one every > vaxstation2000 would bugcheck. I was always rather astonished that > nobody at DEC either noticed it, or thought it was a very big deal > because the bug survived a long time. I thought that was just me. My first IT job was developing credit-card systems on VAXen. We had the office flood-wired with 10base2 in one long bus - at locations where there wasn't a PC yet, there was just a faceplace with two BNC connectors, and a tiny patch lead between them. To install a new PC, you had to have a length of co-ax long enough to go from the faceplate to the desk and back, with a T-piece in the middle. Installation involved whipping out the short patch lead and re-connecting both ends of the longer one before things elsewhere declared the network as broken and started shutting down somewhat ungracefully. This was best done as a two-man job, but we did get it down to quite an art. Nice to know after all this time that someone else was playing the same silly game... Regards, Tim. From bicknell at ufp.org Wed Apr 7 10:12:27 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 7 Apr 2010 08:12:27 -0700 Subject: interop show network (was: legacy /8) In-Reply-To: References: <4BBC9215.40207@cisco.com> Message-ID: <20100407151227.GA40049@ussenterprise.ufp.org> In a message written on Wed, Apr 07, 2010 at 10:12:48AM -0400, Brandon Ross wrote: > The suggestion was to run a "v6 only network". Does anyone on the NANOG > list believe that v6 is at all ready to be run without any v4 > underpinnings and provide a real service to a customer base? Is it ready, absolutely. Is it pretty, not quite. But that's ok, it will take some time in the real world to get the spit polish IPv4 has had 25+ years to earn. The issue is not is IPv6 ready, it's how do you interoperate between the IPv6 world and the IPv4 world. Dual stack was/is the answer, but with IPv4 running out it won't be for much longer. Is the answer a transition mechanism or cold turkey? It probably depends on your situation. -- 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 chrisy at flix.net Wed Apr 7 10:13:18 2010 From: chrisy at flix.net (Chris Luke) Date: Wed, 7 Apr 2010 10:13:18 -0500 Subject: IPv6 Newbie In-Reply-To: References: Message-ID: <20100407151318.GA23727@flix.net> Ricky Beam wrote (on Apr 06): > On Tue, 06 Apr 2010 03:20:26 -0400, shake righa wrote: > >Can one subnet to include /127 for point to point connections? > > That's the equiv of a /31 in IPv4. Do you use /31's for p-t-p links > in your IPv4 network(s)? > > (Yes, I've used /31's before, but only to represent 2 /32's. And > even that was silly.) We use /31 (v4) and /127 (v6) for internal PtPs in our mostly-vendor-C network with no special tweaks or odd behaviour. YMMV. There was a talk at the Austin NANOG on this. I asked the audience in a straw-poll what their PtP v6 netmask preferences were - resoundingly audience support was for /127's. Chris. From ops.lists at gmail.com Wed Apr 7 10:17:53 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 7 Apr 2010 20:47:53 +0530 Subject: FCC dealt major blow in net neutrality ruling favoring Comcast In-Reply-To: References: <42DF9B4B-8614-43F9-802D-9586AA7AD0FB@ianai.net> <20100407235116.7773cab2@opy.nosense.org> Message-ID: On Wed, Apr 7, 2010 at 8:12 PM, Chris Grundemann wrote: > They are now using the phrase "Open > Internetworking" to describe their stance on the issue. How very sensible of ISOC. -- Suresh Ramasubramanian (ops.lists at gmail.com) From jack at crepinc.com Wed Apr 7 10:34:03 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Wed, 7 Apr 2010 11:34:03 -0400 Subject: Best Practice: 2routers, 2isp, 1AS In-Reply-To: <017265BF3B9640499754DD48777C3D206859F8F96D@MBX9.EXCHPROD.USA.NET> References: <8BCB5625-633C-4786-93DA-F0715D8015B0@mac.com> <017265BF3B9640499754DD48777C3D206859F8F96D@MBX9.EXCHPROD.USA.NET> Message-ID: Could also just push default into OSPF from both ends (assuming you have the iBGP between both borders) if your goal is redundancy. -Jack Carrozzo On Wed, Apr 7, 2010 at 10:06 AM, Dylan Ebner wrote: > You can still use vrrp in the inside. We have a similar configuration to what you have defined. Two routers, 4 ISPs, BGP annoucing 2 /24's. We get partial routes and prepend on 3 of the isps to only use our primary. Our primary is delivered via fiber and the backup isps are delivered via copper ethernet. We use interface tracking with reachability to determine if we are having a problem with one of our downstreams. This way, if we still have a link light, but no traffic flow we can detect and adjust accordingly. > > > > Dylan > > -----Original Message----- > From: Beavis [mailto:pfunix at gmail.com] > Sent: Wednesday, April 07, 2010 12:42 AM > To: nanog at nanog.org > Subject: Re: Best Practice: 2routers, 2isp, 1AS > > thanks for the reply brian. :) > > sorry for a bit lack on the info, I was thinking of using VRRP. but my > 2 links are running on different interface-types isp1 runs via > ethernet while the other is on an ATM interface. I only have 1 router > that has an ATM interface. setting it to VRRP would cause me problems > if it was a physical failure. I have a small /24 to advertise on my > AS. I'll go and check on the "Performance Based Routing" you > recommend. > > > thanks, > -b > > On Tue, Apr 6, 2010 at 11:25 PM, Brian Feeny wrote: >> >> There are alot more questions that need to be asked. ?Like how much address space do you have to announce? What routes are you getting from each ISP? >> >> Assuming you are an end user, and knowing the very limited information I know at this point, I would make sure that these two routers LAN interfaces are in some sort of transit vlan/subnet with my downstream router, which would also be participating in iBGP. ?Alternately you could have that router do VRRP/HSRP with your two border routers, but I prefer iBGP. >> >> I would then setup both routers using OER (Optimized Edge Routing, i think now known as Performance Based Routing), to handle outbound. ?You could just announce your /24 out each provider (assuming that's what you had) to handle inbound, or if you have larger than that you could announce the aggregate out both and more specifics out each to do some type of balancing. >> >> Its hard to say there is a best practice here, as there are so many scenarios. ?I will say that I like OeR/PfR for edge customers who are dual homed. ?BGP is very arbitrary, and its nice to have some real metrics that mean something to play with :) >> >> Brian >> >> >> On Apr 7, 2010, at 1:14 AM, Beavis wrote: >> >>> Greetings! >>> >>> ? Want to ask out anybody on the list about a "best practice" of the >>> setup below: >>> >>> - 2 ISP's (A & B) >>> - 2 Routers (A & B) >>> >>> I want Router-A for ISP-A, Router-B for ISP-B and have Router-A & >>> Router-B talk and be able to pass routes on each side in an event of a >>> physical failure on one of the Routers. >>> >>> I was planning at first to setup a multi-home BGP, but I want to have >>> physical redundancy as well. >>> >>> ASCII-diag >>> >>> =--[RouterA]--isp1(bgp) >>> L ? ?| >>> A ? iBGP >>> N ? ?| >>> =--[RouterB]--isp2(bgp) >>> >>> Any recommendation would awesomely appreciated. >>> >>> -B >>> >>> >>> -- >>> () ?ascii ribbon campaign - against html e-mail >>> /\ ?www.asciiribbon.org ? - against proprietary attachments >>> >> >> > > > > -- > () ?ascii ribbon campaign - against html e-mail > /\ ?www.asciiribbon.org ? - against proprietary attachments > > > > From jgreco at ns.sol.net Wed Apr 7 10:47:50 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 7 Apr 2010 10:47:50 -0500 (CDT) Subject: what about 48 bits? In-Reply-To: <31616530.21270652801888.JavaMail.root@jennyfur.pelican.org> from "Tim Franklin" at Apr 07, 2010 03:06:41 PM Message-ID: <201004071547.o37FlpTN032000@aurora.sol.net> > I thought that was just me. My first IT job was developing credit- > card systems on VAXen. We had the office flood-wired with 10base2 > in one long bus - at locations where there wasn't a PC yet, there > was just a faceplace with two BNC connectors, and a tiny patch > lead between them. > > To install a new PC, you had to have a length of co-ax long enough > to go from the faceplate to the desk and back, with a T-piece in > the middle. Installation involved whipping out the short patch > lead and re-connecting both ends of the longer one before things > elsewhere declared the network as broken and started shutting down > somewhat ungracefully. This was best done as a two-man job, but > we did get it down to quite an art. > > Nice to know after all this time that someone else was playing the > same silly game... There were several proprietary solutions to the 10base2 conundrum, I can't remember the name of the one I was most familiar with, but it eliminated all that stuff by using a molded cable that had a BNC on one end, contained dual RG cables inside a heavy jacket, and a funky molded plug on the end. The plug would connect to a socket through which a 10base2 segment ran, and inserting the plug would open a switch that shorted the conductors, and then the cable would form the link to re-complete the segment. Much fun was to be had: 1) Plugging in a network cable partway might break the circuit without also establishing the new path, 2) Sometimes the sockets would get fouled and locating the problem was a royal pain, 3) Because the system was meant to be simple enough for users to use, users would sometimes plug in too many of these cables, extending the maximum length of the network beyond standard, 4) Also because users could be involved, when one of them did something to the network, they would either not realize it or not own up to it, further adding to the debugging fun. When it worked, it worked great. Which was most of the time. I used to remember what the darn things were called... ... 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 dylan.ebner at crlmed.com Wed Apr 7 10:48:05 2010 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Wed, 7 Apr 2010 15:48:05 +0000 Subject: Best Practice: 2routers, 2isp, 1AS In-Reply-To: References: <8BCB5625-633C-4786-93DA-F0715D8015B0@mac.com> <017265BF3B9640499754DD48777C3D206859F8F96D@MBX9.EXCHPROD.USA.NET> Message-ID: <017265BF3B9640499754DD48777C3D206859F8FA65@MBX9.EXCHPROD.USA.NET> Jack- We did discuss this when designing our solution. In then end we decided not to introduce another routing protocol to our enviornment. We rely exclusivly on BGP and EIGRP. It may not be the best solution, but servicability is also important. Dylan -----Original Message----- From: Jack Carrozzo [mailto:jack at crepinc.com] Sent: Wednesday, April 07, 2010 10:34 AM To: Dylan Ebner Cc: Beavis; nanog at nanog.org Subject: Re: Best Practice: 2routers, 2isp, 1AS Could also just push default into OSPF from both ends (assuming you have the iBGP between both borders) if your goal is redundancy. -Jack Carrozzo On Wed, Apr 7, 2010 at 10:06 AM, Dylan Ebner wrote: > You can still use vrrp in the inside. We have a similar configuration to what you have defined. Two routers, 4 ISPs, BGP annoucing 2 /24's. We get partial routes and prepend on 3 of the isps to only use our primary. Our primary is delivered via fiber and the backup isps are delivered via copper ethernet. We use interface tracking with reachability to determine if we are having a problem with one of our downstreams. This way, if we still have a link light, but no traffic flow we can detect and adjust accordingly. > > > > Dylan > > -----Original Message----- > From: Beavis [mailto:pfunix at gmail.com] > Sent: Wednesday, April 07, 2010 12:42 AM > To: nanog at nanog.org > Subject: Re: Best Practice: 2routers, 2isp, 1AS > > thanks for the reply brian. :) > > sorry for a bit lack on the info, I was thinking of using VRRP. but my > 2 links are running on different interface-types isp1 runs via > ethernet while the other is on an ATM interface. I only have 1 router > that has an ATM interface. setting it to VRRP would cause me problems > if it was a physical failure. I have a small /24 to advertise on my > AS. I'll go and check on the "Performance Based Routing" you > recommend. > > > thanks, > -b > > On Tue, Apr 6, 2010 at 11:25 PM, Brian Feeny wrote: >> >> There are alot more questions that need to be asked. ?Like how much address space do you have to announce? What routes are you getting from each ISP? >> >> Assuming you are an end user, and knowing the very limited information I know at this point, I would make sure that these two routers LAN interfaces are in some sort of transit vlan/subnet with my downstream router, which would also be participating in iBGP. ?Alternately you could have that router do VRRP/HSRP with your two border routers, but I prefer iBGP. >> >> I would then setup both routers using OER (Optimized Edge Routing, i think now known as Performance Based Routing), to handle outbound. ?You could just announce your /24 out each provider (assuming that's what you had) to handle inbound, or if you have larger than that you could announce the aggregate out both and more specifics out each to do some type of balancing. >> >> Its hard to say there is a best practice here, as there are so many scenarios. ?I will say that I like OeR/PfR for edge customers who are dual homed. ?BGP is very arbitrary, and its nice to have some real metrics that mean something to play with :) >> >> Brian >> >> >> On Apr 7, 2010, at 1:14 AM, Beavis wrote: >> >>> Greetings! >>> >>> ? Want to ask out anybody on the list about a "best practice" of the >>> setup below: >>> >>> - 2 ISP's (A & B) >>> - 2 Routers (A & B) >>> >>> I want Router-A for ISP-A, Router-B for ISP-B and have Router-A & >>> Router-B talk and be able to pass routes on each side in an event of a >>> physical failure on one of the Routers. >>> >>> I was planning at first to setup a multi-home BGP, but I want to have >>> physical redundancy as well. >>> >>> ASCII-diag >>> >>> =--[RouterA]--isp1(bgp) >>> L ? ?| >>> A ? iBGP >>> N ? ?| >>> =--[RouterB]--isp2(bgp) >>> >>> Any recommendation would awesomely appreciated. >>> >>> -B >>> >>> >>> -- >>> () ?ascii ribbon campaign - against html e-mail >>> /\ ?www.asciiribbon.org ? - against proprietary attachments >>> >> >> > > > > -- > () ?ascii ribbon campaign - against html e-mail > /\ ?www.asciiribbon.org ? - against proprietary attachments > > > > From lowen at pari.edu Wed Apr 7 10:51:12 2010 From: lowen at pari.edu (Lamar Owen) Date: Wed, 7 Apr 2010 11:51:12 -0400 Subject: /31's again (Re: IPv6 Newbie) In-Reply-To: References: Message-ID: <201004071151.12813.lowen@pari.edu> On Tuesday 06 April 2010 08:10:14 pm Ricky Beam wrote: > That's the equiv of a /31 in IPv4. Do you use /31's for p-t-p links in > your IPv4 network(s)? Yes, like many others (there was a thread on this on NANOG towards the end of January, no? Yes; started 1/22/2010 by Seth Mattinen; I don't have a link to an archive entry, because I have it in my own archives here). It's amazing how many 'subnetting reference guides' I've found out there that go as far as stating that /31's aren't even legal.... they'd really fall over if they saw how I was using a /27's broadcast address as one end of a /31 in one particular instance.... :-) RFC 3021, man, RFC 3021. From pfunix at gmail.com Wed Apr 7 11:00:15 2010 From: pfunix at gmail.com (Beavis) Date: Wed, 7 Apr 2010 10:00:15 -0600 Subject: Best Practice: 2routers, 2isp, 1AS In-Reply-To: <017265BF3B9640499754DD48777C3D206859F8F96D@MBX9.EXCHPROD.USA.NET> References: <8BCB5625-633C-4786-93DA-F0715D8015B0@mac.com> <017265BF3B9640499754DD48777C3D206859F8F96D@MBX9.EXCHPROD.USA.NET> Message-ID: I'll do some digging on "interface tracking" for cisco gear. thanks On Wed, Apr 7, 2010 at 8:06 AM, Dylan Ebner wrote: > You can still use vrrp in the inside. We have a similar configuration to what you have defined. Two routers, 4 ISPs, BGP annoucing 2 /24's. We get partial routes and prepend on 3 of the isps to only use our primary. Our primary is delivered via fiber and the backup isps are delivered via copper ethernet. We use interface tracking with reachability to determine if we are having a problem with one of our downstreams. This way, if we still have a link light, but no traffic flow we can detect and adjust accordingly. > > > > Dylan > > -----Original Message----- > From: Beavis [mailto:pfunix at gmail.com] > Sent: Wednesday, April 07, 2010 12:42 AM > To: nanog at nanog.org > Subject: Re: Best Practice: 2routers, 2isp, 1AS > > thanks for the reply brian. :) > > sorry for a bit lack on the info, I was thinking of using VRRP. but my > 2 links are running on different interface-types isp1 runs via > ethernet while the other is on an ATM interface. I only have 1 router > that has an ATM interface. setting it to VRRP would cause me problems > if it was a physical failure. I have a small /24 to advertise on my > AS. I'll go and check on the "Performance Based Routing" you > recommend. > > > thanks, > -b > > On Tue, Apr 6, 2010 at 11:25 PM, Brian Feeny wrote: >> >> There are alot more questions that need to be asked. ?Like how much address space do you have to announce? What routes are you getting from each ISP? >> >> Assuming you are an end user, and knowing the very limited information I know at this point, I would make sure that these two routers LAN interfaces are in some sort of transit vlan/subnet with my downstream router, which would also be participating in iBGP. ?Alternately you could have that router do VRRP/HSRP with your two border routers, but I prefer iBGP. >> >> I would then setup both routers using OER (Optimized Edge Routing, i think now known as Performance Based Routing), to handle outbound. ?You could just announce your /24 out each provider (assuming that's what you had) to handle inbound, or if you have larger than that you could announce the aggregate out both and more specifics out each to do some type of balancing. >> >> Its hard to say there is a best practice here, as there are so many scenarios. ?I will say that I like OeR/PfR for edge customers who are dual homed. ?BGP is very arbitrary, and its nice to have some real metrics that mean something to play with :) >> >> Brian >> >> >> On Apr 7, 2010, at 1:14 AM, Beavis wrote: >> >>> Greetings! >>> >>> ? Want to ask out anybody on the list about a "best practice" of the >>> setup below: >>> >>> - 2 ISP's (A & B) >>> - 2 Routers (A & B) >>> >>> I want Router-A for ISP-A, Router-B for ISP-B and have Router-A & >>> Router-B talk and be able to pass routes on each side in an event of a >>> physical failure on one of the Routers. >>> >>> I was planning at first to setup a multi-home BGP, but I want to have >>> physical redundancy as well. >>> >>> ASCII-diag >>> >>> =--[RouterA]--isp1(bgp) >>> L ? ?| >>> A ? iBGP >>> N ? ?| >>> =--[RouterB]--isp2(bgp) >>> >>> Any recommendation would awesomely appreciated. >>> >>> -B >>> >>> >>> -- >>> () ?ascii ribbon campaign - against html e-mail >>> /\ ?www.asciiribbon.org ? - against proprietary attachments >>> >> >> > > > > -- > () ?ascii ribbon campaign - against html e-mail > /\ ?www.asciiribbon.org ? - against proprietary attachments > > > -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From stb at lassitu.de Wed Apr 7 11:06:42 2010 From: stb at lassitu.de (Stefan Bethke) Date: Wed, 7 Apr 2010 18:06:42 +0200 Subject: what about 48 bits? In-Reply-To: <201004071547.o37FlpTN032000@aurora.sol.net> References: <201004071547.o37FlpTN032000@aurora.sol.net> Message-ID: <6B612F55-0543-4E1C-A203-23AF6A3E1D82@lassitu.de> Am 07.04.2010 um 17:47 schrieb Joe Greco: > There were several proprietary solutions to the 10base2 conundrum, > I can't remember the name of the one I was most familiar with, but it > eliminated all that stuff by using a molded cable that had a BNC on > one end, contained dual RG cables inside a heavy jacket, and a funky > molded plug on the end. One system popular in Germany at the time used a modified German phone plug ("TAE"), and the resulting system was marketed as "EAD" or Ethernet Anschluss Dose. The coax was way too heavy and stiff for the small plug, and would regularly unseat the connector. Since the phone plug was never designed to have a defined impedance, any run longer than about 50 meters for the segment was hit and miss. http://en.wikipedia.org/wiki/EAD-socket Stefan -- Stefan Bethke Fon +49 151 14070811 From nanog2 at adns.net Wed Apr 7 11:09:30 2010 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Wed, 7 Apr 2010 11:09:30 -0500 Subject: ARIN IP6 policy for those with legacy IP4 Space Message-ID: <18459664B284412885743075C7E0C621@TAKA> Was looking at the ARIN IP6 policy and cannot find any reference to those who have IP4 legacy space. Isn't there an automatic allocation for those of us who have legacy IP space. If not, is ARIN saying we have to pay them a fee to use IP6? Isn't this a disincentive for us to move up to IP6? Those with legacy IP4 space should have the equivalent IP6 space under the same terms. Or am I missing something? From Jeff-Kell at utc.edu Wed Apr 7 11:10:23 2010 From: Jeff-Kell at utc.edu (Jeff Kell) Date: Wed, 07 Apr 2010 12:10:23 -0400 Subject: what about 48 bits? Message-ID: <1270656623.9afd837cJeff-Kell@utc.edu> That would be the AMP quick connect kit. Been there, done that, got the scars and war stories too. The most notable was that the "drops" from the actual coax down to the end-stations were of a non-trivial length, and the actual length added to your coax segment was double that (due to the loop out to the end-station). We had several cases of segments getting "too long" unexpectedly, and some green techs hooking up 3-4 drops in their new office areas at the same time (adding ~100' to your run)... Jeff -----Original Message----- From: Joe Greco There were several proprietary solutions to the 10base2 conundrum, I can't remember the name of the one I was most familiar with, but it eliminated all that stuff by using a molded cable that had a BNC on one end, contained dual RG cables inside a heavy jacket, and a funky molded plug on the end. The plug would connect to a socket through which a 10base2 segment ran, and inserting the plug would open a switch that shorted the conductors, and then the cable would form the link to re-complete the segment. From bill at herrin.us Wed Apr 7 11:22:15 2010 From: bill at herrin.us (William Herrin) Date: Wed, 7 Apr 2010 12:22:15 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <18459664B284412885743075C7E0C621@TAKA> References: <18459664B284412885743075C7E0C621@TAKA> Message-ID: On Wed, Apr 7, 2010 at 12:09 PM, John Palmer (NANOG Acct) wrote: > Was looking at the ARIN IP6 policy and cannot find any reference to those > who have > IP4 legacy space. > > Isn't there an automatic allocation for those of us who have legacy IP > space. If not, is ARIN > saying we have to pay them a fee to use IP6? ?Isn't this a disincentive for > us to move up to IP6? > > Those with legacy IP4 space should have the equivalent IP6 space under the > same terms. Or am I missing something? Hi John, The game is: Sign ARIN's "Legacy RSA" covering your legacy space. With the LRSA you retain more rights than folks who sign the regular RSA, but probably less rights than you have now. Pay your $100/year as an end-user. You now qualify for an IPv6 assignment under ARIN NRPM 6.5.8.1b regardless of the size of your network. Pay the $1250 IPv6 initial assignment fee. For better or for worse, you're not going to get IPv6 space under the "same terms" as your legacy IPv4 space. You got a really good deal on IPv4. Try not to be too disappointed that the same deal isn't available with IPv6. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nick at foobar.org Wed Apr 7 11:23:31 2010 From: nick at foobar.org (Nick Hilliard) Date: Wed, 07 Apr 2010 17:23:31 +0100 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <18459664B284412885743075C7E0C621@TAKA> References: <18459664B284412885743075C7E0C621@TAKA> Message-ID: <4BBCB183.2070400@foobar.org> On 07/04/2010 17:09, John Palmer (NANOG Acct) wrote: > Was looking at the ARIN IP6 policy and cannot find any reference to > those who have IP4 legacy space. > > Isn't there an automatic allocation for those of us who have legacy IP > space. If not, is ARIN saying we have to pay them a fee to use IP6? > Isn't this a disincentive for us to move up to IP6? > > Those with legacy IP4 space should have the equivalent IP6 space under > the same terms. Or am I missing something? Yes. You're 6 days late. Nick From tony at lava.net Wed Apr 7 11:26:26 2010 From: tony at lava.net (Antonio Querubin) Date: Wed, 7 Apr 2010 06:26:26 -1000 (HST) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <18459664B284412885743075C7E0C621@TAKA> References: <18459664B284412885743075C7E0C621@TAKA> Message-ID: On Wed, 7 Apr 2010, John Palmer \(NANOG Acct\) wrote: > Was looking at the ARIN IP6 policy and cannot find any reference to > those who have IP4 legacy space. > > Isn't there an automatic allocation for those of us who have legacy IP > space. Nope. > If not, is ARIN saying we have to pay them a fee to use IP6? Yep. > Isn't this a disincentive for us to move up to IP6? Yep. Just went through this with one organization which I hadn't realized at the time was a legacy IPv4 holder. The fees were a surprise (I thought they'd already been paying those fees). Needless to say, their IPv6 plans are on hold indefinitely. > Those with legacy IP4 space should have the equivalent IP6 space under > the same terms. Or am I missing something? But they're not exactly the same terms. ARIN 'terms' for the legacy holder probably didn't exist at the time of their IPv4 allocation. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From aaron at wholesaleinternet.net Wed Apr 7 11:27:01 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Wed, 7 Apr 2010 11:27:01 -0500 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <18459664B284412885743075C7E0C621@TAKA> References: <18459664B284412885743075C7E0C621@TAKA> Message-ID: <030201cad66f$26d11130$74733390$@net> There was talk a little while ago about a fee waiver for legacy holders who had signed an RSA but I think it's still in the suggestion phase. To get v6 space now you would need to sign an RSA for the v6 space and pay the v6 fee's. There is a partial fee waiver in effect for ISP v6 allocations. No fee waiver for end user v6 allocations. As for being a disincentive, only you can answer whether your network needs justify a v6 allocation or whether or not v4 will service you. Aaron -----Original Message----- From: John Palmer (NANOG Acct) [mailto:nanog2 at adns.net] Sent: Wednesday, April 07, 2010 11:10 AM To: NANOG list Subject: ARIN IP6 policy for those with legacy IP4 Space Was looking at the ARIN IP6 policy and cannot find any reference to those who have IP4 legacy space. Isn't there an automatic allocation for those of us who have legacy IP space. If not, is ARIN saying we have to pay them a fee to use IP6? Isn't this a disincentive for us to move up to IP6? Those with legacy IP4 space should have the equivalent IP6 space under the same terms. Or am I missing something? No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.800 / Virus Database: 271.1.1/2792 - Release Date: 04/07/10 01:32:00 From Valdis.Kletnieks at vt.edu Wed Apr 7 11:28:39 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 07 Apr 2010 12:28:39 -0400 Subject: interop show network (was: legacy /8) In-Reply-To: Your message of "Wed, 07 Apr 2010 16:09:25 +0200." <4BBC9215.40207@cisco.com> References: <4BBC9215.40207@cisco.com> Message-ID: <8863.1270657719@localhost> On Wed, 07 Apr 2010 16:09:25 +0200, Eliot Lear said: > them). If v6 is even close to ready, wouldn't it be sad that this sort > of testing isn't done at interop? Interop long ago ceased being a interop shootout and became a 8x11 color glossy trade show. I think the last time any actual *testing* happened at Interop, the guys hooking up the network drops were wearing t-shirts that said "Yes, the subnet mask really *is* 255.255.252.0", and anybody who whined that their gear only supported octet-boundary subnets was told "And next year, it will be 255.255.250.0". :) Anybody got production gear that *still* doesn't do non-octet-boundary subnets? -------------- 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 Wed Apr 7 11:49:33 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 7 Apr 2010 09:49:33 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <18459664B284412885743075C7E0C621@TAKA> Message-ID: On Apr 7, 2010, at 9:22 AM, William Herrin wrote: > On Wed, Apr 7, 2010 at 12:09 PM, John Palmer (NANOG Acct) > wrote: >> Was looking at the ARIN IP6 policy and cannot find any reference to those >> who have >> IP4 legacy space. >> >> Isn't there an automatic allocation for those of us who have legacy IP >> space. If not, is ARIN >> saying we have to pay them a fee to use IP6? Isn't this a disincentive for >> us to move up to IP6? >> >> Those with legacy IP4 space should have the equivalent IP6 space under the >> same terms. Or am I missing something? > > Hi John, > > The game is: > > Sign ARIN's "Legacy RSA" covering your legacy space. With the LRSA you > retain more rights than folks who sign the regular RSA, but probably > less rights than you have now. > More accurately, you retain more rights than the standard RSA and you move from a situation where your exact rights are unknown and undetermined with no contractual relationship between you and ARIN to a situation where your rights are assured, enumerated, and a contractual relationship exists between you and ARIN governing the services you are receiving from ARIN. > Pay your $100/year as an end-user. You now qualify for an IPv6 > assignment under ARIN NRPM 6.5.8.1b regardless of the size of your > network. > > Pay the $1250 IPv6 initial assignment fee. > This is correct. I would like to see initial registration fee waivers for IPv6 end-user assignments. I've brought the subject up on arin-discuss. There was substantial opposition to the idea. If you would like to see that happen, I encourage you to voice your opinion there. > > For better or for worse, you're not going to get IPv6 space under the > "same terms" as your legacy IPv4 space. You got a really good deal on > IPv4. Try not to be too disappointed that the same deal isn't > available with IPv6. > Well said, Bill. Owen From nonobvious at gmail.com Wed Apr 7 12:47:08 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Wed, 7 Apr 2010 10:47:08 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <18459664B284412885743075C7E0C621@TAKA> Message-ID: >>> Isn't there an automatic allocation for those of us who have legacy IP >>> space. If not, is ARIN saying we have to pay them a fee to use IP6? >>>?Isn't this a disincentive for us to move up to IP6? If you're a very small company looking for larger than /32, maybe it's an issue. If you're a medium-large company and /48 or /32 is enough, the decision looks like this - Option 1 - Pay the annoying fee, which is less than a week's pay for a senior engineer. - Option 2 - Allocate 160 hours of meeting time (50% scheduled, 50% ad-hoc), spread over 18 months, for one senior engineer, two junior engineers, one mid-level manager, two upper level managers, three accounting trolls, 18 reams of printer paper, six pots of coffee, optional doughnuts. Most companies prefer the latter approach, but you don't have to be one of them. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From heather.schiller at verizonbusiness.com Wed Apr 7 13:02:12 2010 From: heather.schiller at verizonbusiness.com (Schiller, Heather A (HeatherSkanks)) Date: Wed, 07 Apr 2010 18:02:12 +0000 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <18459664B284412885743075C7E0C621@TAKA> References: <18459664B284412885743075C7E0C621@TAKA> Message-ID: ARIN Region IPv6 fee waiver: https://www.arin.net/fees/fee_schedule.html#waivers "In Jan 2008, the Board of Trustees decided to reduce the fee waiver incrementally over a period of 4 years. Full fees will be in effect in 2012." Can you provide rationalization why anyone should automatically get any kind of allocation? Or why legacy holders should "have equivalent [IPv6] space under the same terms" You can read through past iterations of this discussion over in the PPML archives. --Heather -----Original Message----- From: John Palmer (NANOG Acct) [mailto:nanog2 at adns.net] Sent: Wednesday, April 07, 2010 12:10 PM To: NANOG list Subject: ARIN IP6 policy for those with legacy IP4 Space Was looking at the ARIN IP6 policy and cannot find any reference to those who have IP4 legacy space. Isn't there an automatic allocation for those of us who have legacy IP space. If not, is ARIN saying we have to pay them a fee to use IP6? Isn't this a disincentive for us to move up to IP6? Those with legacy IP4 space should have the equivalent IP6 space under the same terms. Or am I missing something? From jeroen at mompl.net Wed Apr 7 13:39:09 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 07 Apr 2010 11:39:09 -0700 Subject: Finding content in your job title In-Reply-To: <201004021313.31080.lowen@pari.edu> References: <201004021313.31080.lowen@pari.edu> Message-ID: <4BBCD14D.4070305@mompl.net> Lamar Owen wrote: > companies, Official Title is used to determine salary (or even whether you're an > exempt employee or not). And the company's bylaws may invest particular Unless I misread the laws regarding this, in CA at least you still have to earn ~$40/hr or more (it varies and last I read it was lowered a few $s) or more to be considered exempt, regardless of your job title From LarrySheldon at cox.net Wed Apr 7 13:48:43 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 07 Apr 2010 13:48:43 -0500 Subject: Finding content in your job title In-Reply-To: <4BBCD14D.4070305@mompl.net> References: <201004021313.31080.lowen@pari.edu> <4BBCD14D.4070305@mompl.net> Message-ID: <4BBCD38B.9010509@cox.net> On 4/7/2010 13:39, Jeroen van Aart wrote: > Lamar Owen wrote: >> companies, Official Title is used to determine salary (or even whether you're an >> exempt employee or not). And the company's bylaws may invest particular > > Unless I misread the laws regarding this, in CA at least you still have > to earn ~$40/hr or more (it varies and last I read it was lowered a few > $s) or more to be considered exempt, regardless of your job title When I was a manager out thee some years ago, you also had to have substantial control over your activities. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From jeroen at mompl.net Wed Apr 7 13:50:14 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 07 Apr 2010 11:50:14 -0700 Subject: XO Communications rDNS Message-ID: <4BBCD3E6.3060403@mompl.net> I manage some IP space that's provided by an ISP but is "owned" by XO. I am trying to have rDNS configured but their contact email (ipadmin at eng.xo.com) in the whois does not grace me with a response (yet). Does anyone know if there is a way to get this done or should I just not bother and live with it? Thanks, Jeroen From sparctacus at gmail.com Wed Apr 7 13:57:21 2010 From: sparctacus at gmail.com (Bryan Irvine) Date: Wed, 7 Apr 2010 11:57:21 -0700 Subject: XO Communications rDNS In-Reply-To: <4BBCD3E6.3060403@mompl.net> References: <4BBCD3E6.3060403@mompl.net> Message-ID: Call their tech support line. You can either just give them the name you want the rDNS to have or have them delegate the range to you. I've done both with them in the past and tech support was able to handle it. -Bryan On Wed, Apr 7, 2010 at 11:50 AM, Jeroen van Aart wrote: > I manage some IP space that's provided by an ISP but is "owned" by XO. I am > trying to have rDNS configured but their contact email (ipadmin at eng.xo.com) > in the whois does not grace me with a response (yet). > > Does anyone know if there is a way to get this done or should I just not > bother and live with it? > > Thanks, > Jeroen > > From jeroen at mompl.net Wed Apr 7 14:09:40 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 07 Apr 2010 12:09:40 -0700 Subject: Finding content in your job title In-Reply-To: <4BBCD38B.9010509@cox.net> References: <201004021313.31080.lowen@pari.edu> <4BBCD14D.4070305@mompl.net> <4BBCD38B.9010509@cox.net> Message-ID: <4BBCD874.8040507@mompl.net> Larry Sheldon wrote: > On 4/7/2010 13:39, Jeroen van Aart wrote: >> Unless I misread the laws regarding this, in CA at least you still have >> to earn ~$40/hr or more (it varies and last I read it was lowered a few >> $s) or more to be considered exempt, regardless of your job title > When I was a manager out thee some years ago, you also had to have > substantial control over your activities. Yes, and it has to be of a special "intellectual" nature (for lack of better terms). I would think just a fancy job title, but no duties to reflect it, would not stand a chance at all if the employee would legally challenge their supposedly exempt status. Anyways, http://www.dir.ca.gov/dlse/Glossary.asp?Button1=E#employee%20in%20the%20computer%20software%20field explains it fairly well. "The employee's hourly rate of pay is not less than $41.00 [the rate in effect on September 19, 2000]". The rate according to their provided pdf is not less than $37.94 or not less than $79050.- annually. Regards, Jeroen From kevin at steadfast.net Wed Apr 7 14:47:59 2010 From: kevin at steadfast.net (Kevin Stange) Date: Wed, 07 Apr 2010 14:47:59 -0500 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <18459664B284412885743075C7E0C621@TAKA> Message-ID: <4BBCE16F.40504@steadfast.net> On 04/07/2010 11:26 AM, Antonio Querubin wrote: > On Wed, 7 Apr 2010, John Palmer \(NANOG Acct\) wrote: >> Isn't this a disincentive for us to move up to IP6? > > Yep. Just went through this with one organization which I hadn't > realized at the time was a legacy IPv4 holder. The fees were a surprise > (I thought they'd already been paying those fees). Needless to say, > their IPv6 plans are on hold indefinitely. How much IPv6 address space were they expecting? I have trouble envisioning any operation that could require more than a /32 immediately that can't afford to pay $4500 per YEAR. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From jeroen at mompl.net Wed Apr 7 14:56:38 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 07 Apr 2010 12:56:38 -0700 Subject: interop show network In-Reply-To: References: Message-ID: <4BBCE376.7090304@mompl.net> Christopher Morrow wrote: > also, see previous 12 episodes of this conversation.. 1 /8 == ~3months > in ARIN allocation timeframes. > > There is no cure, pls to be rolling out IPv6 2 years ago. Yes I understand. But a show like that going IPv6 only could provide some sort of incentive. And at the same time you gain the goodwill and comfy feeling of having returned a /8. And I am sure that the people designing the network are able to find a solution for those without IPv6 aware equipment to still get connectivity. Regards, Jeroen From martin at theicelandguy.com Wed Apr 7 15:28:32 2010 From: martin at theicelandguy.com (Martin Hannigan) Date: Wed, 7 Apr 2010 16:28:32 -0400 Subject: Finding content in your job title In-Reply-To: <4BB2BE2C.9000901@ibctech.ca> References: <4BB2BE2C.9000901@ibctech.ca> Message-ID: On Tue, Mar 30, 2010 at 11:14 PM, Steve Bertrand wrote: [ snip ] > > For instance, I like to present myself as a 'network engineer'. I have > never taken formal education, don't hold any certifications (well, since > 2001), and can't necessarily prove my worth. > > How does the ops community feel about using this designation? > FWIW, I was Commodore of Infrastructure when I worked for the President of The World. Hope that's helpful. :-) Best, -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From jgreco at ns.sol.net Wed Apr 7 15:31:08 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 7 Apr 2010 15:31:08 -0500 (CDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: from "Owen DeLong" at Apr 07, 2010 09:49:33 AM Message-ID: <201004072031.o37KV8jp043643@aurora.sol.net> > On Apr 7, 2010, at 9:22 AM, William Herrin wrote: > > > On Wed, Apr 7, 2010 at 12:09 PM, John Palmer (NANOG Acct) > > wrote: > >> Was looking at the ARIN IP6 policy and cannot find any reference to those > >> who have > >> IP4 legacy space. > >> > >> Isn't there an automatic allocation for those of us who have legacy IP > >> space. If not, is ARIN > >> saying we have to pay them a fee to use IP6? Isn't this a disincentive for > >> us to move up to IP6? > >> > >> Those with legacy IP4 space should have the equivalent IP6 space under the > >> same terms. Or am I missing something? > > > > Hi John, > > > > The game is: > > > > Sign ARIN's "Legacy RSA" covering your legacy space. With the LRSA you > > retain more rights than folks who sign the regular RSA, but probably > > less rights than you have now. > > More accurately, you retain more rights than the standard RSA and you > move from a situation where your exact rights are unknown and > undetermined with no contractual relationship between you and ARIN > to a situation where your rights are assured, enumerated, and a > contractual relationship exists between you and ARIN governing > the services you are receiving from ARIN. > > > Pay your $100/year as an end-user. You now qualify for an IPv6 > > assignment under ARIN NRPM 6.5.8.1b regardless of the size of your > > network. > > > > Pay the $1250 IPv6 initial assignment fee. > > This is correct. I would like to see initial registration fee waivers for > IPv6 end-user assignments. I've brought the subject up on arin-discuss. > There was substantial opposition to the idea. If you would like to see > that happen, I encourage you to voice your opinion there. It's not the initial assignment fee that's really an impediment, it's moving from a model where the address space is free (or nearly so) to a model where you're paying a significant annual fee for the space. We'd be doing IPv6 here if not for the annual fee. As it stands, there isn't that much reason to do IPv6, and a significant disincentive in the form of the fees. ... 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 pfunix at gmail.com Wed Apr 7 15:36:39 2010 From: pfunix at gmail.com (Beavis) Date: Wed, 7 Apr 2010 14:36:39 -0600 Subject: Finding content in your job title In-Reply-To: References: <4BB2BE2C.9000901@ibctech.ca> <4BB2C0D9.4020607@ibctech.ca> Message-ID: Nathan, CIJ (Chief Internet Janitor) is kinda catchy ;) and this best describe my line of work. Keeping the company's Internet clean.. or when a mess is done already. But at the end of the day regardless of one's fancy title. there is still the work ... if you love it stay with it. my 0.002nc On Tue, Mar 30, 2010 at 9:30 PM, Nathan Ward wrote: > On 31/03/2010, at 4:26 PM, Steve Bertrand wrote: > >> On 2010.03.30 23:20, Jorge Amodio wrote: >>> I'd say that probably around here for those like me that have been in >>> operations/engineering management positions we don't give a squat >>> about what title your biz card says you have, your actions and >>> performance speak by themselves. >>> >>> There are no kings around here so titles most of the time are worthless. >>> >>> By asking what title may impress others is sort of a -1 to start. >> >> It isn't about impression. >> >> I'd put 'janitor' on my business card for all I really care. > > I'm pretty sure Jonny Martin was Chief Internet Janitor in his previous role. > > He cleaned the tubes so the sewage could flow. > > -- > Nathan Ward > > -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From gem at rellim.com Wed Apr 7 15:47:00 2010 From: gem at rellim.com (Gary E. Miller) Date: Wed, 7 Apr 2010 13:47:00 -0700 (PDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004072031.o37KV8jp043643@aurora.sol.net> References: <201004072031.o37KV8jp043643@aurora.sol.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo Joe! On Wed, 7 Apr 2010, Joe Greco wrote: > We'd be doing IPv6 here if not for the annual fee. As it stands, there > isn't that much reason to do IPv6, and a significant disincentive in the > form of the fees. +1 RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFLvO9IBmnRqz71OvMRAiAhAJwMeCY48LNxDXaSzXp5/zTNrjiOewCgytZL SBhqe9tTRo/qGeHt8xLbXLA= =//mT -----END PGP SIGNATURE----- From nenolod at systeminplace.net Wed Apr 7 15:52:24 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Wed, 07 Apr 2010 15:52:24 -0500 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004072031.o37KV8jp043643@aurora.sol.net> References: <201004072031.o37KV8jp043643@aurora.sol.net> Message-ID: <1270673544.20802.14.camel@petrie> On Wed, 2010-04-07 at 15:31 -0500, Joe Greco wrote: > > On Apr 7, 2010, at 9:22 AM, William Herrin wrote: > > > > > On Wed, Apr 7, 2010 at 12:09 PM, John Palmer (NANOG Acct) > > > wrote: > > >> Was looking at the ARIN IP6 policy and cannot find any reference to those > > >> who have > > >> IP4 legacy space. > > >> > > >> Isn't there an automatic allocation for those of us who have legacy IP > > >> space. If not, is ARIN > > >> saying we have to pay them a fee to use IP6? Isn't this a disincentive for > > >> us to move up to IP6? > > >> > > >> Those with legacy IP4 space should have the equivalent IP6 space under the > > >> same terms. Or am I missing something? > > > > > > Hi John, > > > > > > The game is: > > > > > > Sign ARIN's "Legacy RSA" covering your legacy space. With the LRSA you > > > retain more rights than folks who sign the regular RSA, but probably > > > less rights than you have now. > > > > More accurately, you retain more rights than the standard RSA and you > > move from a situation where your exact rights are unknown and > > undetermined with no contractual relationship between you and ARIN > > to a situation where your rights are assured, enumerated, and a > > contractual relationship exists between you and ARIN governing > > the services you are receiving from ARIN. > > > > > Pay your $100/year as an end-user. You now qualify for an IPv6 > > > assignment under ARIN NRPM 6.5.8.1b regardless of the size of your > > > network. > > > > > > Pay the $1250 IPv6 initial assignment fee. > > > > This is correct. I would like to see initial registration fee waivers for > > IPv6 end-user assignments. I've brought the subject up on arin-discuss. > > There was substantial opposition to the idea. If you would like to see > > that happen, I encourage you to voice your opinion there. > > It's not the initial assignment fee that's really an impediment, it's > moving from a model where the address space is free (or nearly so) to > a model where you're paying a significant annual fee for the space. > > We'd be doing IPv6 here if not for the annual fee. As it stands, there > isn't that much reason to do IPv6, and a significant disincentive in the > form of the fees. And when there are no eyeballs to look at your IPv4 content because your average comcast user is on IPv6? Will you have an incentive then? William From brandon.galbraith at gmail.com Wed Apr 7 15:55:02 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 7 Apr 2010 15:55:02 -0500 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <1270673544.20802.14.camel@petrie> References: <201004072031.o37KV8jp043643@aurora.sol.net> <1270673544.20802.14.camel@petrie> Message-ID: On Wed, Apr 7, 2010 at 3:52 PM, William Pitcock wrote: > And when there are no eyeballs to look at your IPv4 content because your > average comcast user is on IPv6? > > Will you have an incentive then? > > As long as Comcast or $EYEBALL_NET provides some sort of IPv6->IPv4, no. > William > > > -- Brandon Galbraith Voice: 630.492.0464 From jabley at hopcount.ca Wed Apr 7 15:58:15 2010 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 7 Apr 2010 16:58:15 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <18459664B284412885743075C7E0C621@TAKA> Message-ID: On 2010-04-07, at 14:02, Schiller, Heather A (HeatherSkanks) wrote: > ARIN Region IPv6 fee waiver: > https://www.arin.net/fees/fee_schedule.html#waivers > > "In Jan 2008, the Board of Trustees decided to reduce the fee waiver > incrementally over a period of 4 years. Full fees will be in effect in > 2012." > > Can you provide rationalization why anyone should automatically get any > kind of allocation? Or why legacy holders should "have equivalent > [IPv6] space under the same terms" - there is no address scarcity with IPv6 (at least not in the sense that there is with v4) - there is no significant danger of unconstrained v6 RIB explosion when assigning PI prefix to people who already occupy at least one slot in the v4 table (the problem is constrained to be at worst as bad as we see with v4, which is a known ceiling) - there's minimal administrative overhead in assigning PI space to people who are unlikely ever to come back to ask for more - what administrative overhead there is is minimal if the process of justification is trivial (or automatic) - ARIN says it is in the business of encouraging people to use v6 - people are more likely to use v6 if they can get v6 addresses easily and cheaply So automatically assigning v6 addresses to people who have a history of advertising v4 prefixes seems like it has minimal cost (less cost than other assignment strategies, seems to me) minimal risk to the Internet and will encourage people to use v6. What rationalisation can you provide for not doing this? [I mention this just because you asked. I'm not trying to turn NANOG into PPML. I'd mention this on PPML instead, but past experience tells me that I have far too much real work to do every day to be able to follow that list, and posting to a list you don't read seems rude.] Joe (speaking as private individual, not in any other capacity) From nanog2 at adns.net Wed Apr 7 15:59:30 2010 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Wed, 7 Apr 2010 15:59:30 -0500 Subject: ARIN IP6 policy for those with legacy IP4 Space References: <201004072031.o37KV8jp043643@aurora.sol.net> Message-ID: <68107E737FF84E2FB5409B1D516C022F@TAKA> Yah, thats what we are thinking here. We'll probably stick with IP4 only. Sounds like ARIN has set a trap, so that virtually any contact with them will result in the ceding of legacy rights. We'll be sure to avoid any such contact. Thanks everyone for the info. John ----- Original Message ----- From: "Joe Greco" To: "Owen DeLong" Cc: "NANOG list" Sent: Wednesday, April 07, 2010 3:31 PM Subject: Re: ARIN IP6 policy for those with legacy IP4 Space > It's not the initial assignment fee that's really an impediment, it's > moving from a model where the address space is free (or nearly so) to > a model where you're paying a significant annual fee for the space. > > We'd be doing IPv6 here if not for the annual fee. As it stands, there > isn't that much reason to do IPv6, and a significant disincentive in the > form of the fees. > > ... JG > -- From jfbeam at gmail.com Wed Apr 7 16:05:15 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 07 Apr 2010 17:05:15 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <18459664B284412885743075C7E0C621@TAKA> References: <18459664B284412885743075C7E0C621@TAKA> Message-ID: On Wed, 07 Apr 2010 12:09:30 -0400, John Palmer (NANOG Acct) wrote: > If not, is ARIN saying we have to pay them a fee to use IP6? Yeap. Just like everyone else with address space assigned from ARIN. > Isn't this a disincentive for us to move up to IP6? Yes! However, eventually, your "free" IPv4 space will be useless -- the rest of the world having moved on to IPv6. (and eventually the sun will burn out. I'm not worried about either.) > Those with legacy IP4 space should have the equivalent IP6 space under > the same terms. Or am I missing something? Why should they? The early ("legacy") allocations are from an different era. Their free ride is nearing it's end. They will have to start paying for address space like everyone else. And yes, that will further hinder IPv6 deployment. From awacs at ziskind.us Wed Apr 7 16:05:49 2010 From: awacs at ziskind.us (N. Yaakov Ziskind) Date: Wed, 7 Apr 2010 17:05:49 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <68107E737FF84E2FB5409B1D516C022F@TAKA> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> Message-ID: <20100407170549.B25519@egps.egps.com> Just curious: why not set up a separate entity to apply for IPv6 space? Do you get a cheaper fee (or other brownie points) if you already have an allocation? John Palmer (NANOG Acct) wrote (on Wed, Apr 07, 2010 at 03:59:30PM -0500): > Yah, thats what we are thinking here. We'll probably stick with IP4 only. > > Sounds like ARIN has set a trap, so that virtually any contact with them > will result in the ceding of legacy rights. > > We'll be sure to avoid any such contact. > > Thanks everyone for the info. > > John > ----- Original Message ----- > From: "Joe Greco" > To: "Owen DeLong" > Cc: "NANOG list" > Sent: Wednesday, April 07, 2010 3:31 PM > Subject: Re: ARIN IP6 policy for those with legacy IP4 Space > > >It's not the initial assignment fee that's really an impediment, it's > >moving from a model where the address space is free (or nearly so) to > >a model where you're paying a significant annual fee for the space. > > > >We'd be doing IPv6 here if not for the annual fee. As it stands, there > >isn't that much reason to do IPv6, and a significant disincentive in the > >form of the fees. > > > >... JG -- _________________________________________ 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 owen at delong.com Wed Apr 7 16:06:54 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 7 Apr 2010 14:06:54 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <68107E737FF84E2FB5409B1D516C022F@TAKA> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> Message-ID: If you are an end-user type organization, the fee is only $100/year for all your resources, IPv4 and IPv6 included. Is that really what you would call significant? Owen On Apr 7, 2010, at 1:59 PM, John Palmer (NANOG Acct) wrote: > Yah, thats what we are thinking here. We'll probably stick with IP4 only. > > Sounds like ARIN has set a trap, so that virtually any contact with them > will result in the ceding of legacy rights. > We'll be sure to avoid any such contact. > Thanks everyone for the info. > > John > ----- Original Message ----- From: "Joe Greco" > To: "Owen DeLong" > Cc: "NANOG list" > Sent: Wednesday, April 07, 2010 3:31 PM > Subject: Re: ARIN IP6 policy for those with legacy IP4 Space > > >> It's not the initial assignment fee that's really an impediment, it's >> moving from a model where the address space is free (or nearly so) to >> a model where you're paying a significant annual fee for the space. >> We'd be doing IPv6 here if not for the annual fee. As it stands, there >> isn't that much reason to do IPv6, and a significant disincentive in the >> form of the fees. >> ... JG >> -- > > From gem at rellim.com Wed Apr 7 16:12:27 2010 From: gem at rellim.com (Gary E. Miller) Date: Wed, 7 Apr 2010 14:12:27 -0700 (PDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <18459664B284412885743075C7E0C621@TAKA> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo Ricky! On Wed, 7 Apr 2010, Ricky Beam wrote: > They will have to start paying for > address space like everyone else. I could handle 'like everyone else', but have you noticed the HUGE per IP disparity between large and small block sizes? RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFLvPU/BmnRqz71OvMRAgNIAJ98nD7MomYGZLqcPqpo7q/1ihq1LwCg0PjA kpNkRpOVNpIiL1pi6zN2gXw= =ndUt -----END PGP SIGNATURE----- From asr+nanog at latency.net Wed Apr 7 16:14:08 2010 From: asr+nanog at latency.net (Adam Rothschild) Date: Wed, 7 Apr 2010 17:14:08 -0400 Subject: XO Communications rDNS In-Reply-To: <4BBCD3E6.3060403@mompl.net> References: <4BBCD3E6.3060403@mompl.net> Message-ID: <20100407211408.GA30675@latency.net> On 2010-04-07-14:50:14, Jeroen van Aart wrote: > I manage some IP space that's provided by an ISP but is "owned" by XO. I > am trying to have rDNS configured but their contact email > (ipadmin at eng.xo.com) in the whois does not grace me with a response (yet). > > Does anyone know if there is a way to get this done or should I just not > bother and live with it? This would be submitted by the XO customer directly. The "Business Center" portal[1] is generally the best place to submit such change requests, with follow-up correspondence by telephone, as necessary. With that said, it would seem XO decided to stop maintaining PTR records for backbone devices, instead opting for the more generic 'x.x.x.x.ptr.xo.net' (where x.x.x.x is an interface's IP address) naming convention. HTH, -a [1] https://bc.xo.com/Registration/Login.aspx From gem at rellim.com Wed Apr 7 16:17:49 2010 From: gem at rellim.com (Gary E. Miller) Date: Wed, 7 Apr 2010 14:17:49 -0700 (PDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo Owen! On Wed, 7 Apr 2010, Owen DeLong wrote: > If you are an end-user type organization, the fee is only $100/year > for all your resources, IPv4 and IPv6 included. Is that really what > you would call significant? As always, the devil is in the deetails. From: https://www.arin.net/fees/fee_schedule.html#waivers "The annual fee will be $100 USD until 2013, at which time ARIN's Board of Trustees may choose to raise the fee." Then scroll down to the fees you can expect in 2013. Especially note how the small guys get hit much harder per IP. RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFLvPZ/BmnRqz71OvMRAgXlAJ99dBvHUNfO5lAU//6aIlMMtKZ6NACgwP7c QLK2MxkwzeAEhV2qKKijxsQ= =bsCq -----END PGP SIGNATURE----- From lee at asgard.org Wed Apr 7 16:29:54 2010 From: lee at asgard.org (Lee Howard) Date: Wed, 7 Apr 2010 17:29:54 -0400 Subject: NAT444 vs IPv6 (was RE: legacy /8) In-Reply-To: <19E7C0EA-03D9-43A4-9E65-57565F2144C2@virtualized.org> References: <4BB65B39.8010902@mompl.net> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <19E7C0EA-03D9-43A4-9E65-57565F2144C2@virtualized.org> Message-ID: <002401cad699$7761f810$6625e830$@org> > > Nobody promised you a free lunch. In any case, the investment required to > > turn up IPv6 support is a lot less than the cost of carrier grade NAT. And > > the running costs of IPv6 are also lower, > > Can you provide pointers to these analyses? Any evidence-backed data showing how CGN > is more expensive would be very helpful. It depends. If you plan to do IPv6 eventually, it's probably cheaper to do it now than to depend on NAT444. NAT444 breaks some things (fewer than you might expect, so it might not be as expensive as you think). Some of those things can be fixed by doing static port forwarding, but that means a support call explaining how to configure port forwarding on the LSN, and troubleshooting through the CPE. Cost analysis: more support calls, but might be even with IPv6 support calls. If your provisioning and OSS are centralized, you may need multiple instances inside each LSN (or tunnels, or some other way to cope with the fact that you now have multiple domains of 10/8 inside your network). Cost analysis: may be the same amount of development required to add IPv6 functionality, but additional hardware may be required. You need a pretty big logging infrastructure, so you have an answer when Smokey says, "Who had this address with this source port at time T six months ago?" and lawyers on hand to explain why you won't tell them all 500 customers who were using that address at the time. And a variety of things documented in draft-ford-shared-addressing-issues. Cost analysis: lots of disk, lawyers, for issues that don't exist in IPv6. All of your hardware already speaks IPv4, very little requires updates to support private addressing. Cost analysis: you probably have some hardware that doesn't support IPv6. If cost were the only criterion, it might be an even split between NAT444 and IPv6. Using NAT444 to delay replacing non-IPv6 hardware until the regular depreciation cycle means spending twice on development labor just to delay the capex. That math may or may not make sense for your network.. Lee From drc at virtualized.org Wed Apr 7 16:49:27 2010 From: drc at virtualized.org (David Conrad) Date: Wed, 7 Apr 2010 11:49:27 -1000 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <1270673544.20802.14.camel@petrie> References: <201004072031.o37KV8jp043643@aurora.sol.net> <1270673544.20802.14.camel@petrie> Message-ID: On Apr 7, 2010, at 10:52 AM, William Pitcock wrote: > And when there are no eyeballs to look at your IPv4 content because your > average comcast user is on IPv6? The chances of this actually occurring in our lifetime are so small as to be meaningless. There are (according to published reports) between 1 and 2 billion people reachable on IPv4. No rational commercial Internet organization is going to block themselves off from that customer base. Folks like Comcast will probably add IPv6 support _in addition to_ IPv4. Eventually, they may even add a surcharge to encourage people to migrate off IPv4, but I'd imagine that's way down the line. By way of analogy, how long did pulse dialing continue to be supported in the phone system after DTMF was introduced? Regards, -drc From Valdis.Kletnieks at vt.edu Wed Apr 7 16:48:06 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 07 Apr 2010 17:48:06 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: Your message of "Wed, 07 Apr 2010 14:17:49 PDT." References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> Message-ID: <22087.1270676886@localhost> On Wed, 07 Apr 2010 14:17:49 PDT, "Gary E. Miller" said: > Then scroll down to the fees you can expect in 2013. Especially note > how the small guys get hit much harder per IP. The small guys pay: $0.000074505805969 per /64. ($1250 / (2^(64-40)) The big guys pay: $0.000000008185452 per /64. ($36000 / (2^(64-22)) The small guys are still paying less than 1/100th of a penny per /64. Assuming your salary plus overhead is $40/hour, each *second* of your time is worth more than the cost of 150 /64s. Oh, the inhumanity. -------------- 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 Wed Apr 7 16:52:49 2010 From: bill at herrin.us (William Herrin) Date: Wed, 7 Apr 2010 17:52:49 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> Message-ID: On Wed, Apr 7, 2010 at 4:31 PM, Joe Greco wrote: > We'd be doing IPv6 here if not for the annual fee. As it stands, there > isn't that much reason to do IPv6, and a significant disincentive in the > form of the fees. No you wouldn't. You'd hit the next impediment where the presence of IPv6 on your LAN destabilizes your "Internet connection" by causing all your software to try IPv6 first even though the IPv6 network hasn't reached the level of stability present in the IPv4 network. And then you'd stop and (rightly) complain about that problem too. On Wed, Apr 7, 2010 at 5:12 PM, Gary E. Miller wrote: > I could handle 'like everyone else', but have you noticed the HUGE > per IP disparity between large and small block sizes? How many zeros would you like at the end of your address count? The smallest ARIN IPv6 assignment has nearly 300 trillion more IP addresses than the whole IPv4 Internet. > As always, the devil is in the deetails. > > From: https://www.arin.net/fees/fee_schedule.html#waivers > > "The annual fee will be $100 USD until 2013, at which time ARIN's Board > of Trustees may choose to raise the fee." > > Then scroll down to the fees you can expect in 2013. Especially note > how the small guys get hit much harder per IP. You've misread the insider terminology. Here's a brief lesson in ARIN-speak: allocation - addresses provided to ISPs which ISPs then "reassign" to customers. These cost a lot per year. Partial waivers apply until 2013. assignment - addresses provided to end-users. These cost a lot up front, but then the organization as a whole only pays an annual maintenance fee of $100 per year total. No waivers apply. On Wed, Apr 7, 2010 at 5:49 PM, David Conrad wrote: > By way of analogy, how long did pulse dialing continue to be > supported in the phone system after DTMF was introduced? It still is on every analog line I've tried, including voip adapters. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From lee at asgard.org Wed Apr 7 17:07:27 2010 From: lee at asgard.org (Lee Howard) Date: Wed, 7 Apr 2010 18:07:27 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> Message-ID: <003001cad69e$b61d97d0$2258c770$@org> > -----Original Message----- > From: Gary E. Miller [mailto:gem at rellim.com] > From: https://www.arin.net/fees/fee_schedule.html#waivers > > "The annual fee will be $100 USD until 2013, at which time ARIN's Board > of Trustees may choose to raise the fee." Right. That's for legacy space. The Board was trying to show that the fees will be stable, without saying they'd never rise. In fact, if you read the Legacy RSA itself, it says fee increases are limited to: (1) the amount charged non-Legacy holders for this maintenance service; and (2) no increase per year greater than $25. You can find it through https://www.arin.net/resources/legacy/ along with a FAQ explaining why you might consider it. You can contact ARIN to discuss it, if you have questions (see FAQ #11). By the way, we extended the availability of the Legacy RSA through June 30, 2010. Also, the fee is waived if you pay other fees to ARIN, or if you return some address space. See the URL. > Then scroll down to the fees you can expect in 2013. You're talking now about a new IPv6 allocation, not your legacy space, right? I covered legacy fees above. > Especially note > how the small guys get hit much harder per IP. Do you mean the $2250 for a /32, or the $1250 for a /48? Compare the relative costs to ARIN; ARIN's fees aren't set per IP address. Disclaimer: I'm on the ARIN Board, but I sometimes make mistakes. I summarize, but the official word comes from the documents and the staff. Lee From john at sackheads.org Wed Apr 7 17:31:16 2010 From: john at sackheads.org (John Payne) Date: Wed, 7 Apr 2010 18:31:16 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <18459664B284412885743075C7E0C621@TAKA> References: <18459664B284412885743075C7E0C621@TAKA> Message-ID: <5C00010B-856A-4ADC-A3EF-6E4CC7E9D170@sackheads.org> On Apr 7, 2010, at 12:09 PM, John Palmer (NANOG Acct) wrote: > Was looking at the ARIN IP6 policy and cannot find any reference to those who have > IP4 legacy space. > > Isn't there an automatic allocation for those of us who have legacy IP space. If not, is ARIN > saying we have to pay them a fee to use IP6? Isn't this a disincentive for us to move up to IP6? > > Those with legacy IP4 space should have the equivalent IP6 space under the same terms. Or > am I missing something? If you don't have a contract with ARIN, why should ARIN provide you with anything? From deepak at ai.net Wed Apr 7 17:31:25 2010 From: deepak at ai.net (Deepak Jain) Date: Wed, 7 Apr 2010 18:31:25 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <003001cad69e$b61d97d0$2258c770$@org> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <003001cad69e$b61d97d0$2258c770$@org> Message-ID: Now I may be talking crazy... IIRC, all of IPv4 space maps to a section of IPv6 space. If one has legacy IPv4 space, but actually talks IPv6 couldn't one announce a prefix much longer than a /64 to map them onto the IPv6 universe (assuming people would allow such craziness... perhaps on their IPv4 speaking routers) and originate/terminate traffic as normal? Isn't this all left to the networks to enforce, as usual, but unlike the status quo, these are all valid allocations... Technical note: I know this breaks lots of IPv6 goodness (no need to enumerate it here). DJ From ghicks at hicks-net.net Wed Apr 7 17:45:11 2010 From: ghicks at hicks-net.net (Gregory Hicks) Date: Wed, 7 Apr 2010 15:45:11 -0700 (PDT) Subject: Finding content in your job title Message-ID: <201004072245.o37MjBVS024092@metis.hicks-net.net> > Date: Wed, 07 Apr 2010 11:39:09 -0700 > From: Jeroen van Aart > To: NANOG list > Subject: Re: Finding content in your job title > > Lamar Owen wrote: > > companies, Official Title is used to determine salary (or even > > whether you're an exempt employee or not). And the company's > > bylaws may invest particular > > Unless I misread the laws regarding this, in CA at least you still > have to earn ~$40/hr or more (it varies and last I read it was > lowered a few $s) or more to be considered exempt, regardless of your > job title Actually, it doesn't matter how much you make per hour, the deciding factor between exempt and non-exempt is how many (if any) people you SUPERVISE. No supervision of others, then non-exempt. Now you and the employer may agree to some other definition, but that is between you and them. At my previous $DAY_JOB, a technicion who was classified as "exempt" took $EMPLOYER to court over back pay, overtime, lunch breaks, et al and WON. (He had no direct reports...) Regards, Gregory Hicks --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer | Direct: 408.569.7928 People sleep peaceably in their beds at night only because rough men stand ready to do violence on their behalf -- George Orwell The price of freedom is eternal vigilance. -- Thomas Jefferson "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton From nanog2 at adns.net Wed Apr 7 17:54:44 2010 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Wed, 7 Apr 2010 17:54:44 -0500 Subject: ARIN IP6 policy for those with legacy IP4 Space References: <201004072031.o37KV8jp043643@aurora.sol.net><68107E737FF84E2FB5409B1D516C022F@TAKA><003001cad69e$b61d97d0$2258c770$@org> Message-ID: I kind of thought that was something that had already been worked out. Thats what I get for not paying close enough attention. ----- Original Message ----- From: "Deepak Jain" To: "Lee Howard" ; "'Gary E. Miller'" ; "'OwenDeLong'" Cc: "'NANOG list'" Sent: Wednesday, April 07, 2010 5:31 PM Subject: RE: ARIN IP6 policy for those with legacy IP4 Space Now I may be talking crazy... IIRC, all of IPv4 space maps to a section of IPv6 space. If one has legacy IPv4 space, but actually talks IPv6 couldn't one announce a prefix much longer than a /64 to map them onto the IPv6 universe (assuming people would allow such craziness... perhaps on their IPv4 speaking routers) and originate/terminate traffic as normal? Isn't this all left to the networks to enforce, as usual, but unlike the status quo, these are all valid allocations... Technical note: I know this breaks lots of IPv6 goodness (no need to enumerate it here). DJ From scottleibrand at gmail.com Wed Apr 7 17:57:07 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 07 Apr 2010 15:57:07 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <18459664B284412885743075C7E0C621@TAKA> Message-ID: <4BBD0DC3.9020803@gmail.com> On Wed 4/7/2010 2:12 PM, Gary E. Miller wrote: > On Wed, 7 Apr 2010, Ricky Beam wrote: > > >> They will have to start paying for >> address space like everyone else. >> > I could handle 'like everyone else', but have you noticed the HUGE > per IP disparity between large and small block sizes? > Gary, ARIN doesn't allocate IPv6 addresses on a per-address basis. ARIN charges fees for address block assignments using a cost recovery model, and attempts to set those fees approximately proportional to the costs of allocating, assigning, and maintaining registration for address blocks. It costs ARIN about the same (up front) to allocate a /32 as it does to assign a /48. On an ongoing basis, it costs more to maintain registry integrity (keep whois up to date) on a /32 allocation than it does for a /48 assignment. So the annual fee for a /48 assignment is $100/yr, whereas the annual fee for a /32 allocation is the same as the initial allocation fee. If you are not an ARIN member, but would like to participate in the members' discussion of ARIN's fee structure, the semi-annual member's meeting is open to the public. Remote participation is available free of charge: https://www.arin.net/participate/meetings/ARIN-XXV/remote.html Also, don't forget that if you want to pay less (i.e. nothing) for your IPv6 assignment, you can get a /48 for free from just about any ISP that does IPv6. -Scott From nanog2 at adns.net Wed Apr 7 17:59:27 2010 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Wed, 7 Apr 2010 17:59:27 -0500 Subject: ARIN IP6 policy for those with legacy IP4 Space References: <18459664B284412885743075C7E0C621@TAKA> <4BBD0DC3.9020803@gmail.com> Message-ID: <90B522A1B7194C2FBA5AB4E70F1F9C6B@TAKA> But its not portable. Thats a deal breaker for some applications. ----- Original Message ----- From: "Scott Leibrand" To: Sent: Wednesday, April 07, 2010 5:57 PM Subject: Re: ARIN IP6 policy for those with legacy IP4 Space > Also, don't forget that if you want to pay less (i.e. nothing) for your > IPv6 assignment, you can get a /48 for free from just about any ISP that > does IPv6. > > -Scott > > From patrick at zill.net Wed Apr 7 18:10:46 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Wed, 07 Apr 2010 19:10:46 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004072031.o37KV8jp043643@aurora.sol.net> References: <201004072031.o37KV8jp043643@aurora.sol.net> Message-ID: <4BBD10F6.9080409@zill.net> Joe Greco wrote: > > It's not the initial assignment fee that's really an impediment, it's > moving from a model where the address space is free (or nearly so) to > a model where you're paying a significant annual fee for the space. > > We'd be doing IPv6 here if not for the annual fee. As it stands, there > isn't that much reason to do IPv6, and a significant disincentive in the > form of the fees. > > ... JG I have to agree ... why such high charges when a similar service like GoDaddy provides (domain name registrar) is $15 a year? Is it REALLY X times the level of difficulty of registering a domain name, and thus the charges are justified? I will let someone who is very technical explain this to me. Cordially Patrick From owen at delong.com Wed Apr 7 18:19:06 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 7 Apr 2010 16:19:06 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> Message-ID: That talks about the LRSA fee. Everything below that, however, refers to ISP fees, not to end user fees. There is no speculation on that page as to what LRSA fees will be after 2013, and, there is nothing indicating that we should expect a significant change in end-user fees for LRSA or RSA. I know this is subtle, but: ALLOCATION == ISP ASSIGNMENT == End User Assignments are not charged subscriber renewal fees. They are charged an annual maintenance fee. Owen On Apr 7, 2010, at 2:17 PM, Gary E. Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Yo Owen! > > On Wed, 7 Apr 2010, Owen DeLong wrote: > >> If you are an end-user type organization, the fee is only $100/year >> for all your resources, IPv4 and IPv6 included. Is that really what >> you would call significant? > > As always, the devil is in the deetails. > > From: https://www.arin.net/fees/fee_schedule.html#waivers > > "The annual fee will be $100 USD until 2013, at which time ARIN's Board > of Trustees may choose to raise the fee." > > Then scroll down to the fees you can expect in 2013. Especially note > how the small guys get hit much harder per IP. > > RGDS > GARY > - --------------------------------------------------------------------------- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 > gem at rellim.com Tel:+1(541)382-8588 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > > iD8DBQFLvPZ/BmnRqz71OvMRAgXlAJ99dBvHUNfO5lAU//6aIlMMtKZ6NACgwP7c > QLK2MxkwzeAEhV2qKKijxsQ= > =bsCq > -----END PGP SIGNATURE----- From franck at genius.com Wed Apr 7 18:20:01 2010 From: franck at genius.com (Franck Martin) Date: Thu, 8 Apr 2010 11:20:01 +1200 (FJT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4BBD10F6.9080409@zill.net> Message-ID: <9530527.457.1270682401434.JavaMail.franck@franck-martins-macbook-pro.local> APNIC has a calculator for the fees for the space. you pay max(IPv4 space fee, IPv6 space fee). So basically you don't pay anything to dual stack your current network. Also, if you are current standing member, they don't even ask you to justify IPv6, they give you a similar space to your current IPv4 space on simple request. If you need more then you need to justify. ----- Original Message ----- From: "Patrick Giagnocavo" To: "Joe Greco" , "NANOG" Sent: Thursday, 8 April, 2010 11:10:46 AM Subject: Re: ARIN IP6 policy for those with legacy IP4 Space Joe Greco wrote: > > It's not the initial assignment fee that's really an impediment, it's > moving from a model where the address space is free (or nearly so) to > a model where you're paying a significant annual fee for the space. > > We'd be doing IPv6 here if not for the annual fee. As it stands, there > isn't that much reason to do IPv6, and a significant disincentive in the > form of the fees. > > ... JG I have to agree ... why such high charges when a similar service like GoDaddy provides (domain name registrar) is $15 a year? Is it REALLY X times the level of difficulty of registering a domain name, and thus the charges are justified? I will let someone who is very technical explain this to me. Cordially Patrick From owen at delong.com Wed Apr 7 18:22:01 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 7 Apr 2010 16:22:01 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <1270673544.20802.14.camel@petrie> Message-ID: On Apr 7, 2010, at 2:49 PM, David Conrad wrote: > On Apr 7, 2010, at 10:52 AM, William Pitcock wrote: >> And when there are no eyeballs to look at your IPv4 content because your >> average comcast user is on IPv6? > > The chances of this actually occurring in our lifetime are so small as to be meaningless. There are (according to published reports) between 1 and 2 billion people reachable on IPv4. No rational commercial Internet organization is going to block themselves off from that customer base. Folks like Comcast will probably add IPv6 support _in addition to_ IPv4. Eventually, they may even add a surcharge to encourage people to migrate off IPv4, but I'd imagine that's way down the line. By way of analogy, how long did pulse dialing continue to be supported in the phone system after DTMF was introduced? > > Regards, > -drc Actually, I suspect that once orgs. like Comcast have IPv6 fully deployed you will very likely see increasing fees for "Legacy IPv4 Support" from those providers. Once that happens, there will be eye-ball consumer pressure for content providers to be available on IPv6 or lose business. Pulse dialing is still supported in most PSTN switches. How often do you think it is still used? Frankly, the biggest reason Pulse dialing wasn't deprecated faster was the number of Telcos that charged extra for DTMF support for so long. Once the DTMF surcharges were removed, most users converted almost over night. Owen From davet1 at gmail.com Wed Apr 7 18:26:51 2010 From: davet1 at gmail.com (Dave Temkin) Date: Wed, 07 Apr 2010 16:26:51 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4BBD10F6.9080409@zill.net> References: <201004072031.o37KV8jp043643@aurora.sol.net> <4BBD10F6.9080409@zill.net> Message-ID: <4BBD14BB.7010907@gmail.com> Patrick Giagnocavo wrote: > Joe Greco wrote: > > >> It's not the initial assignment fee that's really an impediment, it's >> moving from a model where the address space is free (or nearly so) to >> a model where you're paying a significant annual fee for the space. >> >> We'd be doing IPv6 here if not for the annual fee. As it stands, there >> isn't that much reason to do IPv6, and a significant disincentive in the >> form of the fees. >> >> ... JG >> > > > I have to agree ... why such high charges when a similar service like > GoDaddy provides (domain name registrar) is $15 a year? > > Is it REALLY X times the level of difficulty of registering a domain > name, and thus the charges are justified? I will let someone who is > very technical explain this to me. > > Cordially > > Patrick > > There are 117,351,239 domain names registered. If I had to guess, there are less than 1% of that total number in IP assignments (not allocations), but I don't have the patience to go compile those statistics. GoDaddy exists based on volume, which we don't have the same scale with IP assignments. -Dave From randy at psg.com Wed Apr 7 18:30:53 2010 From: randy at psg.com (Randy Bush) Date: Thu, 08 Apr 2010 08:30:53 +0900 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <1270673544.20802.14.camel@petrie> References: <201004072031.o37KV8jp043643@aurora.sol.net> <1270673544.20802.14.camel@petrie> Message-ID: > And when there are no eyeballs to look at your IPv4 content because your > average comcast user is on IPv6? we should live so long randy From matthew at matthew.at Wed Apr 7 18:33:11 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 07 Apr 2010 16:33:11 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4BBD14BB.7010907@gmail.com> References: <201004072031.o37KV8jp043643@aurora.sol.net> <4BBD10F6.9080409@zill.net> <4BBD14BB.7010907@gmail.com> Message-ID: <4BBD1637.5050208@matthew.at> Dave Temkin wrote: > There are 117,351,239 domain names registered. If I had to guess, > there are less than 1% of that total number in IP assignments (not > allocations), but I don't have the patience to go compile those > statistics. GoDaddy exists based on volume, which we don't have the > same scale with IP assignments. > And when every entity only needs one IPv6 block and doesn't need to ever come back for more, RIR revenues will be even lower. But that won't mean the spending stops... so I'm sure the shortfall will be made up somehow. Matthew Kaufman From randy at psg.com Wed Apr 7 18:34:14 2010 From: randy at psg.com (Randy Bush) Date: Thu, 08 Apr 2010 08:34:14 +0900 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <003001cad69e$b61d97d0$2258c770$@org> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <003001cad69e$b61d97d0$2258c770$@org> Message-ID: > Do you mean the $2250 for a /32, or the $1250 for a /48? Compare the > relative costs to ARIN; ARIN's fees aren't set per IP address. if not, then why are they not flat per-allocation? randy From owen at delong.com Wed Apr 7 18:34:38 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 7 Apr 2010 16:34:38 -0700 Subject: Finding content in your job title In-Reply-To: <201004072245.o37MjBVS024092@metis.hicks-net.net> References: <201004072245.o37MjBVS024092@metis.hicks-net.net> Message-ID: On Apr 7, 2010, at 3:45 PM, Gregory Hicks wrote: > >> Date: Wed, 07 Apr 2010 11:39:09 -0700 >> From: Jeroen van Aart >> To: NANOG list >> Subject: Re: Finding content in your job title >> >> Lamar Owen wrote: >>> companies, Official Title is used to determine salary (or even >>> whether you're an exempt employee or not). And the company's >>> bylaws may invest particular >> >> Unless I misread the laws regarding this, in CA at least you still >> have to earn ~$40/hr or more (it varies and last I read it was >> lowered a few $s) or more to be considered exempt, regardless of your >> job title > > Actually, it doesn't matter how much you make per hour, the deciding > factor between exempt and non-exempt is how many (if any) people you > SUPERVISE. No supervision of others, then non-exempt. > That is not entirely correct. The actual text of the law, IIRC, reads to the effect of "Work which is primarily intellectual or managerial in nature..." In other words, if you are management _OR_ some form of technical professional. Most of the technical individual contributors I know that are in the 6-figure realm are exempt. You can find California Guidance on this matter here: http://www.dir.ca.gov/dlse/faq_OvertimeExemptions.htm More information is available here: http://www.management-advantage.com/products/overtime-exempt.html For further information, refer to the California Labor Code, near section 515. (515.5 applies to this industry) Other states may vary. Owen From awacs at ziskind.us Wed Apr 7 18:40:30 2010 From: awacs at ziskind.us (N. Yaakov Ziskind) Date: Wed, 7 Apr 2010 19:40:30 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> Message-ID: <20100407194030.A3660@egps.egps.com> I don't think the issue is *money* (at least the big issue; money is *always* an issue), but rather the all-of-sudden jump from being unregulated to regulated, whatever that means. I would think multiple times before making that jump. Hence my suggestion to set up a separate organization to request IPv6 space, and thus not 'endanger' whatever I had before. Owen DeLong wrote (on Wed, Apr 07, 2010 at 02:06:54PM -0700): > If you are an end-user type organization, the fee is only $100/year > for all your resources, IPv4 and IPv6 included. Is that really what > you would call significant? > > Owen > > On Apr 7, 2010, at 1:59 PM, John Palmer (NANOG Acct) wrote: > > > Yah, thats what we are thinking here. We'll probably stick with IP4 only. > > > > Sounds like ARIN has set a trap, so that virtually any contact with them > > will result in the ceding of legacy rights. > > We'll be sure to avoid any such contact. > > Thanks everyone for the info. > > > > John > > ----- Original Message ----- From: "Joe Greco" > > To: "Owen DeLong" > > Cc: "NANOG list" > > Sent: Wednesday, April 07, 2010 3:31 PM > > Subject: Re: ARIN IP6 policy for those with legacy IP4 Space > > > > > >> It's not the initial assignment fee that's really an impediment, it's > >> moving from a model where the address space is free (or nearly so) to > >> a model where you're paying a significant annual fee for the space. > >> We'd be doing IPv6 here if not for the annual fee. As it stands, there > >> isn't that much reason to do IPv6, and a significant disincentive in the > >> form of the fees. > >> ... JG > >> -- > > > > > -- _________________________________________ 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 kevin at steadfast.net Wed Apr 7 18:47:10 2010 From: kevin at steadfast.net (Kevin Stange) Date: Wed, 07 Apr 2010 18:47:10 -0500 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <9530527.457.1270682401434.JavaMail.franck@franck-martins-macbook-pro.local> References: <9530527.457.1270682401434.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4BBD197E.9050403@steadfast.net> On 04/07/2010 06:20 PM, Franck Martin wrote: > APNIC has a calculator for the fees for the space. you pay max(IPv4 space fee, IPv6 space fee). So basically you don't pay anything to dual stack your current network. It currently works the same way in ARIN's fee schedule. However, in this discussion, we're talking about people who have legacy IPv4 space, which is now administratively under ARIN's management, and for whom there are currently no fees of any kind, which means that max(IPv4 space fee, IPv6 space fee) == IPv6 space fee, and increase from nothing, ever. > Also, if you are current standing member, they don't even ask you to justify IPv6, they give you a similar space to your current IPv4 space on simple request. If you need more then you need to justify. For an organization that didn't have to justify anything for IPv4 in the modern sense in order to obtain their address space, it's arguably a valid question to ask whether they have any need for anything similar in IPv6. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From jeroen at mompl.net Wed Apr 7 19:04:24 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 07 Apr 2010 17:04:24 -0700 Subject: XO Communications rDNS In-Reply-To: <20100407211408.GA30675@latency.net> References: <4BBCD3E6.3060403@mompl.net> <20100407211408.GA30675@latency.net> Message-ID: <4BBD1D88.6060506@mompl.net> Adam Rothschild wrote: > With that said, it would seem XO decided to stop maintaining PTR > records for backbone devices, instead opting for the more generic > 'x.x.x.x.ptr.xo.net' (where x.x.x.x is an interface's IP address) > naming convention. The particular /28 netblock I talk about does not have any rDNS at all. From jeroen at mompl.net Wed Apr 7 20:06:24 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 07 Apr 2010 18:06:24 -0700 Subject: what about 48 bits? In-Reply-To: <4BBA2D35.6070805@foobar.org> References: <20100404180856.GP75640@gerbil.cluepon.net> <4BB8FBCF.4020909@matthew.at> <20100405105746.750257bf@opy.nosense.org> <20100405025742.GR75640@gerbil.cluepon.net> <4BB96187.6040703@bogus.com> <2B39543C-7EF5-48AE-9E54-3E8A0C714204@cs.columbia.edu> <13353.1270489432@localhost> <0CEC3B65-F639-4B0D-AC0E-F3AF99779EEB@cs.columbia.edu> <4BBA2D35.6070805@foobar.org> Message-ID: <4BBD2C10.8060805@mompl.net> Nick Hilliard wrote: > On an even more unrelated note, does anyone remember the day that > CMU-TEK tcp/ip stopped working some time in the early 1990s? That was a > load of fun. I remember a satellite taking care of trans-Atlantic internet traffic going down in the mid 90s causing 30 minute lags on irc, if that counts. :-) From scott at doc.net.au Wed Apr 7 21:22:02 2010 From: scott at doc.net.au (Scott Howard) Date: Wed, 7 Apr 2010 19:22:02 -0700 Subject: APNIC's report on traffic directed to 1.0.0.0/8 Message-ID: http://mailman.apnic.net/mailing-lists/apnic-talk/archive/2010/04/msg00002.html (There's also a PDF version with easier to enlarge images at http://www.potaroo.net/studies/1slash8/1slash8.pdf ) Scott. From LarrySheldon at cox.net Wed Apr 7 22:00:11 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 07 Apr 2010 22:00:11 -0500 Subject: Finding content in your job title In-Reply-To: <201004072245.o37MjBVS024092@metis.hicks-net.net> References: <201004072245.o37MjBVS024092@metis.hicks-net.net> Message-ID: <4BBD46BB.40801@cox.net> On 4/7/2010 17:45, Gregory Hicks wrote: > Actually, it doesn't matter how much you make per hour, the deciding > factor between exempt and non-exempt is how many (if any) people you > SUPERVISE. No supervision of others, then non-exempt. I don't think that is correct. "Professionals" do not supervise people but if the substantial control their own activities and make above a certain level in total compensation, they may be exempt. > > Now you and the employer may agree to some other definition, but that > is between you and them. > > At my previous $DAY_JOB, a technicion who was classified as "exempt" > took $EMPLOYER to court over back pay, overtime, lunch breaks, et al > and WON. (He had no direct reports...) He probably failed the compensation test, or more likely, did not control his own activities. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From smb at cs.columbia.edu Wed Apr 7 20:00:00 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 7 Apr 2010 21:00:00 -0400 Subject: Hubs on a NIC (was:Re: what about 48 bits?) In-Reply-To: <201004071503.o37F3HPI030585@aurora.sol.net> References: <201004071503.o37F3HPI030585@aurora.sol.net> Message-ID: On Apr 7, 2010, at 11:03 16AM, Joe Greco wrote: >> On Wednesday 07 April 2010 07:18:57 am Joe Greco wrote: >>> To me, this is a Dilbert-class engineering failure. I would imagine that >>> if you could implement a hub on the network card, the same chip(s) would >>> work in an external tin can with a separate power supply. Designing a >>> product that actually exhibits a worse failure mode than 10base2 is ... >>> strange to me. >> >> I have in my gear museum a fairly large box with a couple of this type of 'hub >> on a card' installed. And in this particular case, it made perfect sense, as >> the box is an Evergreen Systems CAPserver, and has 16 486 single-board >> computers tied to two 8-port hub cards (two ports on each modular plug, too), >> with....wait for it... a 10Base-2 uplink. These were used mostly for remote >> network access and remote desktop access. >> >> If you want more data on this old and odd box, see >> http://www.bomara.com/Eversys/capserver2300.htm >> >> I can see a hub card being useful in an old NetWare server setting, though, >> since if the server went down you might as well not have a network in the first >> place, in that use case. > > Certainly. I can come up with a bunch of reasonable-use scenarios too, > but most of the people here will have run into that awful situation where > a product is used in a manner that isn't "Recommended". > > In this case, I know that some of these cards were marketed in the same > manner that workgroup hubs/switches are marketed; you would daisy-chain > these stupid things so that your PC would feed the cubes right around you > and then have an uplink and downlink a few cubes to the next "hub". When I had the need to wire a building around 1987, I opted for the multiport 10Base5 repeaters that DEC made -- they were called DELUAs, I think. I'd had quite enough of distributed single points of failure, thank you. > > Remember, it was this strange time when people were uncertain about how > networks were going to evolve, and what the next thing would be, and > even then, 10baseT was being deployed over Cat3 (sometimes recycled/ > repurposed), so any sort of "enabling" gadget such as these cards had a > tendency to be abused in various ways. Right -- the wire and pin assignments for 10BaseT and 100BaseT were designed to permit sharing the cable between Ethernet and phone. > > Two ports on each modular plug, though.... (shudder) ;-) > Hey, I had that in my house on my 100BaseT network, till I upgraded to gigE and had to give in and buy another switch. (Sigh -- home network configurations of NANOGers. I'm contemplating putting in VLANs now...) --Steve Bellovin, http://www.cs.columbia.edu/~smb From smb at cs.columbia.edu Wed Apr 7 20:03:32 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 7 Apr 2010 21:03:32 -0400 Subject: Finding content in your job title In-Reply-To: References: <4BB2BE2C.9000901@ibctech.ca> Message-ID: On Apr 7, 2010, at 4:28 32PM, Martin Hannigan wrote: > On Tue, Mar 30, 2010 at 11:14 PM, Steve Bertrand wrote: > > [ snip ] > > >> >> For instance, I like to present myself as a 'network engineer'. I have >> never taken formal education, don't hold any certifications (well, since >> 2001), and can't necessarily prove my worth. >> >> How does the ops community feel about using this designation? >> > > FWIW, I was Commodore of Infrastructure when I worked for the President of > The World. Way back when, an organization I know of decided to "regularize" its titles and insisted that the computer center staff suggest proper titles. They didn't much like "Bit Pusher" or "Telecommunications Bit Pusher", but finally gave up when one woman insisted that her proper title was "Empress of the 8th Floor". --Steve Bellovin, http://www.cs.columbia.edu/~smb From tony at lava.net Wed Apr 7 23:28:02 2010 From: tony at lava.net (Antonio Querubin) Date: Wed, 7 Apr 2010 18:28:02 -1000 (HST) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4BBCE16F.40504@steadfast.net> References: <18459664B284412885743075C7E0C621@TAKA> <4BBCE16F.40504@steadfast.net> Message-ID: On Wed, 7 Apr 2010, Kevin Stange wrote: > How much IPv6 address space were they expecting? I have trouble > envisioning any operation that could require more than a /32 immediately > that can't afford to pay $4500 per YEAR. Amount of address space wasn't the problem. The application was actually approved by ARIN. However, fighting for a line in the budget for the unexpected fee(s) and the prospect of having to push the RSA through state government lawyers was enough to dissuade them that IPv6 just wasn't important enough at this time. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From mark at viviotech.net Thu Apr 8 00:51:22 2010 From: mark at viviotech.net (Mark Keymer) Date: Wed, 07 Apr 2010 22:51:22 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <18459664B284412885743075C7E0C621@TAKA> <4BBCE16F.40504@steadfast.net> Message-ID: <4BBD6EDA.2030306@viviotech.net> Hi, I guess I am confused. Don't you have to pay for IP4 space? I know I am still fairly new to things. So maybe I just don't get it. Sincerely, Mark Antonio Querubin wrote: > On Wed, 7 Apr 2010, Kevin Stange wrote: > >> How much IPv6 address space were they expecting? I have trouble >> envisioning any operation that could require more than a /32 immediately >> that can't afford to pay $4500 per YEAR. > > > Amount of address space wasn't the problem. The application was > actually approved by ARIN. However, fighting for a line in the budget > for the unexpected fee(s) and the prospect of having to push the RSA > through state government lawyers was enough to dissuade them that IPv6 > just wasn't important enough at this time. > > Antonio Querubin > 808-545-5282 x3003 > e-mail/xmpp: tony at lava.net > From tony at lava.net Thu Apr 8 03:14:24 2010 From: tony at lava.net (Antonio Querubin) Date: Wed, 7 Apr 2010 22:14:24 -1000 (HST) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4BBD6EDA.2030306@viviotech.net> References: <18459664B284412885743075C7E0C621@TAKA> <4BBCE16F.40504@steadfast.net> <4BBD6EDA.2030306@viviotech.net> Message-ID: On Wed, 7 Apr 2010, Mark Keymer wrote: > I guess I am confused. Don't you have to pay for IP4 space? I know I am still > fairly new to things. So maybe I just don't get it. Legacy IPv4 holders have no obligation to ARIN until they sign an RSA. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From jim at reptiles.org Thu Apr 8 03:33:57 2010 From: jim at reptiles.org (Jim Mercer) Date: Thu, 8 Apr 2010 04:33:57 -0400 Subject: speedtest suite like NDT that runs on FreeBSD? Message-ID: <20100408083357.GH3030@reptiles.org> i'm looking for a speedtest server suite, like NDT http://netspeed.stanford.edu/ which can be run using a FreeBSD server. any leads? thanx -- Jim Mercer jim at reptiles.org +92 336 520-4504 From owen at delong.com Thu Apr 8 05:17:05 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 8 Apr 2010 03:17:05 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <18459664B284412885743075C7E0C621@TAKA> <4BBCE16F.40504@steadfast.net> <4BBD6EDA.2030306@viviotech.net> Message-ID: On Apr 8, 2010, at 1:14 AM, Antonio Querubin wrote: > On Wed, 7 Apr 2010, Mark Keymer wrote: > >> I guess I am confused. Don't you have to pay for IP4 space? I know I am still fairly new to things. So maybe I just don't get it. > > Legacy IPv4 holders have no obligation to ARIN until they sign an RSA. The obligation of legacy holders to ARIN (if any exists) and the obligation of ARIN to legacy holders (again, if any exists) is definitely an open question. One which, so far, ARIN has tried to be very gentle about, providing services to legacy holders without asking much (anything) in return. The Legacy RSA is a particularly generous version of the RSA which is intended to preserve most of the perceived benefits legacy holders currently receive while bringing their resources clearly under ARIN stewardship and imposing a few of the obligations which exist for all other resource holding members of the community. Owen From jcurran at istaff.org Thu Apr 8 07:13:24 2010 From: jcurran at istaff.org (John Curran) Date: Thu, 8 Apr 2010 08:13:24 -0400 Subject: Content via IPv4/IPv6 (was: Re: ARIN IP6 policy for those with legacy IP4 Space) In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <1270673544.20802.14.camel@petrie> Message-ID: <5EA59A41-40FB-43F0-B8F6-8394C59CF83C@istaff.org> On Apr 7, 2010, at 5:49 PM, David Conrad wrote: > On Apr 7, 2010, at 10:52 AM, William Pitcock wrote: >> And when there are no eyeballs to look at your IPv4 content because your average comcast user is on IPv6? > > The chances of this actually occurring in our lifetime are so small as to be meaningless. There are (according to published reports) between 1 and 2 billion people reachable on IPv4. No rational commercial Internet organization is going to block themselves off from that customer base. Folks like Comcast will probably add IPv6 support _in addition to_ IPv4. Eventually, they may even add a surcharge to encourage people to migrate off IPv4, but I'd imagine that's way down the line. By way of analogy, how long did pulse dialing continue to be supported in the phone system after DTMF was introduced? David - Your assessment matches mine, with one important difference: While I'm certain that almost any new broadband user from any provider will be able to reach IPv4-only sites (required in order to meet consumer expectations of "This is Internet service"), the ability to provide scalable high-performance, low-latency, low-jitter path to IPv4 resources is questionable. If you are a hosting/content provider, and you decide to only source the content via IPv4 connectivity going forward, the assumption you're making is that each and every ISP out is in charge of the quality of your service, even when the ISPs are internally doing engineering gymnastics with types of NAT to provide the connectivity. /John From jgreco at ns.sol.net Thu Apr 8 07:51:47 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 8 Apr 2010 07:51:47 -0500 (CDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <5C00010B-856A-4ADC-A3EF-6E4CC7E9D170@sackheads.org> from "John Payne" at Apr 07, 2010 06:31:16 PM Message-ID: <201004081251.o38Cpl5W017606@aurora.sol.net> > On Apr 7, 2010, at 12:09 PM, John Palmer (NANOG Acct) wrote: > > > Was looking at the ARIN IP6 policy and cannot find any reference to those who have > > IP4 legacy space. > > > > Isn't there an automatic allocation for those of us who have legacy IP space. If not, is ARIN > > saying we have to pay them a fee to use IP6? Isn't this a disincentive for us to move up to IP6? > > > > Those with legacy IP4 space should have the equivalent IP6 space under the same terms. Or > > am I missing something? > > If you don't have a contract with ARIN, why should ARIN provide you with anything? Because a legacy holder doesn't care about ARIN; a legacy holder has usable space that cannot be reclaimed by ARIN and who is not paying anything to ARIN. The point here is that this situation does not encourage adoption of IPv6, where suddenly there'd be an annual fee and a contract for the space. "ARIN" is incidental, simply the RIR responsible in this case. ... 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 adrian at creative.net.au Thu Apr 8 08:00:52 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 8 Apr 2010 21:00:52 +0800 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004081251.o38Cpl5W017606@aurora.sol.net> References: <5C00010B-856A-4ADC-A3EF-6E4CC7E9D170@sackheads.org> <201004081251.o38Cpl5W017606@aurora.sol.net> Message-ID: <20100408130052.GD22122@skywalker.creative.net.au> On Thu, Apr 08, 2010, Joe Greco wrote: > Because a legacy holder doesn't care about ARIN; a legacy holder has > usable space that cannot be reclaimed by ARIN and who is not paying > anything to ARIN. The point here is that this situation does not > encourage adoption of IPv6, where suddenly there'd be an annual fee > and a contract for the space. "ARIN" is incidental, simply the RIR > responsible in this case. Out of curiousity, I wonder whether the adoption of the internet in the 90s would have occured if IPv4 addresses were allocated, managed and controlled like they are today. Adrian From jgreco at ns.sol.net Thu Apr 8 08:00:54 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 8 Apr 2010 08:00:54 -0500 (CDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4BBD10F6.9080409@zill.net> from "Patrick Giagnocavo" at Apr 07, 2010 07:10:46 PM Message-ID: <201004081300.o38D0tic017897@aurora.sol.net> > Joe Greco wrote: > > It's not the initial assignment fee that's really an impediment, it's > > moving from a model where the address space is free (or nearly so) to > > a model where you're paying a significant annual fee for the space. > > > > We'd be doing IPv6 here if not for the annual fee. As it stands, there > > isn't that much reason to do IPv6, and a significant disincentive in the > > form of the fees. > > > > ... JG > > > I have to agree ... why such high charges when a similar service like > GoDaddy provides (domain name registrar) is $15 a year? > > Is it REALLY X times the level of difficulty of registering a domain > name, and thus the charges are justified? I will let someone who is > very technical explain this to me. Because when ARIN gets into a legal p***ing match with someone (Kremen, etc), the cash to fight that comes from somewhere. When you're registering many millions of domain names, that's going to generate more revenue even at the lower price than what ARIN brings in. ... 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 jgreco at ns.sol.net Thu Apr 8 08:08:24 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 8 Apr 2010 08:08:24 -0500 (CDT) Subject: Hubs on a NIC (was:Re: what about 48 bits?) In-Reply-To: from "Steven Bellovin" at Apr 07, 2010 09:00:00 PM Message-ID: <201004081308.o38D8Owp018769@aurora.sol.net> > When I had the need to wire a building around 1987, I opted for the > multiport 10Base5 repeaters that DEC made -- they were called DELUAs, > I think. I'd had quite enough of distributed single points of failure, > thank you. Think those were something else; DEMPR = Digital Ethernet Multi Port Repeater DELNI = Digital Ethernet Local Network Interconnect ("hub") Threw some away a few years ago. > Hey, I had that in my house on my 100BaseT network, till I upgraded > to gigE and had to give in and buy another switch. (Sigh -- home > network configurations of NANOGers. I'm contemplating putting in > VLANs now...) VLAN's == fun ... 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 john at sackheads.org Thu Apr 8 08:57:56 2010 From: john at sackheads.org (John Payne) Date: Thu, 8 Apr 2010 09:57:56 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004081251.o38Cpl5W017606@aurora.sol.net> References: <201004081251.o38Cpl5W017606@aurora.sol.net> Message-ID: On Apr 8, 2010, at 8:51 AM, Joe Greco wrote: >> On Apr 7, 2010, at 12:09 PM, John Palmer (NANOG Acct) wrote: >> >>> Was looking at the ARIN IP6 policy and cannot find any reference to those who have >>> IP4 legacy space. >>> >>> Isn't there an automatic allocation for those of us who have legacy IP space. If not, is ARIN >>> saying we have to pay them a fee to use IP6? Isn't this a disincentive for us to move up to IP6? >>> >>> Those with legacy IP4 space should have the equivalent IP6 space under the same terms. Or >>> am I missing something? >> >> If you don't have a contract with ARIN, why should ARIN provide you with anything? > > Because a legacy holder doesn't care about ARIN; a legacy holder has > usable space that cannot be reclaimed by ARIN and who is not paying > anything to ARIN. The point here is that this situation does not > encourage adoption of IPv6, where suddenly there'd be an annual fee > and a contract for the space. "ARIN" is incidental, simply the RIR > responsible in this case. Umm, ARIN should provide a legacy holder with IPv6 space because the legacy holder doesn't care about ARIN? Legacy holders have been holding parts (possibly more than they would be able to justify from an RIR) of a finite global shared resource without sharing in the costs associated, and it's unfair to _them_ that they're not _entitled_ to do the same in the IPv6 space? Yep, makes perfect sense to me. If the "rest of the world" moving to IPv6 isn't enough encouragement for you, then bleh. I'm only interested in encouraging my employer and my providers. If you have no need to reach IPv6-only content or eyeballs, and you don't care about NAT or geolocation issues with centralized NAT or.... then sure, you have no encouragement or need to adopt IPv6. If you do need to reach IPv6-only content or eyeballs, then that is your encouragement to play in the same playing field as everyone else in your RIR-area. From bill at herrin.us Thu Apr 8 09:52:43 2010 From: bill at herrin.us (William Herrin) Date: Thu, 8 Apr 2010 10:52:43 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <5C00010B-856A-4ADC-A3EF-6E4CC7E9D170@sackheads.org> References: <18459664B284412885743075C7E0C621@TAKA> <5C00010B-856A-4ADC-A3EF-6E4CC7E9D170@sackheads.org> Message-ID: On Wed, Apr 7, 2010 at 6:31 PM, John Payne wrote: >> Those with legacy IP4 space should have the equivalent IP6 >> space under the same terms. Or am I missing something? > > If you don't have a contract with ARIN, why should ARIN >provide you with anything? Because ARIN is one of the guardians of Internet public policy and it is in the public's best interest for every individual private organization to spend the money and effort deploying IPv6 sooner rather than later, regardless of their individual relationships with ARIN. It's like government services for the elderly. Though today many are a net drain on society, they've mostly earned their place with past action and it's the decent and charitable thing to do for the folks who created the possibility of the lives we enjoy today. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dhubbard at dino.hostasaurus.com Thu Apr 8 10:07:05 2010 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 8 Apr 2010 11:07:05 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space Message-ID: From: William Herrin [mailto:bill at herrin.us] > > > It's like government services for the elderly. Though today many are a > net drain on society, they've mostly earned their place with past > action and it's the decent and charitable thing to do for the folks > who created the possibility of the lives we enjoy today. > LOL! I'm sure most legacy orgs are living on a fixed income and just trying to get by; here I was not even feeling sorry for them that they can't have some free IPv6 allocations when they're just trying to survive. ARIN's fees are hardly unreasonable, they need to stop crying and join the rest of us that haven't had to make their businesses work without the luxury of a free handout. From jgreco at ns.sol.net Thu Apr 8 10:36:22 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 8 Apr 2010 10:36:22 -0500 (CDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: from "John Payne" at Apr 08, 2010 09:57:56 AM Message-ID: <201004081536.o38FaMKQ025021@aurora.sol.net> > > > On Apr 8, 2010, at 8:51 AM, Joe Greco wrote: > > >> On Apr 7, 2010, at 12:09 PM, John Palmer (NANOG Acct) wrote: > >> > >>> Was looking at the ARIN IP6 policy and cannot find any reference to those who have > >>> IP4 legacy space. > >>> > >>> Isn't there an automatic allocation for those of us who have legacy IP space. If not, is ARIN > >>> saying we have to pay them a fee to use IP6? Isn't this a disincentive for us to move up to IP6? > >>> > >>> Those with legacy IP4 space should have the equivalent IP6 space under the same terms. Or > >>> am I missing something? > >> > >> If you don't have a contract with ARIN, why should ARIN provide you with anything? > > > > Because a legacy holder doesn't care about ARIN; a legacy holder has > > usable space that cannot be reclaimed by ARIN and who is not paying > > anything to ARIN. The point here is that this situation does not > > encourage adoption of IPv6, where suddenly there'd be an annual fee > > and a contract for the space. "ARIN" is incidental, simply the RIR > > responsible in this case. > > Umm, ARIN should provide a legacy holder with IPv6 space because the > legacy holder doesn't care about ARIN? No. Legacy holders have little incentive to implement IPv6 because they have their v4 resources; this is a partial impediment to forward progress in the implementation of v6. If the Internet community really wanted to motivate transition to v6, it would make reasonable sense to allocate space to all interested v4 stakeholders at rates and preferably on terms similar to what those stakeholders currently have. This is independent of any particular RIR; the only reason ARIN might be involved is that ARIN is currently vaguely responsible for those legacy delegations, and is therefore the logically responsible entity for such a policy. ICANN could make the decision for all I care. > Legacy holders have been holding parts (possibly more than they would > be able to justify from an RIR) of a finite global shared resource > without sharing in the costs associated, and it's unfair to _them_ > that they're not _entitled_ to do the same in the IPv6 space? When ARIN's costs are largely legal costs to go "enforcing" v4 policy and a bureaucracy to go through all the policy and paperwork? The finiteness of the resource is irrelevant; it does not cost ARIN any more or less to do its task in the v4 arena. There is a cost to the global Internet for v4 depletion, yes, but ARIN is not paying any of us for forwarding table entries or forced use of NAT due to lack of space, so to imply that ARIN's expenses are in any way related to the finiteness of the resource is a laughable argument (you're 8 days late). It would be better to dismantle the current ARIN v6 framework and do a separate v6 RIR. In v6, there's an extremely limited need to go battling things in court, one could reduce expenses simply by giving the benefit of the doubt and avoiding stuff like Kremen entirely. In the old days, nearly anyone could request -and receive- a Class C or even Class B with very little more than some handwaving. The main reason to tighten that up was depletion; with IPv6, it isn't clear that the allocation function needs to be any more complex than what used to exist, especially for organizations already holding v4 resources. So, my challenges to you: 1) Justify why we need a heavy bureaucracy such as ARIN for IPv6 numbering resources, 2) Tell me why something like the old pre-depletion pre-ARIN model of InterNIC and just handing out prefixes with substantially less paper-pushing wouldn't result in a cheaper-to-run RIR. > Yep, makes perfect sense to me. > > If the "rest of the world" moving to IPv6 isn't enough > encouragement for you, then bleh. So far, the rest of the world ISN'T moving to IPv6. A small percentage is, and it's almost entirely dual-stack anyways. > I'm only interested in encouraging my employer and my providers. > If you have no need to reach IPv6-only content or eyeballs, and > you don't care about NAT or geolocation issues with centralized > NAT or.... then sure, you have no encouragement or need to adopt > IPv6. If you do need to reach IPv6-only content or eyeballs, > then that is your encouragement to play in the same playing > field as everyone else in your RIR-area. IPv6-only content won't be meaningful for years yet, and IPv6-only eyeballs will necessarily be given ways to reach v4 for many years to come. ... 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 awacs at ziskind.us Thu Apr 8 10:52:48 2010 From: awacs at ziskind.us (N. Yaakov Ziskind) Date: Thu, 8 Apr 2010 11:52:48 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: Message-ID: <20100408115248.A15214@egps.egps.com> David Hubbard wrote (on Thu, Apr 08, 2010 at 11:07:05AM -0400): > From: William Herrin [mailto:bill at herrin.us] > > > > > > It's like government services for the elderly. Though today many are a > > net drain on society, they've mostly earned their place with past > > action and it's the decent and charitable thing to do for the folks > > who created the possibility of the lives we enjoy today. > > > > LOL! I'm sure most legacy orgs are living on a fixed > income and just trying to get by; here I was not > even feeling sorry for them that they can't have some > free IPv6 allocations when they're just trying to survive. > > ARIN's fees are hardly unreasonable, they need to stop > crying and join the rest of us that haven't had to > make their businesses work without the luxury of a > free handout. Is this just an argument about the money? Or, are there other issues ("you agree that we can revoke your allocation at any time, for any reason, as we see fit")? -- _________________________________________ 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 trejrco at gmail.com Thu Apr 8 10:54:37 2010 From: trejrco at gmail.com (TJ) Date: Thu, 8 Apr 2010 11:54:37 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004081536.o38FaMKQ025021@aurora.sol.net> References: <201004081536.o38FaMKQ025021@aurora.sol.net> Message-ID: > > IPv6-only content won't be meaningful for years yet, and IPv6-only > eyeballs will necessarily be given ways to reach v4 for many years > to come. To be fair - IPv6 only content may not exactly be commonplace, but there are IPv6-only networks out there ... they just tend to consist of "things" rather than "people". For the "surfable internet", the chicken-and-egg scenario continues - as more services get reachable, it should create impetus for users - all dual stack (hopefully) ... until a threshold is crossed, when it becomes more feasible to be a general consumer who was IPv6-only (or really bad IPv4 alongside it). I also think "for years" and "for many years" are very relative terms :) ... /TJ From jgreco at ns.sol.net Thu Apr 8 11:00:37 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 8 Apr 2010 11:00:37 -0500 (CDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <20100408115248.A15214@egps.egps.com> from "N. Yaakov Ziskind" at Apr 08, 2010 11:52:48 AM Message-ID: <201004081600.o38G0bCg026452@aurora.sol.net> > Is this just an argument about the money? Or, are there other issues > ("you agree that we can revoke your allocation at any time, for any > reason, as we see fit")? I'd be curious to know what the justification for such a policy would be under v6. Even if space were obtained under false pretenses, the cost of reclaiming it (in terms of lawsuits, etc) is essentially being shoveled onto the shoulders of others who have received allocations. It seems like you could run an RIR more cheaply by simply handing out the space fairly liberally, which would have the added benefit of encouraging v6 adoption. The lack of a need for onerous contractual clauses as suggested above, combined with less overhead costs, ought to make v6 really cheap. ... 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 bdflemin at gmail.com Thu Apr 8 11:02:36 2010 From: bdflemin at gmail.com (Brad Fleming) Date: Thu, 8 Apr 2010 11:02:36 -0500 Subject: Peering Exchange Configurations Message-ID: <9A0CBD30-7766-4773-9B40-20A28F4415EA@gmail.com> Hello All, First, apologies for the change in email address.. my work account was getting a little busy so I've moved my lists to my Gmail account. But onward.. I'm interested in peering exchange design. We are not lucky enough to have access to a peering exchange so I have no direct experience. My questions are as follows: 1) Is a private AS typically used for the exchange side of the session? 2) Are RFC1918 IPs typically used for the p2p links into the exchange? 3) Do peering exchanges typically remove their AS from the path advertised to exchange participants? 3a) If no: Do participants typically preference exchange-learned routes over other sources? 4) Do exchanges typically support the following address families? IPv4 Multicast IPv6 Unicast IPv6 Multicast In exchanges where a route server is employed: 4) Do participants have a p2p link into a simple routing environment then multi-hop to a route server? 5) I see that Bird, OpenBDGd, and Quagga are all options for route server software. Does one of those packages stand out as the clear current choice for production peering exchanges? I very much appreciate any responses. -- Brad Fleming From stucchi at briantel.com Thu Apr 8 11:25:56 2010 From: stucchi at briantel.com (Massimiliano Stucchi) Date: Thu, 08 Apr 2010 18:25:56 +0200 Subject: Peering Exchange Configurations In-Reply-To: <9A0CBD30-7766-4773-9B40-20A28F4415EA@gmail.com> References: <9A0CBD30-7766-4773-9B40-20A28F4415EA@gmail.com> Message-ID: <4BBE0394.6070901@briantel.com> On 08/04/10 18:02, Brad Fleming wrote: > 1) Is a private AS typically used for the exchange side of the session? No. Everybody uses his own AS number to establish sessions at peering points. > 2) Are RFC1918 IPs typically used for the p2p links into the exchange? No. You usually get an IP address from the IX which pertains to the IX's AS, and sits in a class that's specifically not announced to the outside world. > 3) Do peering exchanges typically remove their AS from the path > advertised to exchange participants? This is the case that happens if you use a route server. Being at a peering exchange point means you have the chance to sit on a switch where other participants are directly connected. At this point you can either establish direct peering relationships (configuring a session for each peering agreement you get) or create a session with the local route server, getting routes from all the other participants. > 3a) If no: Do participants typically preference exchange-learned > routes over other sources? It depends. It's mostly a matter of economics more than a personal choice. > In exchanges where a route server is employed: > 4) Do participants have a p2p link into a simple routing environment > then multi-hop to a route server? The route server usually sits on the same LAN segment as the IXP participants. > 5) I see that Bird, OpenBDGd, and Quagga are all options for route > server software. Does one of those packages stand out as the clear > current choice for production peering exchanges? I would say that OpenBGPd and BIRD are your best choices for this. Quagga is getting better now, but suffered lots of problems with a high number of peers in the past at many IXes. That's why many migrated either to OpenBGPd, BIRD or both. Ciao! -- Massimiliano Stucchi BrianTel Srl stucchi at briantel.com From jabley at hopcount.ca Thu Apr 8 11:29:57 2010 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 8 Apr 2010 12:29:57 -0400 Subject: Peering Exchange Configurations In-Reply-To: <9A0CBD30-7766-4773-9B40-20A28F4415EA@gmail.com> References: <9A0CBD30-7766-4773-9B40-20A28F4415EA@gmail.com> Message-ID: <3018ECB0-5A60-400C-8BE1-4A805C95373A@hopcount.ca> On 2010-04-08, at 12:02, Brad Fleming wrote: > 1) Is a private AS typically used for the exchange side of the session? No. Also many exchange points do not run route servers at all, and expect participants to build bilateral BGP sessions directly between each other. > 2) Are RFC1918 IPs typically used for the p2p links into the exchange? No. Participants in an exchange typically number their exchange-facing interfaces out of a larger (non-p2p) subnet, e.g. an IPv4 /24 or /23, or an IPv6 /48 (or both). > 3) Do peering exchanges typically remove their AS from the path advertised to exchange participants? Some do, I hear. See above regarding route servers. > 3a) If no: Do participants typically preference exchange-learned routes over other sources? Many people apply a higher LOCAL_PREF to routes learnt over an exchange in order to prefer cheap peering routes over more expensive transit routes. This is not universal, however. I know of networks who deliberately flatten LOCAL_PREF across peering and transit sessions in order to use different discriminators for exit selection (e.g. AS_PATH length). > 4) Do exchanges typically support the following address families? > IPv4 Multicast > IPv6 Unicast > IPv6 Multicast I'm quite ignorant of multicast. IPv6 unicast peering is common. > In exchanges where a route server is employed: > 4) Do participants have a p2p link into a simple routing environment then multi-hop to a route server? In all exchange points I have seen where a route server was available, the route server appears on the shared fabric numbered just as any other participant would be. > 5) I see that Bird, OpenBDGd, and Quagga are all options for route server software. Does one of those packages stand out as the clear current choice for production peering exchanges? BIRD seems to be the choice du jour based on idle hallway chatter, but I have not compared them. Joe From Grzegorz at Janoszka.pl Thu Apr 8 11:33:42 2010 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Thu, 08 Apr 2010 18:33:42 +0200 Subject: China prefix hijack Message-ID: <4BBE0566.6080208@Janoszka.pl> Just half an hour ago China Telecom hijacked one of our prefixes: Your prefix: X.Y.Z.0/19: Prefix Description: NETNAME Update time: 2010-04-08 15:58 (UTC) Detected by #peers: 1 Detected prefix: X.Y.Z.0/19 Announced by: AS23724 (CHINANET-IDC-BJ-AP IDC, China Telecommunications Corporation) Upstream AS: AS4134 (CHINANET-BACKBONE No.31,Jin-rong Street) ASpath: 39792 4134 23724 23724 Luckily it had to be limited as only one BGPmon peer saw it. Anyone else noticed it? -- Grzegorz Janoszka From owen at delong.com Thu Apr 8 11:34:17 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 8 Apr 2010 09:34:17 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <22087.1270676886@localhost> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <22087.1270676886@localhost> Message-ID: This assumes that small = /40 and large = /22. Still, with more realistic numbers: The small guy (/48) pays $0.019073486 per /64 The large guy (/24) pays $0.000000032741808 per /64 FWIW. Owen On Apr 7, 2010, at 2:48 PM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 07 Apr 2010 14:17:49 PDT, "Gary E. Miller" said: > >> Then scroll down to the fees you can expect in 2013. Especially note >> how the small guys get hit much harder per IP. > > The small guys pay: $0.000074505805969 per /64. ($1250 / (2^(64-40)) > The big guys pay: $0.000000008185452 per /64. ($36000 / (2^(64-22)) > > The small guys are still paying less than 1/100th of a penny per /64. Assuming > your salary plus overhead is $40/hour, each *second* of your time is worth > more than the cost of 150 /64s. > > Oh, the inhumanity. From copraphage at gmail.com Thu Apr 8 11:39:57 2010 From: copraphage at gmail.com (Chris McDonald) Date: Thu, 8 Apr 2010 12:39:57 -0400 Subject: China prefix hijack In-Reply-To: <4BBE0566.6080208@Janoszka.pl> References: <4BBE0566.6080208@Janoszka.pl> Message-ID: i think so yeah AS 23724 is now announcing 63.218.188.0/22 which is historically announced by ASes: 3491. Time: Thu Apr 8 16:55:02 2010 GMT Observed path: 812 174 4134 23724 23724 On Thu, Apr 8, 2010 at 12:33 PM, Grzegorz Janoszka wrote: > > Just half an hour ago China Telecom hijacked one of our prefixes: > > Your prefix: X.Y.Z.0/19: > Prefix Description: NETNAME > Update time: 2010-04-08 15:58 (UTC) > Detected by #peers: 1 > Detected prefix: X.Y.Z.0/19 > Announced by: AS23724 (CHINANET-IDC-BJ-AP IDC, China > Telecommunications Corporation) > Upstream AS: AS4134 (CHINANET-BACKBONE No.31,Jin-rong Street) > ASpath: 39792 4134 23724 23724 > > Luckily it had to be limited as only one BGPmon peer saw it. Anyone else > noticed it? > > -- > Grzegorz Janoszka > > From elmi at 4ever.de Thu Apr 8 11:42:16 2010 From: elmi at 4ever.de (Elmar K. Bins) Date: Thu, 8 Apr 2010 18:42:16 +0200 Subject: Peering Exchange Configurations In-Reply-To: <3018ECB0-5A60-400C-8BE1-4A805C95373A@hopcount.ca> References: <9A0CBD30-7766-4773-9B40-20A28F4415EA@gmail.com> <3018ECB0-5A60-400C-8BE1-4A805C95373A@hopcount.ca> Message-ID: <20100408164216.GP1403@ronin.4ever.de> Re JOe, jabley at hopcount.ca (Joe Abley) wrote: > > 1) Is a private AS typically used for the exchange side of the session? > No. Also many exchange points do not run route servers at all, and expect participants to build bilateral BGP sessions directly between each other. ...which is a shame. Routeservers in place gives you a nice benefit upon hooking up to the exchange and before you have even found out who is on the grid (anyone have a list for NOTA?). Basically, the bigger exchange points (as in "european" mostly) all have routeservers ready, but not everybody chooses to use them. > > 2) Are RFC1918 IPs typically used for the p2p links into the exchange? > No. Participants in an exchange typically number their exchange-facing interfaces out of a larger (non-p2p) subnet, e.g. an IPv4 /24 or /23, or an IPv6 /48 (or both). Using RFC1918 for oft-traversed addresses is also not a good idea ;) > > 3) Do peering exchanges typically remove their AS from the path advertised to exchange participants? > Some do, I hear. See above regarding route servers. None of the routeservers I am peering with does insert their ASN. On direct peering sessions, there is of course nobody in between. > > 4) Do exchanges typically support the following address families? > > IPv4 Multicast > > IPv6 Unicast > > IPv6 Multicast > > I'm quite ignorant of multicast. IPv6 unicast peering is common. Multicast is still seen as something special, sometimes even on dedicated hardware, or on different VLANs. It's certainly possible, but usually there are not so many participants... > > 5) I see that Bird, OpenBDGd, and Quagga are all options for route server software. Does one of those packages stand out as the clear current choice for production peering exchanges? > > BIRD seems to be the choice du jour based on idle hallway chatter, but I have not compared them. I was thinking "plat du jour"...and well, it's "du jour", so it can change in an instant. Cheers, Elmar. From Grzegorz at Janoszka.pl Thu Apr 8 11:44:14 2010 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Thu, 08 Apr 2010 18:44:14 +0200 Subject: Peering Exchange Configurations In-Reply-To: <9A0CBD30-7766-4773-9B40-20A28F4415EA@gmail.com> References: <9A0CBD30-7766-4773-9B40-20A28F4415EA@gmail.com> Message-ID: <4BBE07DE.6020403@Janoszka.pl> On 8-4-2010 18:02, Brad Fleming wrote: > 1) Is a private AS typically used for the exchange side of the session? No. > 2) Are RFC1918 IPs typically used for the p2p links into the exchange? No. In EU usually it is separate public /24, /23 or /22. The IPv6 range in RIPE region for exchanges is assigned from within special pool 2001:7f8::/32 (each IX gets /48). > 3) Do peering exchanges typically remove their AS from the path > advertised to exchange participants? The direct peering is between participants AS'es, there is nothing in between, including IX AS. Route-servers based on Cisco box put their AS number in between, but Quagga/Bird usually remove the IX as, however it may be configured per peer not to do so. > 3a) If no: Do participants typically preference exchange-learned routes > over other sources? Most do. > 4) Do exchanges typically support the following address families? > IPv4 Multicast no > IPv6 Unicast Almost all. > IPv6 Multicast No. > In exchanges where a route server is employed: > 4) Do participants have a p2p link into a simple routing environment > then multi-hop to a route server? Route-server is just like one of the members of the exchange. You get /23 or similar prefix of the exchange. You may have a BGP session with the route-server, but you are also free to have direct BGP sessions with other parties. Route-servers are mostly used by peers with open peering policies, but you still may steer your announcements basing on BGP communities. > 5) I see that Bird, OpenBDGd, and Quagga are all options for route > server software. Does one of those packages stand out as the clear > current choice for production peering exchanges? Quagga was used most often, but recently most biggest EU exchanges replaced it with Bird and it is much more stable. -- Grzegorz Janoszka From jabley at hopcount.ca Thu Apr 8 11:47:45 2010 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 8 Apr 2010 12:47:45 -0400 Subject: Peering Exchange Configurations In-Reply-To: <20100408164216.GP1403@ronin.4ever.de> References: <9A0CBD30-7766-4773-9B40-20A28F4415EA@gmail.com> <3018ECB0-5A60-400C-8BE1-4A805C95373A@hopcount.ca> <20100408164216.GP1403@ronin.4ever.de> Message-ID: <16B7DAA5-28C0-4D91-AAD7-A3B300BD51C7@hopcount.ca> On 2010-04-08, at 12:42, Elmar K. Bins wrote: > jabley at hopcount.ca (Joe Abley) wrote: > >>> 1) Is a private AS typically used for the exchange side of the session? >> No. Also many exchange points do not run route servers at all, and expect participants to build bilateral BGP sessions directly between each other. > > ...which is a shame. Routeservers in place gives you a nice benefit > upon hooking up to the exchange and before you have even found out > who is on the grid (anyone have a list for NOTA?). I've never had a problem getting a participant list for NOTA from Terremark. One down-side of route servers on a shared exchange fabric is that the layer-2 path through the exchange for the BGP sessions does not always match the layer-2 path through the exchange for traffic. This means that AS1 might continue to learn AS2's routes through the route server even though there's a layer-2 problem that prevents AS1 and AS2's peering routers from talking directly to each other. Hilarity may result. I've never seen such a problem on small exchanges where the layer-2 fabric is simple, but I have seen it more than once on larger, more complicated exchanges. My personal preference is to focus peering energy on bilats, and not to rely on a route server. But I understand the savings in opex that route servers can provide on busy exchanges. Joe From Valdis.Kletnieks at vt.edu Thu Apr 8 11:48:17 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 08 Apr 2010 12:48:17 -0400 Subject: China prefix hijack In-Reply-To: Your message of "Thu, 08 Apr 2010 18:33:42 +0200." <4BBE0566.6080208@Janoszka.pl> References: <4BBE0566.6080208@Janoszka.pl> Message-ID: <16130.1270745297@localhost> On Thu, 08 Apr 2010 18:33:42 +0200, Grzegorz Janoszka said: > Your prefix: X.Y.Z.0/19: > Detected prefix: X.Y.Z.0/19 > Luckily it had to be limited as only one BGPmon peer saw it. Anyone else > noticed it? Sorry, I'm not seeing an announcement for X.Y.Z.0/19 here. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ccosta at cenic.org Thu Apr 8 11:52:20 2010 From: ccosta at cenic.org (Chris Costa) Date: Thu, 8 Apr 2010 09:52:20 -0700 Subject: Peering Exchange Configurations In-Reply-To: <3018ECB0-5A60-400C-8BE1-4A805C95373A@hopcount.ca> References: <9A0CBD30-7766-4773-9B40-20A28F4415EA@gmail.com> <3018ECB0-5A60-400C-8BE1-4A805C95373A@hopcount.ca> Message-ID: Some Research&Education type peering exchanges, like Pacific Wave http://www.pacificwave.net/ , support ipv4 multicast forwarding. As an exchange operator you'd want to support PIM-Snooping and the ability to disable DR-Flooding to control those flows just to the networks that joined them. Chris -- Chris Costa CENIC ccosta at cenic.org On Apr 8, 2010, at 9:29 AM, Joe Abley wrote: > >> 4) Do exchanges typically support the following address families? >> IPv4 Multicast >> IPv6 Unicast >> IPv6 Multicast > From khuon at neebu.net Thu Apr 8 11:48:18 2010 From: khuon at neebu.net (Jake Khuon) Date: Thu, 08 Apr 2010 09:48:18 -0700 Subject: Peering Exchange Configurations In-Reply-To: <9A0CBD30-7766-4773-9B40-20A28F4415EA@gmail.com> References: <9A0CBD30-7766-4773-9B40-20A28F4415EA@gmail.com> Message-ID: <1270745299.12732.16.camel@localhost> On Thu, 2010-04-08 at 11:02 -0500, Brad Fleming wrote: > 1) Is a private AS typically used for the exchange side of the session? Not in a typical public internet exchange. that said, there is no reason why one could not build an exchange point that uses private ASNs. One might do this for a specialised application of PPVPN peering partners but that is beyond what you are asking. > 2) Are RFC1918 IPs typically used for the p2p links into the exchange? No. Public IXPs will provide an address space for its participants to use. That said, once again, there might be some very specific non-public applications of exchange points which may use RFC1918 address space. > 3) Do peering exchanges typically remove their AS from the path > advertised to exchange participants? I'm assuming you are talking about routes exchanged via a route-server. Most moderm deployments of RSes do act transparently but in the past there have been cases where some exchange point participants did want to see the RS' ASN in the ASPATH. Merit's old RSes had the capbility to turn on or off transparency on a peer-by-peer basis. I am not sure about modern RS implementations. > 3a) If no: Do participants typically preference exchange-learned > routes over other sources? That is a matter of personal reference and religion. But in my experience at larger exchanges with bigger players, the RSes' routes are considered secondary and less preferred. > 4) Do exchanges typically support the following address families? > IPv4 Multicast > IPv6 Unicast > IPv6 Multicast IPv4 multicast and IPv6 unicast seems standard in modern IXPs but I'm not sure about IPv6 multicast. > In exchanges where a route server is employed: > 4) Do participants have a p2p link into a simple routing environment > then multi-hop to a route server? Not in modern exchange points. In some older ones this was the case but I think that's largely historic. > 5) I see that Bird, OpenBDGd, and Quagga are all options for route > server software. Does one of those packages stand out as the clear > current choice for production peering exchanges? I wouldn't say clear but BIRD seems to be gaining ground on the other two. There were some talk given at the last NANOG meeting in the route- servers track... http://www.nanog.org/meetings/nanog48/abstracts.php?pt=MTUxMyZuYW5vZzQ4&nm=nanog48 -- /*=================[ Jake Khuon ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ From oneil at oclc.org Thu Apr 8 11:54:58 2010 From: oneil at oclc.org (O'Neil,Kevin) Date: Thu, 8 Apr 2010 12:54:58 -0400 Subject: another report of possible prefix hijack by ASN in China Message-ID: <4E7C2F493C1A1A44BE705AFDCEE8A1330718484B@OAEXCH2SERVER.oa.oclc.org> We also got a BGPmon notification of a possible prefix hijack: ==================================================================== Possible Prefix Hijack (Code: 10) ==================================================================== Your prefix: 206.107.43.0/24: Update time: 2010-04-08 15:58 (UTC) Detected by #peers: 1 Detected prefix: 206.107.43.0/24 Announced by: AS23724 (CHINANET-IDC-BJ-AP IDC, China Telecommunications Corporation) Upstream AS: AS4134 (CHINANET-BACKBONE No.31,Jin-rong Street) ASpath: 39792 4134 23724 23724 All of our prefixes (8) were detected as possible hijacks. ...Kevin O'Neil From owen at delong.com Thu Apr 8 11:54:21 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 8 Apr 2010 09:54:21 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004081536.o38FaMKQ025021@aurora.sol.net> Message-ID: <250CFBF9-844D-4057-B769-7B87941AF910@delong.com> On Apr 8, 2010, at 8:54 AM, TJ wrote: >> >> IPv6-only content won't be meaningful for years yet, and IPv6-only >> eyeballs will necessarily be given ways to reach v4 for many years >> to come. > > > To be fair - IPv6 only content may not exactly be commonplace, but there are > IPv6-only networks out there ... they just tend to consist of "things" > rather than "people". > > For the "surfable internet", the chicken-and-egg scenario continues - as > more services get reachable, it should create impetus for users - all dual > stack (hopefully) ... until a threshold is crossed, when it becomes more > feasible to be a general consumer who was IPv6-only (or really bad IPv4 > alongside it). I also think "for years" and "for many years" are very > relative terms :) ... > > > /TJ I think that the creation of consumers with IPv6-only or really bad IPv4 along side it will result sooner than any threshold of IPv6-ready content is reached. I think this will be the result of not having IPv4 addresses to give those consumers rather than the result of IPv6 deployment. Owen From lee at asgard.org Thu Apr 8 12:01:46 2010 From: lee at asgard.org (Lee Howard) Date: Thu, 8 Apr 2010 13:01:46 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004081600.o38G0bCg026452@aurora.sol.net> References: <20100408115248.A15214@egps.egps.com> from "N. Yaakov Ziskind" at Apr 08, 2010 11:52:48 AM <201004081600.o38G0bCg026452@aurora.sol.net> Message-ID: <000601cad73d$2cac32a0$860497e0$@org> > -----Original Message----- > From: Joe Greco [mailto:jgreco at ns.sol.net] > It seems like you could run an RIR more cheaply by simply handing out > the space fairly liberally, which would have the added benefit of > encouraging v6 adoption. The lack of a need for onerous contractual > clauses as suggested above, combined with less overhead costs, ought > to make v6 really cheap. For "fairly liberally" see: For ISPs: https://www.arin.net/policy/nrpm.html#six51 You have to be an ISP with a plan to have 200 assignment in 5 years Non-ISP: https://www.arin.net/policy/nrpm.html#six58 Be not-an-ISP and have a need for addresses (per other policies, you get to choose which one). In another post you asked essentially "why does ARIN charge so much?" ARIN doesn't just maintain a notebook of address assignments. There are HA servers for Whois, IN-ADDR. and IP6.ARPA, research in things like SIDR, DNSsec, other tools-services, and educational outreach on IPv6. You suggest that there's much less to argue about in IPv6 policy, but if you look at current proposals (https://www.arin.net/policy/proposals/) you'll see three that are IPv6-specific, and most of the others cover both IPv4 and IPv6. So ARIN will continue to maintain the mailing lists, and hold public policy meetings (with remote participation, so anyone can participate), and facilitate elections so you can throw the bums out if you don't like how we do things. We don't really know how much IPv6 will cost ARIN. If there were no more debate about allocation policies, and nobody else had any interest in us (politically or litigiously), and technology were fairly static, then we might just do periodic tech refreshes and be fine. I imagine all of those things will continue for a while, though, and ARIN will need to be financially solvent through the transition. Your ARIN fee does not cover me posting here. That's gratis, and worth it. Lee From andree+nanog at toonk.nl Thu Apr 8 12:15:19 2010 From: andree+nanog at toonk.nl (Andree Toonk) Date: Thu, 08 Apr 2010 10:15:19 -0700 Subject: China prefix hijack In-Reply-To: <4BBE0566.6080208@Janoszka.pl> References: <4BBE0566.6080208@Janoszka.pl> Message-ID: <4BBE0F27.9080203@toonk.nl> Hi Grzegorz, .-- My secret spy satellite informs me that at 08/04/10 9:33 AM Grzegorz Janoszka wrote: > > Just half an hour ago China Telecom hijacked one of our prefixes: > > Your prefix: X.Y.Z.0/19: > Prefix Description: NETNAME > Update time: 2010-04-08 15:58 (UTC) > Detected by #peers: 1 > Detected prefix: X.Y.Z.0/19 > Announced by: AS23724 (CHINANET-IDC-BJ-AP IDC, China Telecommunications > Corporation) > Upstream AS: AS4134 (CHINANET-BACKBONE No.31,Jin-rong Street) > ASpath: 39792 4134 23724 23724 > > Luckily it had to be limited as only one BGPmon peer saw it. Anyone else > noticed it? > Yes many prefixes have been 'impacted' by this. These include prefixes for websites such as dell.com and cnn.com. The event has been detected globally by peers in Rusia, USA, Japan and Brazil. However not all individual prefix 'hijacks' were detected globally, many only by one or 2 peers, in one or 2 countries, but some by more. The common part in the ASpath is 4134 23724 Which are: AS4134 CHINANET-BACKBONE No.31,Jin-rong Street AS23724 CHINANET-IDC-BJ-AP IDC, China Telecommunications Corporation ASns peering with AS4134 seem to have picked this up and propagated that to their customers. Some of these ASns include: AS9002 RETN-AS ReTN.net Autonomous System AS12956 TELEFONICA Telefonica Backbone Autonomous System AS209 ASN-QWEST - Qwest Communications Company, LLC AS3320 DTAG Deutsche Telekom AG AS3356 LEVEL3 Level 3 Communications AS7018 ATT-INTERNET4 - AT&T WorldNet Services All RIS peers that detected this where behind (transit/peer) one of those ANS's. Most 'alerts' have now been cleared, they typically lasted a few minutes. Cheers, Andree From bmanning at vacation.karoshi.com Thu Apr 8 12:17:40 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 8 Apr 2010 17:17:40 +0000 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <250CFBF9-844D-4057-B769-7B87941AF910@delong.com> References: <201004081536.o38FaMKQ025021@aurora.sol.net> <250CFBF9-844D-4057-B769-7B87941AF910@delong.com> Message-ID: <20100408171740.GE3358@vacation.karoshi.com.> On Thu, Apr 08, 2010 at 09:54:21AM -0700, Owen DeLong wrote: > > On Apr 8, 2010, at 8:54 AM, TJ wrote: > > >> > >> IPv6-only content won't be meaningful for years yet, and IPv6-only > >> eyeballs will necessarily be given ways to reach v4 for many years > >> to come. > > > > > > To be fair - IPv6 only content may not exactly be commonplace, but there are > > IPv6-only networks out there ... they just tend to consist of "things" > > rather than "people". > > > > For the "surfable internet", the chicken-and-egg scenario continues - as > > more services get reachable, it should create impetus for users - all dual > > stack (hopefully) ... until a threshold is crossed, when it becomes more > > feasible to be a general consumer who was IPv6-only (or really bad IPv4 > > alongside it). I also think "for years" and "for many years" are very > > relative terms :) ... > > > > > > /TJ > > I think that the creation of consumers with IPv6-only or really bad IPv4 > along side it will result sooner than any threshold of IPv6-ready content > is reached. I think this will be the result of not having IPv4 addresses > to give those consumers rather than the result of IPv6 deployment. > > Owen > on the other side of the pond, the Euros are grappling with a desire to get actual utilization of assigned numbers into something above single digits. They are shooting for 80% utilization of all assets before assigning any additional numbers. this problem has been around for a -very- long time, predating the RIRs by a couple of decades. the gist is, virtually -every- allocation/delegation exceeds the actual demand - sometimes by many orders of magnitude. in the IPv4 space, it was common to have a min allocation size of a /20 ... or 4,096 addresses ... and yet this amnt of space was allocated to someone who only needed to address "3 servers"... say six total out of a pool of four thousand ninty six. Thats a huge amnt of wasted space. If our wise and pragmatic leaders (drc, jc, et.al.) are correct, then IPv4 will be around for a very long time. What, if any, plan exists to improve the utilization density of the existant IPv4 pool? --bill From fpater at dca.net Thu Apr 8 12:19:35 2010 From: fpater at dca.net (Frank Pater) Date: Thu, 8 Apr 2010 13:19:35 -0400 Subject: China prefix hijack In-Reply-To: References: <4BBE0566.6080208@Janoszka.pl> Message-ID: <20100408171935.GD30450@staff.dca.net> Hi, We received BGPmon notifications for all of our prefixes as well. Not sure if it's relevant, but this is also announced upstream from us by 3491. Example: ==================================================================== Possible Prefix Hijack (Code: 10) ==================================================================== Your prefix: 216.158.0.0/18: Update time: 2010-04-08 15:58 (UTC) Detected by #peers: 1 Detected prefix: 216.158.0.0/18 Announced by: AS23724 (CHINANET-IDC-BJ-AP IDC, China Telecommunications Corporation) Upstream AS: AS4134 (CHINANET-BACKBONE No.31,Jin-rong Street) ASpath: 39792 4134 23724 23724 -- Frank Pater DCANet http://www.dca.net voice: 888-4-DCANET (888-432-2638) fax: 302-426-6386 On Thu, Apr 08, 2010 at 12:39:57PM -0400, Chris McDonald wrote: > i think so yeah > > AS 23724 is now announcing 63.218.188.0/22 which is historically announced > by ASes: 3491. > Time: Thu Apr 8 16:55:02 2010 GMT > Observed path: 812 174 4134 23724 23724 > > > On Thu, Apr 8, 2010 at 12:33 PM, Grzegorz Janoszka wrote: > > > > > Just half an hour ago China Telecom hijacked one of our prefixes: > > > > Your prefix: X.Y.Z.0/19: > > Prefix Description: NETNAME > > Update time: 2010-04-08 15:58 (UTC) > > Detected by #peers: 1 > > Detected prefix: X.Y.Z.0/19 > > Announced by: AS23724 (CHINANET-IDC-BJ-AP IDC, China > > Telecommunications Corporation) > > Upstream AS: AS4134 (CHINANET-BACKBONE No.31,Jin-rong Street) > > ASpath: 39792 4134 23724 23724 > > > > Luckily it had to be limited as only one BGPmon peer saw it. Anyone else > > noticed it? > > > > -- > > Grzegorz Janoszka > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stephen at sprunk.org Thu Apr 8 12:25:32 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 08 Apr 2010 12:25:32 -0500 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> Message-ID: <4BBE118C.6070602@sprunk.org> On 07 Apr 2010 16:17, Gary E. Miller wrote: > On Wed, 7 Apr 2010, Owen DeLong wrote: > >> If you are an end-user type organization, the fee is only $100/year >> for all your resources, IPv4 and IPv6 included. Is that really what >> you would call significant? >> > As always, the devil is in the deetails. > > From: https://www.arin.net/fees/fee_schedule.html#waivers > The proper URL for the below quote is . > "The annual fee will be $100 USD until 2013, at which time ARIN's Board > of Trustees may choose to raise the fee." > Note that the LRSA specifies that the fee increase cannot be more than $25/yr. > Then scroll down to the fees you can expect in 2013. Especially note > how the small guys get hit much harder per IP. > This is the section at . That section applies only to _allocations_, which are what ISPs get. The maintenance fee for _assignments_, which is what end users orgs get, has always been $100/yr. No waiver is necessary, and AFAIK the BoT has made never made any noises about increasing the assignment maintenance fee. And, really, even if the fee for your /48 (X-small category) assignment maintenance fee went up to $1250/yr to match the current allocation maintenance fee table, would that really be "significant" in the grand scheme of things? S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From jbfixurpc at gmail.com Thu Apr 8 12:27:40 2010 From: jbfixurpc at gmail.com (Joe) Date: Thu, 8 Apr 2010 13:27:40 -0400 Subject: China prefix hijack In-Reply-To: <20100408171935.GD30450@staff.dca.net> Message-ID: <001f01cad740$ccf0c390$4401a8c0@jgbpc> Just wondering if this was a "Fat fingered" mistake or intentional... -J > -----Original Message----- > From: Frank Pater [mailto:fpater at dca.net] > Sent: Thursday, April 08, 2010 1:20 PM > To: nanog at nanog.org > Subject: Re: China prefix hijack > > > Hi, > > We received BGPmon notifications for all of our prefixes as > well. Not sure if it's relevant, but this is also announced > upstream from us by 3491. Example: > > ==================================================================== > Possible Prefix Hijack (Code: 10) > ==================================================================== > Your prefix: 216.158.0.0/18: > Update time: 2010-04-08 15:58 (UTC) > Detected by #peers: 1 > Detected prefix: 216.158.0.0/18 > Announced by: AS23724 (CHINANET-IDC-BJ-AP IDC, China > Telecommunications Corporation) > Upstream AS: AS4134 (CHINANET-BACKBONE No.31,Jin-rong Street) > ASpath: 39792 4134 23724 23724 > > > -- > Frank Pater > DCANet > http://www.dca.net > voice: 888-4-DCANET (888-432-2638) > fax: 302-426-6386 > > > On Thu, Apr 08, 2010 at 12:39:57PM -0400, Chris McDonald wrote: > > i think so yeah > > > > AS 23724 is now announcing 63.218.188.0/22 which is historically > > announced by ASes: 3491. > > Time: Thu Apr 8 16:55:02 2010 GMT > > Observed path: 812 174 4134 23724 23724 > > > > > > On Thu, Apr 8, 2010 at 12:33 PM, Grzegorz Janoszka > > wrote: > > > > > > > > Just half an hour ago China Telecom hijacked one of our prefixes: > > > > > > Your prefix: X.Y.Z.0/19: > > > Prefix Description: NETNAME > > > Update time: 2010-04-08 15:58 (UTC) > > > Detected by #peers: 1 > > > Detected prefix: X.Y.Z.0/19 > > > Announced by: AS23724 (CHINANET-IDC-BJ-AP IDC, China > > > Telecommunications Corporation) > > > Upstream AS: AS4134 (CHINANET-BACKBONE > No.31,Jin-rong Street) > > > ASpath: 39792 4134 23724 23724 > > > > > > Luckily it had to be limited as only one BGPmon peer saw > it. Anyone > > > else noticed it? > > > > > > -- > > > Grzegorz Janoszka > > > > > > > > From stephen at sprunk.org Thu Apr 8 12:32:49 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 08 Apr 2010 12:32:49 -0500 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <20100407194030.A3660@egps.egps.com> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <20100407194030.A3660@egps.egps.com> Message-ID: <4BBE1341.2000706@sprunk.org> On 07 Apr 2010 18:40, N. Yaakov Ziskind wrote: > I don't think the issue is *money* (at least the big issue; money is > *always* an issue), but rather the all-of-sudden jump from being > unregulated to regulated, whatever that means. ARIN is not a regulator. The "jump" is from not paying for services that you have no contract for to paying for services that you do have a contract for. > I would think multiple times before making that jump. Hence my suggestion to set up a separate organization to request IPv6 space, and thus not 'endanger' whatever I had before. > Signing an RSA to get new space does not _in any way_ "endanger" or otherwise affect legacy resources. Putting legacy resources under LRSA (or RSA, if you wished) is a completely separate action and is, for now at least, completely optional. You do not need to set up a separate organization; all that does is waste your time and ARIN's. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From babydr at baby-dragons.com Thu Apr 8 12:42:47 2010 From: babydr at baby-dragons.com (Mr. James W. Laferriere) Date: Thu, 8 Apr 2010 09:42:47 -0800 (AKDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <000601cad73d$2cac32a0$860497e0$@org> References: <20100408115248.A15214@egps.egps.com> from "N. Yaakov Ziskind" at Apr 08, 2010 11:52:48 AM <201004081600.o38G0bCg026452@aurora.sol.net> <000601cad73d$2cac32a0$860497e0$@org> Message-ID: Hello Lee , On Thu, 8 Apr 2010, Lee Howard wrote: >> -----Original Message----- >> From: Joe Greco [mailto:jgreco at ns.sol.net] >> It seems like you could run an RIR more cheaply by simply handing out >> the space fairly liberally, which would have the added benefit of >> encouraging v6 adoption. The lack of a need for onerous contractual >> clauses as suggested above, combined with less overhead costs, ought >> to make v6 really cheap. > > For "fairly liberally" see: > For ISPs: https://www.arin.net/policy/nrpm.html#six51 > You have to be an ISP with a plan to have 200 assignment in 5 years > Non-ISP: https://www.arin.net/policy/nrpm.html#six58 > Be not-an-ISP and have a need for addresses (per other policies, > you get to choose which one). > > In another post you asked essentially "why does ARIN charge so much?" > ARIN doesn't just maintain a notebook of address assignments. There are > HA servers for Whois, IN-ADDR. and IP6.ARPA, research in things like > SIDR, DNSsec, other tools-services, and educational outreach on IPv6. > You suggest that there's much less to argue about in IPv6 policy, but if > you look at current proposals (https://www.arin.net/policy/proposals/) > you'll see three that are IPv6-specific, and most of the others cover > both IPv4 and IPv6. So ARIN will continue to maintain the mailing > lists, and hold public policy meetings (with remote participation, so > anyone can participate), and facilitate elections so you can throw the > bums out if you don't like how we do things. > > We don't really know how much IPv6 will cost ARIN. If there were > no more debate about allocation policies, and nobody else had any interest > in us (politically or litigiously), and technology were fairly static, then > we > might just do periodic tech refreshes and be fine. I imagine all of those > things will continue for a while, though, and ARIN will need to be > financially solvent through the transition. > > > Your ARIN fee does not cover me posting here. That's gratis, and > worth it. > > Lee Thank you for posting those URL's I find a completely different interpretation to the prose there . 6.5.8. Direct assignments from ARIN to end-user organizations 6.5.8.1. Criteria To qualify for a direct assignment, an organization must: 1. not be an IPv6 LIR; and 2. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect, or "demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by any current ARIN RSA", or be a qualifying Community Network as defined in Section 2.8, with assignment criteria defined in section 6.5.9. Note the ""'d section above . I as a Legacy holder of netname baby-dragons HAVE to have a Signed RSA with Airn or I am NOT , by definition , Qualified . I find the present lRSA an indecent attempt to undermine the present Legacy ipv4 holders view of the rights presented them at the time of their Assignments or Allocations . If I could find my OLD Ultrix Tarball or Dump tapes from that era , and they are still readable , I might just be able to present the conversations I had at that time with InterNIC while acquiring that Legacy Space . Might someone else have a Document or some other Recorded conversation ? Twyl , JimL ps: Back to haunting mode . -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 3237 Holden Road | Give me Linux | | babydr at baby-dragons.com | Fairbanks, AK. 99709 | only on AXP | +------------------------------------------------------------------+ From dwhite at olp.net Thu Apr 8 12:44:05 2010 From: dwhite at olp.net (Dan White) Date: Thu, 8 Apr 2010 12:44:05 -0500 Subject: China prefix hijack In-Reply-To: <001f01cad740$ccf0c390$4401a8c0@jgbpc> References: <20100408171935.GD30450@staff.dca.net> <001f01cad740$ccf0c390$4401a8c0@jgbpc> Message-ID: <20100408174405.GD4808@dan.olp.net> On 08/04/10?13:27?-0400, Joe wrote: >Just wondering if this was a "Fat fingered" mistake or intentional... If it was a mistake, I hope he fares a bit better than his counterparts in other Chinese industries... -- Dan White From mabrown at renesys.com Thu Apr 8 12:45:56 2010 From: mabrown at renesys.com (Martin A. Brown) Date: Thu, 8 Apr 2010 19:45:56 +0200 Subject: China prefix hijack In-Reply-To: <20100408174405.GD4808@dan.olp.net> References: <20100408171935.GD30450@staff.dca.net> <001f01cad740$ccf0c390$4401a8c0@jgbpc> <20100408174405.GD4808@dan.olp.net> Message-ID: Hello, Just a note of confirmation that 23724 originated as many as 31847 prefixes during an 18 minute window starting around 15:54 UTC. They were prepending their own AS, and this is several orders of magnitude more prefixes than they normally originate. -Martin -- Martin A. Brown --- Renesys Corporation --- mabrown at renesys.com From babydr at baby-dragons.com Thu Apr 8 12:49:53 2010 From: babydr at baby-dragons.com (Mr. James W. Laferriere) Date: Thu, 8 Apr 2010 09:49:53 -0800 (AKDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4BBE118C.6070602@sprunk.org> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <4BBE118C.6070602@sprunk.org> Message-ID: Hello Stephen , On Thu, 8 Apr 2010, Stephen Sprunk wrote: > On 07 Apr 2010 16:17, Gary E. Miller wrote: >> On Wed, 7 Apr 2010, Owen DeLong wrote: >> >>> If you are an end-user type organization, the fee is only $100/year >>> for all your resources, IPv4 and IPv6 included. Is that really what >>> you would call significant? >>> >> As always, the devil is in the deetails. >> >> From: https://www.arin.net/fees/fee_schedule.html#waivers >> > > The proper URL for the below quote is > . > >> "The annual fee will be $100 USD until 2013, at which time ARIN's Board >> of Trustees may choose to raise the fee." >> > > Note that the LRSA specifies that the fee increase cannot be more than > $25/yr. > >> Then scroll down to the fees you can expect in 2013. Especially note >> how the small guys get hit much harder per IP. >> > > This is the section at > . > > That section applies only to _allocations_, which are what ISPs get. > The maintenance fee for _assignments_, which is what end users orgs get, > has always been $100/yr. No waiver is necessary, and AFAIK the BoT has > made never made any noises about increasing the assignment maintenance fee. > > And, really, even if the fee for your /48 (X-small category) assignment > maintenance fee went up to $1250/yr to match the current allocation > maintenance fee table, would that really be "significant" in the grand > scheme of things? > S Try that fee while trying to make a living in a depressed econimic region JUST for an ipv4 /24 Assignment . I don't make enough to cover that '.' . Sorry this is getting to be a too frequent line of .... out of eveyones mouth & does not cover the facts for those who don't have the $ resources to break past this line of thinking to be able to forge ahead with plans to expand . Twyl , JimL -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 3237 Holden Road | Give me Linux | | babydr at baby-dragons.com | Fairbanks, AK. 99709 | only on AXP | +------------------------------------------------------------------+ From dwhite at olp.net Thu Apr 8 12:50:26 2010 From: dwhite at olp.net (Dan White) Date: Thu, 8 Apr 2010 12:50:26 -0500 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <20100408171740.GE3358@vacation.karoshi.com.> References: <201004081536.o38FaMKQ025021@aurora.sol.net> <250CFBF9-844D-4057-B769-7B87941AF910@delong.com> <20100408171740.GE3358@vacation.karoshi.com.> Message-ID: <20100408175026.GE4808@dan.olp.net> On 08/04/10?17:17?+0000, bmanning at vacation.karoshi.com wrote: > in the IPv4 space, it was common to have a min allocation size of > a /20 ... or 4,096 addresses ... and yet this amnt of space was > allocated to someone who only needed to address "3 servers"... say > six total out of a pool of four thousand ninty six. Granted, that may have been the case many years ago. However, this was not our experience when we obtained addresses, and the ARIN rules as I understand them would not allow such an allocation today. > Thats a huge amnt of wasted space. If our wise and pragmatic leaders > (drc, jc, et.al.) are correct, then IPv4 will be around for a very > long time. > > What, if any, plan exists to improve the utilization density of the > existant IPv4 pool? I believe your question is based on an outdated assumption. -- Dan White From owen at delong.com Thu Apr 8 12:55:49 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 8 Apr 2010 10:55:49 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <20100408115248.A15214@egps.egps.com> from "N. Yaakov Ziskind" at Apr 08, 2010 11:52:48 AM <201004081600.o38G0bCg026452@aurora.sol.net> <000601cad73d$2cac32a0$860497e0$@org> Message-ID: On Apr 8, 2010, at 10:42 AM, Mr. James W. Laferriere wrote: > Hello Lee , > > On Thu, 8 Apr 2010, Lee Howard wrote: >>> -----Original Message----- >>> From: Joe Greco [mailto:jgreco at ns.sol.net] >>> It seems like you could run an RIR more cheaply by simply handing out >>> the space fairly liberally, which would have the added benefit of >>> encouraging v6 adoption. The lack of a need for onerous contractual >>> clauses as suggested above, combined with less overhead costs, ought >>> to make v6 really cheap. >> >> For "fairly liberally" see: >> For ISPs: https://www.arin.net/policy/nrpm.html#six51 >> You have to be an ISP with a plan to have 200 assignment in 5 years >> Non-ISP: https://www.arin.net/policy/nrpm.html#six58 >> Be not-an-ISP and have a need for addresses (per other policies, >> you get to choose which one). >> >> In another post you asked essentially "why does ARIN charge so much?" >> ARIN doesn't just maintain a notebook of address assignments. There are >> HA servers for Whois, IN-ADDR. and IP6.ARPA, research in things like >> SIDR, DNSsec, other tools-services, and educational outreach on IPv6. >> You suggest that there's much less to argue about in IPv6 policy, but if >> you look at current proposals (https://www.arin.net/policy/proposals/) >> you'll see three that are IPv6-specific, and most of the others cover >> both IPv4 and IPv6. So ARIN will continue to maintain the mailing >> lists, and hold public policy meetings (with remote participation, so >> anyone can participate), and facilitate elections so you can throw the >> bums out if you don't like how we do things. >> >> We don't really know how much IPv6 will cost ARIN. If there were >> no more debate about allocation policies, and nobody else had any interest >> in us (politically or litigiously), and technology were fairly static, then >> we >> might just do periodic tech refreshes and be fine. I imagine all of those >> things will continue for a while, though, and ARIN will need to be >> financially solvent through the transition. >> >> >> Your ARIN fee does not cover me posting here. That's gratis, and >> worth it. >> >> Lee > Thank you for posting those URL's I find a completely different interpretation to the prose there . > > > 6.5.8. Direct assignments from ARIN to end-user organizations > 6.5.8.1. Criteria > > To qualify for a direct assignment, an organization must: > > 1. not be an IPv6 LIR; and > 2. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect, or "demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by any current ARIN RSA", or be a qualifying Community Network as defined in Section 2.8, with assignment criteria defined in section 6.5.9. > > > Note the ""'d section above . I as a Legacy holder of netname baby-dragons HAVE to have a Signed RSA with Airn or I am NOT , by definition , Qualified . > You must meet 1 (not be an IPv6 LIR) You must meet one of the criteria in 2. Any ONE of: + Qualify for an IPv4 assignment or allocation under current ARIN policy OR "demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must..." OR be a qualifying Community Network as defined in section 2.8... > I find the present lRSA an indecent attempt to undermine the present Legacy ipv4 holders view of the rights presented them at the time of their Assignments or Allocations . If I could find my OLD Ultrix Tarball or Dump tapes from that era , and they are still readable , I might just be able to present the conversations I had at that time with InterNIC while acquiring that Legacy Space . > Might someone else have a Document or some other Recorded conversation ? What, exactly do you find so onerous in the LRSA? Would it be equally onerous if ARIN simply stopped providing RDNS for you? Owen > Twyl , JimL > > ps: Back to haunting mode . > -- > +------------------------------------------------------------------+ > | James W. Laferriere | System Techniques | Give me VMS | > | Network&System Engineer | 3237 Holden Road | Give me Linux | > | babydr at baby-dragons.com | Fairbanks, AK. 99709 | only on AXP | > +------------------------------------------------------------------+ From aaron at wholesaleinternet.net Thu Apr 8 13:00:10 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Thu, 8 Apr 2010 13:00:10 -0500 Subject: Peering Exchange Configurations In-Reply-To: <9A0CBD30-7766-4773-9B40-20A28F4415EA@gmail.com> References: <9A0CBD30-7766-4773-9B40-20A28F4415EA@gmail.com> Message-ID: <01f101cad745$54c98a50$fe5c9ef0$@net> I operate the exchange point in the Kansas City area so I'll answer your questions based on how we do it. 1) Is a private AS typically used for the exchange side of the session? No. Each participant uses their own ASN. 2) Are RFC1918 IPs typically used for the p2p links into the exchange? No. Exchanges typically have their own IPs assigned by their RIR and pass them out to the members for connections to the exchange. 3) Do peering exchanges typically remove their AS from the path advertised to exchange participants? There is no peering directly with the exchange in a private link. In the case of peering with a route server on the exchange then it is considered best practices to do so. 3a) If no: Do participants typically preference exchange-learned routes over other sources? Yes. As far as I know all our members set routes learned through the exchange fabric higher than anything else. That's kind of the point as exchange traffic is free so you always want to use it first. 4) Do exchanges typically support the following address families? IPv4 Multicast IPv6 Unicast IPv6 Multicast No Yes No In exchanges where a route server is employed: 4) Do participants have a p2p link into a simple routing environment then multi-hop to a route server? No. The route server is typically accessed like any other peer on the fabric. 5) I see that Bird, OpenBDGd, and Quagga are all options for route server software. Does one of those packages stand out as the clear current choice for production peering exchanges? We use Quagga. It's what we we're most familiar with and we haven't had any issues. >I very much appreciate any responses. No Problem. Feel free to stop by and check out our fabric for yourself. Aaron From bmanning at vacation.karoshi.com Thu Apr 8 13:00:01 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 8 Apr 2010 18:00:01 +0000 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <20100408175026.GE4808@dan.olp.net> References: <201004081536.o38FaMKQ025021@aurora.sol.net> <250CFBF9-844D-4057-B769-7B87941AF910@delong.com> <20100408171740.GE3358@vacation.karoshi.com.> <20100408175026.GE4808@dan.olp.net> Message-ID: <20100408180001.GH3358@vacation.karoshi.com.> On Thu, Apr 08, 2010 at 12:50:26PM -0500, Dan White wrote: > On 08/04/10 17:17 +0000, bmanning at vacation.karoshi.com wrote: > > in the IPv4 space, it was common to have a min allocation size of > > a /20 ... or 4,096 addresses ... and yet this amnt of space was > > allocated to someone who only needed to address "3 servers"... say > > six total out of a pool of four thousand ninty six. > > Granted, that may have been the case many years ago. > > However, this was not our experience when we obtained addresses, and the > ARIN rules as I understand them would not allow such an allocation today. i picked a fairly recent example - the min allocation size has fluctuated over time. still it is not the case that most folks will get -exactly- what they need - they will - in nearly every case - get more address space than they need - due to the min allocation rules > > Thats a huge amnt of wasted space. If our wise and pragmatic leaders > > (drc, jc, et.al.) are correct, then IPv4 will be around for a very > > long time. > > > > What, if any, plan exists to improve the utilization density of the > > existant IPv4 pool? > > I believe your question is based on an outdated assumption. and that outdated assumption is? > Dan White --bill From robt at cymru.com Thu Apr 8 13:04:00 2010 From: robt at cymru.com (Rob Thomas) Date: Thu, 08 Apr 2010 13:04:00 -0500 Subject: AS23724 oops? was Re: China prefix hijack In-Reply-To: <001f01cad740$ccf0c390$4401a8c0@jgbpc> References: <001f01cad740$ccf0c390$4401a8c0@jgbpc> Message-ID: <4BBE1A90.9020200@cymru.com> Hi, team. Joe wrote: > Just wondering if this was a "Fat fingered" mistake or intentional... I'm thinking "oops." Looking only for prefixes with the aspath " 4134 23724 23724 ," and only on 2010-04-08 UTC, we see 15210 prefixes announced. Of those, 9598 are allocated to CN, 11017 are allocated by APNIC, and 4193 are neither (LACNIC, AFRINIC, RIPE, ARIN). The prefixes are almost sequential as well. There are some few gaps. It ranges beginning with a prefix in 8/8 and ending with a prefix in 222/8. There are a wide range of networks of every sort. Nations involved, according to RIR records, include: Prefixes Country Code 9444 CN 2192 US 758 AU 448 CO 186 RU 139 ID 131 TH 122 JP 103 KR 101 EC 96 BR 91 IN 84 AR [ ... ] So I'm leaning towards "big oops." I'll see if we can find someone at AS23724 to ask, and perhaps assist if needed. Thanks, Rob. -- Rob Thomas Team Cymru https://www.team-cymru.org/ "Say little and do much." M Avot 1:15 From kevin at steadfast.net Thu Apr 8 13:04:04 2010 From: kevin at steadfast.net (Kevin Stange) Date: Thu, 08 Apr 2010 13:04:04 -0500 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004081600.o38G0bCg026452@aurora.sol.net> References: <201004081600.o38G0bCg026452@aurora.sol.net> Message-ID: <4BBE1A94.8020407@steadfast.net> On 04/08/2010 11:00 AM, Joe Greco wrote: >> Is this just an argument about the money? Or, are there other issues >> ("you agree that we can revoke your allocation at any time, for any >> reason, as we see fit")? > > I'd be curious to know what the justification for such a policy would > be under v6. Even if space were obtained under false pretenses, the > cost of reclaiming it (in terms of lawsuits, etc) is essentially being > shoveled onto the shoulders of others who have received allocations. As I understand it ARIN does not like to reclaim space forcibly for this very reason. It's costly and they'd much rather resolve matters amicably and allow people to keep their resources. It's true that anyone that does accept terms to their IP allocations opens the possibility up, but recall that ARIN has a open and public policy making process. If they are going to change something and begin demanding IPs back from certain holders, if you are attentive to the process you should have plenty of opportunity to a) find out, and b) make your displeasure very clear. If you are a member, paying your dues, you also have the right to vote for those people who make the final decisions. But more to the point, how often do you hear that ARIN has decided to come to any IPv4 holder and just take back their allocation without cause? > > It seems like you could run an RIR more cheaply by simply handing out > the space fairly liberally, which would have the added benefit of > encouraging v6 adoption. The lack of a need for onerous contractual > clauses as suggested above, combined with less overhead costs, ought > to make v6 really cheap. This is the current policy, even with respect to IPv4 to a large degree, at least for ARIN. As long as you can establish a fairly evident need for portable address space and can give them a vague plan for allocating it over time, they'll give you want you want, as long as you can pay the appropriate (and I feel quite reasonable) annual fees. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From zeusdadog at gmail.com Thu Apr 8 13:09:49 2010 From: zeusdadog at gmail.com (Jay Nakamura) Date: Thu, 8 Apr 2010 14:09:49 -0400 Subject: Metering power in data center Message-ID: I am looking for suggestions on devices that can monitor(A)/meter(kw/h) power usage in a data center. Getting a metered PDU everywhere seems a little expensive and cumbersome. Are there devices you can wire into breaker box to meter each AC circuit? Thanks in advance for any suggestions. -Jay From owen at delong.com Thu Apr 8 13:08:30 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 8 Apr 2010 11:08:30 -0700 Subject: Peering Exchange Configurations In-Reply-To: <01f101cad745$54c98a50$fe5c9ef0$@net> References: <9A0CBD30-7766-4773-9B40-20A28F4415EA@gmail.com> <01f101cad745$54c98a50$fe5c9ef0$@net> Message-ID: <4C54F0C3-6D41-4EF2-BDD8-4E6E92470B9F@delong.com> > > 3a) If no: Do participants typically preference exchange-learned > routes over other sources? > > Yes. As far as I know all our members set routes learned through the > exchange fabric higher than anything else. That's kind of the point as > exchange traffic is free so you always want to use it first. > Actually, the order of preference is usually: 1. Private Interconnects (direct private peering) 2. Non-metered paid peering/transit 3. Exchange Points 4. Metered paid peering/transit Owen From alex at corp.nac.net Thu Apr 8 13:13:37 2010 From: alex at corp.nac.net (Alex Rubenstein) Date: Thu, 8 Apr 2010 14:13:37 -0400 Subject: Metering power in data center In-Reply-To: References: Message-ID: We use products from Veris. If you could be more specific as to what you want to meter (and where, and types / brands of panels), I could point you further. > I am looking for suggestions on devices that can > monitor(A)/meter(kw/h) power usage in a data center. Getting a > metered PDU everywhere seems a little expensive and cumbersome. > > Are there devices you can wire into breaker box to meter each AC > circuit? > > Thanks in advance for any suggestions. > > -Jay From stephen at sprunk.org Thu Apr 8 13:19:32 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 08 Apr 2010 13:19:32 -0500 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <20100408115248.A15214@egps.egps.com> from "N. Yaakov Ziskind" at Apr 08, 2010 11:52:48 AM <201004081600.o38G0bCg026452@aurora.sol.net> <000601cad73d$2cac32a0$860497e0$@org> Message-ID: <4BBE1E34.5070007@sprunk.org> On 08 Apr 2010 12:42, Mr. James W. Laferriere wrote: > Hello Lee , > > On Thu, 8 Apr 2010, Lee Howard wrote: >>> -----Original Message----- >>> From: Joe Greco [mailto:jgreco at ns.sol.net] >>> It seems like you could run an RIR more cheaply by simply handing >>> out the space fairly liberally, which would have the added benefit >>> of encouraging v6 adoption. The lack of a need for onerous >>> contractual clauses as suggested above, combined with less overhead >>> costs, ought to make v6 really cheap. >> >> For "fairly liberally" see: >> For ISPs: https://www.arin.net/policy/nrpm.html#six51 >> You have to be an ISP with a plan to have 200 assignment in 5 years >> Non-ISP: https://www.arin.net/policy/nrpm.html#six58 >> Be not-an-ISP and have a need for addresses (per other policies, >> you get to choose which one). > > Thank you for posting those URL's I find a completely different > interpretation to the prose there . > > > 6.5.8. Direct assignments from ARIN to end-user organizations > 6.5.8.1. Criteria > > To qualify for a direct assignment, an organization must: > > 1. not be an IPv6 LIR; and > 2. qualify for an IPv4 assignment or allocation from ARIN under the > IPv4 policy currently in effect, or "demonstrate efficient utilization > of all direct IPv4 assignments and allocations, each of which must be > covered by any current ARIN RSA", or be a qualifying Community Network > as defined in Section 2.8, with assignment criteria defined in section > 6.5.9. > > > Note the ""'d section above . I as a Legacy holder of netname > baby-dragons HAVE to have a Signed RSA with Airn or I am NOT , by > definition , Qualified . The section you quoted is the second of the three-part "or" statement. Unfortunately, recent policy changes have made a mess of that text, so I'll offer an edited version that has the same meaning but is much clearer: "6.5.8.1. Criteria To qualify for a direct assignment, an organization must: 1. not be an IPv6 LIR; and 2. one (or more) of the following: 1. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect, or 2. demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by any current ARIN RSA, or 3. be a qualifying Community Network as defined in Section 2.8, with assignment criteria defined in section 6.5.9." IOW, even if you don't qualify under (b)(2) because you haven't signed an LRSA for your legacy space, you can still qualify under (b)(1) or (b)(3). Now, let's look at how one qualifies for (b)(1): "4.3.2. Minimum assignment 4.3.2.1 Single Connection The minimum block of IP address space assigned by ARIN to end-users is a /20. If assignments smaller than /20 are needed, end-users should contact their upstream provider. 4.3.2.2 Multihomed Connection For end-users who demonstrate an intent to announce the requested space in a multihomed fashion, the minimum block of IP address space assigned is a /22. If assignments smaller than a /22 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose. 4.3.3. Utilization rate Utilization rate of address space is a key factor in justifying a new assignment of IP address space. Requesters must show exactly how previous address assignments have been utilized and must provide appropriate details to verify their one-year growth projection. The basic criteria that must be met are: * A 25% immediate utilization rate, and * A 50% utilization rate within one year. A greater utilization rate may be required based on individual network requirements. Please refer to RFC 2050 for more information on utilization guidelines." So, if you are multi-homed, you would need a 25-50% utilization of a /22, or 256-512 hosts; if you are single-homed, you would need a 25-50% utilization of a /20, or 1024-2048 hosts. That is an extremely low bar for any org to automatically qualify for a IPv6 /48 (and a slot in every DFZ router). > I find the present lRSA an indecent attempt to undermine the present > Legacy ipv4 holders view of the rights presented them at the time of > their Assignments or Allocations . If I could find my OLD Ultrix > Tarball or Dump tapes from that era , and they are still readable , > I might just be able to present the conversations I had at that time > with InterNIC while acquiring that Legacy Space . > Might someone else have a Document or some other Recorded > conversation ? If you have any documents or recordings that show ARIN has _any_ existing contractual obligations to you regarding your legacy space, either directly or as legal successor of some other organization, please present it. I'm sure ARIN's legal counsel would be quite interested, but AFAIK no legacy holder has _ever_ been able to do so. Until such time as someone proves otherwise, we must assume that ARIN has _no_ obligations to you, and they could (if the community so desired) delete your unpaid, uncontracted registration from their database and assign/allocate those numbers to some other party, and there's not a damn thing you could do about it other than waste lots of money on a lawsuit you'd undoubtedly lose. Signing an LRSA protects you against that possibility--forever--at minimal cost. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From kwallace at pcconnection.com Thu Apr 8 13:21:15 2010 From: kwallace at pcconnection.com (Wallace Keith) Date: Thu, 8 Apr 2010 14:21:15 -0400 Subject: Metering power in data center In-Reply-To: References: Message-ID: <0E8773C725A1674E9F7B35EABB5EEEB108443DF5@MKA134.pcc.int> -----Original Message----- From: Jay Nakamura [mailto:zeusdadog at gmail.com] Sent: Thursday, April 08, 2010 2:10 PM To: NANOG Subject: Metering power in data center I am looking for suggestions on devices that can monitor(A)/meter(kw/h) power usage in a data center. Getting a metered PDU everywhere seems a little expensive and cumbersome. Are there devices you can wire into breaker box to meter each AC circuit? Thanks in advance for any suggestions. -Jay We have a few of these running: http://www.emon.com/products_webmon.html -Keith From bill at herrin.us Thu Apr 8 13:22:29 2010 From: bill at herrin.us (William Herrin) Date: Thu, 8 Apr 2010 14:22:29 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <4BBE118C.6070602@sprunk.org> Message-ID: On Thu, Apr 8, 2010 at 1:49 PM, Mr. James W. Laferriere wrote: >> And, really, even if the fee for your /48 (X-small category) assignment >> maintenance fee went up to $1250/yr to match the current allocation >> maintenance fee table, would that really be "significant" in the grand >> scheme of things? >> S > > ? ? ? ?Try that fee while trying to make a living in a depressed econimic > region JUST for an ipv4 /24 Assignment . ?I don't make enough to cover that Jim, Not much sympathy for folks crying the blues about the cost of an address assignment that they're going to turn around and announce into the DFZ... http://bill.herrin.us/network/bgpcost.html On Thu, Apr 8, 2010 at 1:17 PM, wrote: > What, if any, plan exists to improve the utilization density of the > existant IPv4 pool? Bill, ARIN has implemented a structure to facilitate IPv4 address transfers should an open market come to exist. Between an address market and the ever more creative use of NAT, it should be possible for IPv4 addressing to continue after free pool depletion as a zero-sum game. Exactly how long is a matter of debate with speculation ranging from months to decades. On Thu, Apr 8, 2010 at 1:55 PM, Owen DeLong wrote: > What, exactly do you find so onerous in the LRSA? Owen, ARIN's unilateral right under the LRSA to reclaim my addresses in the event of a dispute bugs me a tad, as does similar verbiage sprinkled throughout. > Would it be equally onerous if ARIN simply stopped providing RDNS for you? Probably not. SMTP is the only major service any more that cares. But that's immaterial; ending RDNS for legacy registrants has been an empty threat from the day the notion was first hatched. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From patrick at ianai.net Thu Apr 8 13:23:58 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 8 Apr 2010 14:23:58 -0400 Subject: Peering Exchange Configurations In-Reply-To: <4C54F0C3-6D41-4EF2-BDD8-4E6E92470B9F@delong.com> References: <9A0CBD30-7766-4773-9B40-20A28F4415EA@gmail.com> <01f101cad745$54c98a50$fe5c9ef0$@net> <4C54F0C3-6D41-4EF2-BDD8-4E6E92470B9F@delong.com> Message-ID: On Apr 8, 2010, at 2:08 PM, Owen DeLong wrote: >> 3a) If no: Do participants typically preference exchange-learned >> routes over other sources? >> >> Yes. As far as I know all our members set routes learned through the >> exchange fabric higher than anything else. That's kind of the point as >> exchange traffic is free so you always want to use it first. >> > Actually, the order of preference is usually: Where 'usually' here is rather nebulous. I am not trying to say Owen is wrong, just don't think the way any network uses interconnectivity is somehow standard. Every network is different, and even similar links in the same network are different. IXPs are standard ('usually' :), networks are not. -- TTFN, patrick > 1. Private Interconnects (direct private peering) > 2. Non-metered paid peering/transit > 3. Exchange Points > 4. Metered paid peering/transit > > Owen > From jgreco at ns.sol.net Thu Apr 8 13:26:51 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 8 Apr 2010 13:26:51 -0500 (CDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <000601cad73d$2cac32a0$860497e0$@org> from "Lee Howard" at Apr 08, 2010 01:01:46 PM Message-ID: <201004081826.o38IQpfJ038982@aurora.sol.net> > > > -----Original Message----- > > From: Joe Greco [mailto:jgreco at ns.sol.net] > > It seems like you could run an RIR more cheaply by simply handing out > > the space fairly liberally, which would have the added benefit of > > encouraging v6 adoption. The lack of a need for onerous contractual > > clauses as suggested above, combined with less overhead costs, ought > > to make v6 really cheap. > > For "fairly liberally" see: > For ISPs: https://www.arin.net/policy/nrpm.html#six51 > You have to be an ISP with a plan to have 200 assignment in 5 years > Non-ISP: https://www.arin.net/policy/nrpm.html#six58 > Be not-an-ISP and have a need for addresses (per other policies, > you get to choose which one). > > In another post you asked essentially "why does ARIN charge so much?" > ARIN doesn't just maintain a notebook of address assignments. There are > HA servers for Whois, Yeah, real expensive... > IN-ADDR. and IP6.ARPA, Ditto... > research in things like > SIDR, DNSsec, other tools-services, and educational outreach on IPv6. None of which a RIR really /needs/ to do, of course. > You suggest that there's much less to argue about in IPv6 policy, No, I argue there *could* be much less to argue about in IPv6 policy. > but if > you look at current proposals (https://www.arin.net/policy/proposals/) > you'll see three that are IPv6-specific, and most of the others cover > both IPv4 and IPv6. So ARIN will continue to maintain the mailing > lists, and hold public policy meetings (with remote participation, so > anyone can participate), and facilitate elections so you can throw the > bums out if you don't like how we do things. None of which really addresses the point I made; that's the sound of a bureaucracy perpetuating itself. > We don't really know how much IPv6 will cost ARIN. If there were > no more debate about allocation policies, and nobody else had any interest > in us (politically or litigiously), and technology were fairly static, then > we > might just do periodic tech refreshes and be fine. I imagine all of those > things will continue for a while, though, and ARIN will need to be > financially solvent through the transition. The point I was making is that after the "transition", the justification for ARIN is one of maintaining the status quo and perpetuating itself. My question was, what purpose is served by that? With IPv6 designed the way it is, is there a realistic chance of running out of IPv6 even if some questionable delegations are made? What's the purpose of having the complex legal agreements? Handing out numbers without much fuss worked okay in the early days of IPv4, before it became clear that there would be eventual depletion. IPv6 was designed to avoid the depletion scenario, and with that in mind, is there a good reason that a much smaller RIRv6 model wouldn't work? ... 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 joe at via.net Thu Apr 8 13:29:25 2010 From: joe at via.net (joe mcguckin) Date: Thu, 8 Apr 2010 11:29:25 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <20100408175026.GE4808@dan.olp.net> References: <201004081536.o38FaMKQ025021@aurora.sol.net> <250CFBF9-844D-4057-B769-7B87941AF910@delong.com> <20100408171740.GE3358@vacation.karoshi.com.> <20100408175026.GE4808@dan.olp.net> Message-ID: <612B4477-10B0-4B95-8B03-02ACE59DDA76@via.net> This is a pretty boring topic. It's been argued many times over. I think the more interesting discussion is: - Where is ARIN and the RIR's headed? - What will ARIN look like 10 years from now? Mission creep seems to be pervasive in all organizations. ICANN with a headcount of over 100 and a budget exceeding 60MM fulfills a core function that used to be performed by what? 2.5 full-time persons? Is this the fate that awaits ARIN? The main justification for ARIN's size, budget - its existence, even - is that ARIN shepherds a limited set of resources. I find it interesting then, that a number of the pro-IPV6 folk seem to be saying just the opposite when it comes to IPV6. If they're not saying it outright, then the subtext of their argument is that IPV6 is so large, we'll never exhaust it. (Go ahead and give that customer with one computer a chunk of address space that is 2^32 larger than the entire existing IPV4 address space - we'll never miss it.) Well, if that's true; if IPV6 means that address space is no longer a scarce - limited, even - resource, why would there even be an ARIN? Why not collapse all the RIR's into a website that functions more as a title registry than as a justification/vetting organization? After all, IPV6 space is inexhaustible - right. So what if some idiot wants to grab 50 allocations... We'll never miss it. Joe Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax PS: If we want to keep the size of the routing tables down, why isn't ARIN charging MORE for end-user assignments. A lot more, like the same or even more than what allocations cost. From ipv3.com at gmail.com Thu Apr 8 13:30:52 2010 From: ipv3.com at gmail.com (IPv3.com) Date: Thu, 8 Apr 2010 13:30:52 -0500 Subject: Is NANOG == ARIN ? or North America in Scope ? Message-ID: Is NANOG == ARIN ? or North America in Scope ? ============================================================== What do the following /8 ?"Owners"? pay for their CyberLand ? http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt 004/8 Level 3 Communications, Inc. 1992-12 LEGACY 008/8 Level 3 Communications, Inc. 1992-12 LEGACY 032/8 AT&T Global Network Services 1994-06 LEGACY 035/8 MERIT Computer Network 1994-04 LEGACY =============================================================== In the recent Annual Pass Over of /8 Audits it does not appear that /8 Utilization warrants ALL to migrate to 34-bit IPv4++ Space (1+32+1) Also, in some cases, the companies may no longer exist? 016/8 Digital Equipment Corporation 1994-11 LEGACY 045/8 Interop Show Network 1995-01 LEGACY 044/8 Amateur Radio Digital Communications 1992-07 LEGACY ================================================================ BTW, If ARIN has a $10,000,000 HR Budget and 10 people that is an average of $1,000,000 per person. Is that Cost Recovery ? http://bit.ly/17QKAR http://bit.ly/ametyG ================================================================ Why is IN-ADDR.ARPA any different from a $10 .COM Registration ? From bill at herrin.us Thu Apr 8 13:33:49 2010 From: bill at herrin.us (William Herrin) Date: Thu, 8 Apr 2010 14:33:49 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004081826.o38IQpfJ038982@aurora.sol.net> References: <000601cad73d$2cac32a0$860497e0$@org> <201004081826.o38IQpfJ038982@aurora.sol.net> Message-ID: On Thu, Apr 8, 2010 at 2:26 PM, Joe Greco wrote: > With IPv6 designed the > way it is, is there a realistic chance of running out of IPv6 even if > some questionable delegations are made? Joe, You're aware that RIPE has already made some /19 and /20 IPv6 allocations? Yes, with suitably questionable delegations, it is possible to run out of IPv6 quickly. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From kevin at steadfast.net Thu Apr 8 13:34:55 2010 From: kevin at steadfast.net (Kevin Stange) Date: Thu, 08 Apr 2010 13:34:55 -0500 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004081536.o38FaMKQ025021@aurora.sol.net> References: <201004081536.o38FaMKQ025021@aurora.sol.net> Message-ID: <4BBE21CF.2040504@steadfast.net> On 04/08/2010 10:36 AM, Joe Greco wrote: >> Legacy holders have been holding parts (possibly more than they would >> be able to justify from an RIR) of a finite global shared resource >> without sharing in the costs associated, and it's unfair to _them_ >> that they're not _entitled_ to do the same in the IPv6 space? > > When ARIN's costs are largely legal costs to go "enforcing" v4 policy > and a bureaucracy to go through all the policy and paperwork? The > finiteness of the resource is irrelevant; it does not cost ARIN any > more or less to do its task in the v4 arena. There is a cost to the > global Internet for v4 depletion, yes, but ARIN is not paying any of > us for forwarding table entries or forced use of NAT due to lack of > space, so to imply that ARIN's expenses are in any way related to the > finiteness of the resource is a laughable argument (you're 8 days > late). > > It would be better to dismantle the current ARIN v6 framework and do > a separate v6 RIR. In v6, there's an extremely limited need to go > battling things in court, one could reduce expenses simply by giving > the benefit of the doubt and avoiding stuff like Kremen entirely. In > the old days, nearly anyone could request -and receive- a Class C or > even Class B with very little more than some handwaving. The main > reason to tighten that up was depletion; with IPv6, it isn't clear > that the allocation function needs to be any more complex than what > used to exist, especially for organizations already holding v4 > resources. > > So, my challenges to you: > > 1) Justify why we need a heavy bureaucracy such as ARIN for IPv6 > numbering resources, > > 2) Tell me why something like the old pre-depletion pre-ARIN model > of InterNIC and just handing out prefixes with substantially less > paper-pushing wouldn't result in a cheaper-to-run RIR. Just because the benefit of being cautious isn't clear doesn't mean we should simply throw caution to the wind entirely and go back to the "old ways." It seems clear to many now that a lot of the legacy allocations, /8's in particular were issued in a way that has left IPv4 inefficiently allocated and with lack of any agreements by the resource holders to have any responsibility to do anything about it. If we just eliminated the RIRs and agreements governing terms of access to v6 allocations, IF later, we find a problem with the process and start to run out of space, we end up in the same situation. Suddenly we have to form these organizations again, and institute new allocation policies for new allocations, but again lack any recourse for all those people that "greedily" ate up as much space as they could. I think there's a continued need to keep an organization in charge of accounting for the space to whom we as resource holders are accountable and whom is also accountable to us. Later on, when we realize we've gone wrong somewhere (and it will happen) and need to make changes to policy, there is a process by which we can do it where all the parties involved already have an established relationship. I am not going to argue your second request. It'd certainly be cheaper to do things your way. I just think it's a terrible idea. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From aaron at wholesaleinternet.net Thu Apr 8 13:35:24 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Thu, 8 Apr 2010 13:35:24 -0500 Subject: Peering Exchange Configurations In-Reply-To: References: <9A0CBD30-7766-4773-9B40-20A28F4415EA@gmail.com> <01f101cad745$54c98a50$fe5c9ef0$@net> <4C54F0C3-6D41-4EF2-BDD8-4E6E92470B9F@delong.com> Message-ID: <020b01cad74a$40d17120$c2745360$@net> -----Original Message----- On Apr 8, 2010, at 2:08 PM, Owen DeLong wrote: >> 3a) If no: Do participants typically preference exchange-learned >> routes over other sources? >> >> Yes. As far as I know all our members set routes learned through the >> exchange fabric higher than anything else. That's kind of the point as >> exchange traffic is free so you always want to use it first. >> > Actually, the order of preference is usually: Where 'usually' here is rather nebulous. I am not trying to say Owen is wrong, just don't think the way any network uses interconnectivity is somehow standard. Every network is different, and even similar links in the same network are different. IXPs are standard ('usually' :), networks are not. -- TTFN, patrick > 1. Private Interconnects (direct private peering) > 2. Non-metered paid peering/transit > 3. Exchange Points > 4. Metered paid peering/transit > > Owen > ----------------------------------------------------------- My answers were based on what I know about members of our exchange. In our market there is little to no private peering. Everyone connects through the exchange so that's their only source of peering. Although we don't require our members to use the route server, all of them do. From bmanning at vacation.karoshi.com Thu Apr 8 13:37:57 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 8 Apr 2010 18:37:57 +0000 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <4BBE118C.6070602@sprunk.org> Message-ID: <20100408183757.GA9681@vacation.karoshi.com.> On Thu, Apr 08, 2010 at 02:22:29PM -0400, William Herrin wrote: > On Thu, Apr 8, 2010 at 1:49 PM, Mr. James W. Laferriere > wrote: > >> And, really, even if the fee for your /48 (X-small category) assignment > >> maintenance fee went up to $1250/yr to match the current allocation > >> maintenance fee table, would that really be "significant" in the grand > >> scheme of things? > >> S > > > > Try that fee while trying to make a living in a depressed econimic > > region JUST for an ipv4 /24 Assignment . I don't make enough to cover that > > Jim, > > Not much sympathy for folks crying the blues about the cost of an > address assignment that they're going to turn around and announce into > the DFZ... assuming facts not in evidence there ... but ok. > On Thu, Apr 8, 2010 at 1:17 PM, wrote: > > What, if any, plan exists to improve the utilization density of the > > existant IPv4 pool? > > Bill, > > ARIN has implemented a structure to facilitate IPv4 address transfers > should an open market come to exist. Between an address market and the > ever more creative use of NAT, it should be possible for IPv4 > addressing to continue after free pool depletion as a zero-sum game. > Exactly how long is a matter of debate with speculation ranging from > months to decades. cool. I've used the transfer policy with limited success. I guess the interesting thing in your statement (and I suspect a trip to the ARIN NRPM is in order) is "should an open market come into existence" ... how do you see that happening? but more to my point. If I'm using a single /24 out of my /20 (using an antiquated example) - would there be: ) interest in the other 15 /24s ) how would that interest be expressed (so I would know about it) ) complaints from the folks running w/o default about the new prefixes on offer? ** ** remembering that as far as the routing system is concerned, a /32 is a /32 > > > On Thu, Apr 8, 2010 at 1:55 PM, Owen DeLong wrote: > > What, exactly do you find so onerous in the LRSA? > > Owen, > > ARIN's unilateral right under the LRSA to reclaim my addresses in the > event of a dispute bugs me a tad, as does similar verbiage sprinkled > throughout. > > > > Would it be equally onerous if ARIN simply stopped providing RDNS for you? > > Probably not. SMTP is the only major service any more that cares. But > that's immaterial; ending RDNS for legacy registrants has been an > empty threat from the day the notion was first hatched. > > 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 Thu Apr 8 13:42:32 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 8 Apr 2010 18:42:32 +0000 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <612B4477-10B0-4B95-8B03-02ACE59DDA76@via.net> References: <201004081536.o38FaMKQ025021@aurora.sol.net> <250CFBF9-844D-4057-B769-7B87941AF910@delong.com> <20100408171740.GE3358@vacation.karoshi.com.> <20100408175026.GE4808@dan.olp.net> <612B4477-10B0-4B95-8B03-02ACE59DDA76@via.net> Message-ID: <20100408184232.GB9681@vacation.karoshi.com.> On Thu, Apr 08, 2010 at 11:29:25AM -0700, joe mcguckin wrote: > This is a pretty boring topic. It's been argued many times over. > > I think the more interesting discussion is: > - Where is ARIN and the RIR's headed? > - What will ARIN look like 10 years from now? yuppers. this topic -could- engender those discussions > Mission creep seems to be pervasive in all organizations. ICANN with a headcount of over 100 and a budget exceeding 60MM fulfills a core function > that used to be performed by what? 2.5 full-time persons? the IANA budget was just north of 750K/yr and btwn 2 and 4.5 persons. the ICANN bduget, when new TLDs are approved in the next 18 months - is expected to be somewhat north of 500MM/year > Is this the fate that awaits ARIN? nope - well i hope not. > After all, IPV6 space is inexhaustible - right. So what if some idiot wants to grab 50 allocations... its not. > If we want to keep the size of the routing tables down, why isn't ARIN charging MORE for end-user assignments. A lot more, like the same or even more > than what allocations cost. 'cause ARIN isn't the routing police - yet. wait for widespread adoption of rPKI... :) --bill From ipv3.com at gmail.com Thu Apr 8 13:46:57 2010 From: ipv3.com at gmail.com (IPv3.com) Date: Thu, 8 Apr 2010 13:46:57 -0500 Subject: Using Semi-FREE 64-bit Allocations with IPv6 Message-ID: Using Semi-FREE 64-bit Allocations with IPv6 Why would anyone be paying for IPv6 Address Space ? With the 64-bit Address Plan huge allocations are ?$10? per year. 12+18+30+4 maps to LL+LLL+LLLLL+4 Use the 64-symbol Alphabet: 0-9A-Za-z-. for 6-bits per L Example: LL=US LLL=COM LLLLL=ICANN US_COM_ICANN_X is a unique 64-bit Allocation FREE with the .COM domain 2002:[IPv4]:0000:LL_LLL_LLLLL_X From dhetzel at gmail.com Thu Apr 8 13:47:04 2010 From: dhetzel at gmail.com (Dorn Hetzel) Date: Thu, 8 Apr 2010 14:47:04 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4BBE21CF.2040504@steadfast.net> References: <201004081536.o38FaMKQ025021@aurora.sol.net> <4BBE21CF.2040504@steadfast.net> Message-ID: If there was an automatic website that just handed out up to a /40 on demand, and charged a one-time fee of $100, I don't think the space would ever be exhausted, there isn't enough money. On Thu, Apr 8, 2010 at 2:34 PM, Kevin Stange wrote: > On 04/08/2010 10:36 AM, Joe Greco wrote: > >> Legacy holders have been holding parts (possibly more than they would > >> be able to justify from an RIR) of a finite global shared resource > >> without sharing in the costs associated, and it's unfair to _them_ > >> that they're not _entitled_ to do the same in the IPv6 space? > > > > When ARIN's costs are largely legal costs to go "enforcing" v4 policy > > and a bureaucracy to go through all the policy and paperwork? The > > finiteness of the resource is irrelevant; it does not cost ARIN any > > more or less to do its task in the v4 arena. There is a cost to the > > global Internet for v4 depletion, yes, but ARIN is not paying any of > > us for forwarding table entries or forced use of NAT due to lack of > > space, so to imply that ARIN's expenses are in any way related to the > > finiteness of the resource is a laughable argument (you're 8 days > > late). > > > > It would be better to dismantle the current ARIN v6 framework and do > > a separate v6 RIR. In v6, there's an extremely limited need to go > > battling things in court, one could reduce expenses simply by giving > > the benefit of the doubt and avoiding stuff like Kremen entirely. In > > the old days, nearly anyone could request -and receive- a Class C or > > even Class B with very little more than some handwaving. The main > > reason to tighten that up was depletion; with IPv6, it isn't clear > > that the allocation function needs to be any more complex than what > > used to exist, especially for organizations already holding v4 > > resources. > > > > So, my challenges to you: > > > > 1) Justify why we need a heavy bureaucracy such as ARIN for IPv6 > > numbering resources, > > > > 2) Tell me why something like the old pre-depletion pre-ARIN model > > of InterNIC and just handing out prefixes with substantially less > > paper-pushing wouldn't result in a cheaper-to-run RIR. > > Just because the benefit of being cautious isn't clear doesn't mean we > should simply throw caution to the wind entirely and go back to the "old > ways." It seems clear to many now that a lot of the legacy allocations, > /8's in particular were issued in a way that has left IPv4 inefficiently > allocated and with lack of any agreements by the resource holders to > have any responsibility to do anything about it. > > If we just eliminated the RIRs and agreements governing terms of access > to v6 allocations, IF later, we find a problem with the process and > start to run out of space, we end up in the same situation. Suddenly we > have to form these organizations again, and institute new allocation > policies for new allocations, but again lack any recourse for all those > people that "greedily" ate up as much space as they could. > > I think there's a continued need to keep an organization in charge of > accounting for the space to whom we as resource holders are accountable > and whom is also accountable to us. Later on, when we realize we've > gone wrong somewhere (and it will happen) and need to make changes to > policy, there is a process by which we can do it where all the parties > involved already have an established relationship. > > I am not going to argue your second request. It'd certainly be cheaper > to do things your way. I just think it's a terrible idea. > > -- > Kevin Stange > Chief Technology Officer > Steadfast Networks > http://steadfast.net > Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 > > From jeroen at unfix.org Thu Apr 8 13:47:40 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 08 Apr 2010 20:47:40 +0200 Subject: "Running out of IPv6" (Re: ARIN IP6 policy for those with legacy IP4 Space) In-Reply-To: References: <000601cad73d$2cac32a0$860497e0$@org> <201004081826.o38IQpfJ038982@aurora.sol.net> Message-ID: <4BBE24CC.2050803@unfix.org> [changing topics, so that it actually reflects the content] On 2010-04-08 20:33, William Herrin wrote: > On Thu, Apr 8, 2010 at 2:26 PM, Joe Greco wrote: >> With IPv6 designed the >> way it is, is there a realistic chance of running out of IPv6 even if >> some questionable delegations are made? > > Joe, > > You're aware that RIPE has already made some /19 and /20 IPv6 allocations? > > Yes, with suitably questionable delegations, it is possible to run out > of IPv6 quickly. Ever noticed that fat /13 for a certain military network in the ARIN region!? At least those /19 are justifyiable under the HD rules (XX million customers times a /48 and voila). A /13 though, very hard to justify... Also, please note that the current policies and "waste" (ahem) is only for 2000::/3, if that runs out we can take another 7 looks at how we should distribute address space without "waste". Indeed the folks now getting IPv6 will have an IPv4 A-class advantage, but heck, if 2000::/3 is full, we finally can say we properly deployed IPv6 straight all around to the rest of the universe... Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From kevin at steadfast.net Thu Apr 8 13:51:47 2010 From: kevin at steadfast.net (Kevin Stange) Date: Thu, 08 Apr 2010 13:51:47 -0500 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004081536.o38FaMKQ025021@aurora.sol.net> <4BBE21CF.2040504@steadfast.net> Message-ID: <4BBE25C3.3010909@steadfast.net> On 04/08/2010 01:47 PM, Dorn Hetzel wrote: > If there was an automatic website that just handed out up to a /40 on > demand, and charged a one-time fee of $100, I don't think the space > would ever be exhausted, there isn't enough money. I'd hate to see that routing table. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From ipv3.com at gmail.com Thu Apr 8 13:53:46 2010 From: ipv3.com at gmail.com (IPv3.com) Date: Thu, 8 Apr 2010 13:53:46 -0500 Subject: Likely /8 Scenario - Carriers will TAKE what they want ? Message-ID: Likely /8 Scenario - Carriers will TAKE what they want ? As /8s are needed by Carriers (not ISPs) they will likely be able to just take them. Who will stop them. They have the Imperial Walker Routers & Gear. http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt http://en.wikipedia.org/wiki/Walker_%28Star_Wars%29 From dhetzel at gmail.com Thu Apr 8 13:56:15 2010 From: dhetzel at gmail.com (Dorn Hetzel) Date: Thu, 8 Apr 2010 14:56:15 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4BBE25C3.3010909@steadfast.net> References: <201004081536.o38FaMKQ025021@aurora.sol.net> <4BBE21CF.2040504@steadfast.net> <4BBE25C3.3010909@steadfast.net> Message-ID: Well, yeah, but that is a separate problem. Anyone for an announced-prefix-tax ? :) On Thu, Apr 8, 2010 at 2:51 PM, Kevin Stange wrote: > On 04/08/2010 01:47 PM, Dorn Hetzel wrote: > > If there was an automatic website that just handed out up to a /40 on > > demand, and charged a one-time fee of $100, I don't think the space > > would ever be exhausted, there isn't enough money. > > I'd hate to see that routing table. > > -- > Kevin Stange > Chief Technology Officer > Steadfast Networks > http://steadfast.net > Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 > > From owen at delong.com Thu Apr 8 13:55:51 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 8 Apr 2010 11:55:51 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <4BBE118C.6070602@sprunk.org> Message-ID: <14429DA4-BBA0-469C-813C-B0D3E9B20A53@delong.com> > > On Thu, Apr 8, 2010 at 1:55 PM, Owen DeLong wrote: >> What, exactly do you find so onerous in the LRSA? > > Owen, > > ARIN's unilateral right under the LRSA to reclaim my addresses in the > event of a dispute bugs me a tad, as does similar verbiage sprinkled > throughout. > Let's clarify here, however... Nothing guarantees you that ARIN can not do so if you don't have any contract with them. There is a common fiction that ARIN somehow grants right to use or otherwise gives/transfers/leases/etc. Addresses. That is not the case. ARIN provides a REGISTRATION service which merely guarantees that neither ARIN, nor any of the other cooperating participants in the IANA/RIR system will register the same numbers to someone else. So, that clause really states that ARIN reserves the right to invalidate your registration if ARIN feels you are no longer playing by the rules under which that registration was granted. ARIN doesn't have the power to directly prevent you from using the address space. They merely have the ability to let the world know that it is no longer registered to you, and, the ability to register it to someone else. To the best of my knowledge, there is no legal reason ARIN could not do this with any legacy registration which is not the subject of an RSA or LRSA, as I do not believe there is a legal obligation for ARIN to provide services to customers without a service contract. I'm not saying that ARIN will or should do such a thing, but, signing the LRSA is about the only way to insure that ARIN can't do such a thing to your legacy resources. The "perceived" rights of legacy holders are dubious at best. The LRSA does not take any actual rights away, merely enumerates a very small number of the limitations that also exist without a contract. > >> Would it be equally onerous if ARIN simply stopped providing RDNS for you? > > Probably not. SMTP is the only major service any more that cares. But > that's immaterial; ending RDNS for legacy registrants has been an > empty threat from the day the notion was first hatched. > Sure... I'm not advocating any such thing, either. The point being that while I think continuing to provide a free ride to IPv4 legacy holders is a good idea, there is no reason to continue that concept into the IPv6 world. I would like to see fee waivers for IPv6 initial assignment fees to legacy holders who sign the LRSA. I think that would be a good incentive for both the LRSA and IPv6 adoption. However, when I suggested that, there was some negative feedback from the community and I don't think the idea achieved clear consensus for or against. Owen From jack at crepinc.com Thu Apr 8 14:07:47 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Thu, 8 Apr 2010 15:07:47 -0400 Subject: Likely /8 Scenario - Carriers will TAKE what they want ? In-Reply-To: References: Message-ID: Might want to save the we're-all-going-to-die for nanog-lounge or whatever was created and leave the more likely operational scenarios here. Just sayin' -J On Thu, Apr 8, 2010 at 2:53 PM, IPv3.com wrote: > Likely /8 Scenario - Carriers will TAKE what they want ? > > As /8s are needed by Carriers (not ISPs) they will likely be able to > just take them. > Who will stop them. They have the Imperial Walker Routers & Gear. > > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt > > http://en.wikipedia.org/wiki/Walker_%28Star_Wars%29 > > From cgrundemann at gmail.com Thu Apr 8 14:10:59 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 8 Apr 2010 13:10:59 -0600 Subject: "Running out of IPv6" (Re: ARIN IP6 policy for those with legacy IP4 Space) In-Reply-To: <4BBE24CC.2050803@unfix.org> References: <000601cad73d$2cac32a0$860497e0$@org> <201004081826.o38IQpfJ038982@aurora.sol.net> <4BBE24CC.2050803@unfix.org> Message-ID: On Thu, Apr 8, 2010 at 12:47, Jeroen Massar wrote: > [changing topics, so that it actually reflects the content] > > On 2010-04-08 20:33, William Herrin wrote: >> Yes, with suitably questionable delegations, it is possible to run out >> of IPv6 quickly. The bottom line (IMHO) is that IPv6 is NOT infinite and propagating that myth will lead to waste. That being said, the IPv6 space is MUCH larger than IPv4. Somewhere between 16 million and 17 billion times larger based on current standards by my math[1]. > Ever noticed that fat /13 for a certain military network in the ARIN > region!? > > At least those /19 are justifyiable under the HD rules (XX million > customers times a /48 and voila). A /13 though, very hard to justify... Not every customer needs a /48. In fact most probably don't. > Also, please note that the current policies and "waste" (ahem) is only > for 2000::/3, if that runs out we can take another 7 looks at how we > should distribute address space without "waste". > Indeed the folks now getting IPv6 will have an IPv4 A-class advantage, > but heck, if 2000::/3 is full, we finally can say we properly deployed > IPv6 straight all around to the rest of the universe... Very good point and likely our saving grace in v6. The space is big enough that we will get a sanity check after (possibly) burning through the first /3 much faster than expected. ~Chris [1] - "How much IPv6 is there?" http://weblog.chrisgrundemann.com/index.php/2009/how-much-ipv6-is-there/ > > Greets, > ?Jeroen > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From ipv3.com at gmail.com Thu Apr 8 14:14:42 2010 From: ipv3.com at gmail.com (IPv3.com) Date: Thu, 8 Apr 2010 14:14:42 -0500 Subject: More Likely Scenario AUTOMATED IPv4+ Management will CHURN /8s ? Message-ID: More Likely Scenario AUTOMATED IPv4+ Management will CHURN /8s ? Imagine this table times ?? 16 http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Imagine a Fully-Automated Management System that can hand YOU a /18 in a /12 Imagine there are NO RIRs or Labor Union Bosses or PIMPS driving around in Pink Cadillacs From bill at herrin.us Thu Apr 8 14:14:50 2010 From: bill at herrin.us (William Herrin) Date: Thu, 8 Apr 2010 15:14:50 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <20100408183757.GA9681@vacation.karoshi.com.> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <4BBE118C.6070602@sprunk.org> <20100408183757.GA9681@vacation.karoshi.com.> Message-ID: On Thu, Apr 8, 2010 at 2:37 PM, wrote: > On Thu, Apr 08, 2010 at 02:22:29PM -0400, William Herrin wrote: >> On Thu, Apr 8, 2010 at 1:49 PM, Mr. James W. Laferriere >> > ? ? ? ?Try that fee while trying to make a living in a depressed econimic >> > region JUST for an ipv4 /24 Assignment . ?I don't make enough to cover that >> >> Not much sympathy for folks crying the blues about the cost of an >> address assignment that they're going to turn around and announce into >> the DFZ... > > ? ? ? ?assuming facts not in evidence there ... but ok. Hi Bill, If you're not planning to announce a route into the DFZ, we have RFC1918 or IPv6's ULA, address pools that are 100% and completely free for your use. >> ARIN has implemented a structure to facilitate IPv4 address transfers >> should an open market come to exist. Between an address market and the >> ever more creative use of NAT, it should be possible for IPv4 >> addressing to continue after free pool depletion as a zero-sum game. >> Exactly how long is a matter of debate with speculation ranging from >> months to decades. > > ? ? ? ?cool. ?I've used the transfer policy with limited success. > ? ? ? ?I guess the interesting thing in your statement (and I suspect > ? ? ? ?a trip to the ARIN NRPM is in order) is "should an open market > ? ? ? ?come into existence" ... how do you see that happening? eBay? Given a demand and a supply, markets don't traditionally need a whole lot of help to come into being. > ? ? ? ?but more to my point. ?If I'm using a single /24 out of my /20 > ? ? ? ?(using an antiquated example) - would there be: > > ? ? ? ?) interest in the other 15 /24s > ? ? ? ?) how would that interest be expressed (so I would know about it) > ? ? ? ?) complaints from the folks running w/o default about > ? ? ? ? ?the new prefixes on offer? ?** The basic plan (ARIN NRPM section 8.3) is: 1. Request and be approved for addresses from ARIN (even though ARIN won't have any addresses to give). 2. Find (pay) someone who has ARIN-managed addresses that they're willing to give up in the quantity you want. 3. Current holder releases addresses to ARIN in the requested (paid) quantity with instructions to provide those addresses to the already-authorized recipient (in #1). 4. ARIN updates the registration accordingly. On Thu, Apr 8, 2010 at 2:47 PM, Dorn Hetzel wrote: > If there was an automatic website that just handed out up to a /40 on > demand, and charged a one-time fee of $100, I don't think the space would > ever be exhausted, there isn't enough money. 137 billion prefixes would crush the DFZ routers of course, but as we all know the routing table isn't ARIN's lookout. :-P On Thu, Apr 8, 2010 at 2:55 PM, Owen DeLong wrote: >> ARIN's unilateral right under the LRSA to reclaim my addresses in the >> event of a dispute bugs me a tad, as does similar verbiage sprinkled >> throughout. > > Let's clarify here, however... > Nothing guarantees you that ARIN can not do so if you don't have any > contract with them. Owen, Your uneducated YANAL opinion about the governing law in the matter is duly noted and filed beside my own differing viewpoint. Until and unless ARIN attempts to forcibly reclaim a block of legacy addresses from its legacy holder, the question remains theoretical. > The point being that > while I think continuing to provide a free ride to IPv4 legacy holders > is a good idea, there is no reason to continue that concept into the > IPv6 world. The reason is that it could be structured to increase the rate of IPv6 deployment, to the benefit of all. To what degree that would achieve value for cost is debatable, but it certainly qualifies as more than "no reason." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jgreco at ns.sol.net Thu Apr 8 14:17:30 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 8 Apr 2010 14:17:30 -0500 (CDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4BBE21CF.2040504@steadfast.net> from "Kevin Stange" at Apr 08, 2010 01:34:55 PM Message-ID: <201004081917.o38JHVFK046439@aurora.sol.net> > Just because the benefit of being cautious isn't clear doesn't mean we > should simply throw caution to the wind entirely and go back to the "old > ways." It seems clear to many now that a lot of the legacy allocations, > /8's in particular were issued in a way that has left IPv4 inefficiently > allocated and with lack of any agreements by the resource holders to > have any responsibility to do anything about it. There's a lot of space between throwing caution to the wind and the current set of agreements. The current v6 agreements read a lot like the v4 agreements. > If we just eliminated the RIRs and agreements governing terms of access > to v6 allocations, IF later, we find a problem with the process and > start to run out of space, we end up in the same situation. Suddenly we > have to form these organizations again, and institute new allocation > policies for new allocations, but again lack any recourse for all those > people that "greedily" ate up as much space as they could. Then guard against _that_, which is a real problem. > I think there's a continued need to keep an organization in charge of > accounting for the space to whom we as resource holders are accountable > and whom is also accountable to us. Later on, when we realize we've > gone wrong somewhere (and it will happen) and need to make changes to > policy, there is a process by which we can do it where all the parties > involved already have an established relationship. That sets off my radar detector a bit. If you're justifying the need for current policies with that statement, I'd have to disagree... the desire to potentially make changes in the future is not itself a compelling reason to have strongly worded agreements. Even in v4land, we've actually determined that one of the few relatively serious reasons we'd like to reclaim space (depletion) is probably impractical. With that in mind, claims that there needs to be thorough accounting kind of comes off like "trust us, we're in charge, we know what we need but we can't really explain it aside from invoking the boogeyman." On one hand? You absolutely don't want to go around delegating /20's to organizations that clearly have no need. On the other hand, you don't need heavyhanded agreements to avoid that in the first place. This is kind of off-topic for NANOG, so I'll stick with what I've said unless someone has a really good point. ... 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 tchristell at springnet.net Thu Apr 8 14:17:21 2010 From: tchristell at springnet.net (Todd Christell) Date: Thu, 8 Apr 2010 14:17:21 -0500 Subject: Metering power in data center In-Reply-To: References: Message-ID: <97487AA41962C74E83D8ABABD2A90A4905A7FD9992@mail.springnet.local> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We use the enersure product from trendpoint in our data center. I'm not the power guy but our mothership is an electric utility so I would assume it is a good choice. http://www.trendpoint.com/enersure.html tlc Todd Christell Manager Network Architecture and Support www.springnet.net 417.831.8688 Key fingerprint = 4F26 A0B4 5AAD 7FCA 48DD 7F40 A57E 9235 5202 D508 - -----Original Message----- From: Jay Nakamura [mailto:zeusdadog at gmail.com] Sent: Thursday, April 08, 2010 1:10 PM To: NANOG Subject: Metering power in data center I am looking for suggestions on devices that can monitor(A)/meter(kw/h) power usage in a data center. Getting a metered PDU everywhere seems a little expensive and cumbersome. Are there devices you can wire into breaker box to meter each AC circuit? Thanks in advance for any suggestions. - -Jay -----BEGIN PGP SIGNATURE----- Version: 10.0.1 (Build 4020) Charset: utf-8 wj8DBQFLvivgpX6SNVIC1QgRAgPRAJ9IHGqbMH3xOJgziIN0cS5zINGGfwCfeeNU wh/TysRmuVE6hdu0sQcxHjs= =H4+s -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: Christell Todd.vcf Type: text/x-vcard Size: 548 bytes Desc: Christell Todd.vcf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Christell Todd.vcf.sig Type: application/octet-stream Size: 191 bytes Desc: Christell Todd.vcf.sig URL: From bruns at 2mbit.com Thu Apr 8 14:18:23 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 08 Apr 2010 13:18:23 -0600 Subject: Likely /8 Scenario - Carriers will TAKE what they want ? In-Reply-To: References: Message-ID: <4BBE2BFF.1000400@2mbit.com> On 4/8/10 1:07 PM, Jack Carrozzo wrote: > Might want to save the we're-all-going-to-die for nanog-lounge or > whatever was created and leave the more likely operational scenarios > here. > > Just sayin' > Guillaume Fortaine v2.0, IMHO. :-) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From niels=nanog at bakker.net Thu Apr 8 14:27:07 2010 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 8 Apr 2010 21:27:07 +0200 Subject: More Likely Scenario AUTOMATED IPv4+ Management will CHURN /8s ? In-Reply-To: References: Message-ID: <20100408192707.GJ77019@burnout.tpb.net> * ipv3.com at gmail.com (IPv3.com) [Thu 08 Apr 2010, 21:15 CEST]: >Imagine a Fully-Automated Management System that can hand YOU a /18 in a /12 > >Imagine there are NO RIRs or Labor Union Bosses or PIMPS driving >around in Pink Cadillacs Jim Fleming, don't you know better than to post to mailing lists while stoned? -- Niels (imagining mailing lists without ridiculous trolls) From mpetach at netflight.com Thu Apr 8 14:29:08 2010 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 8 Apr 2010 12:29:08 -0700 Subject: More Likely Scenario AUTOMATED IPv4+ Management will CHURN /8s ? In-Reply-To: References: Message-ID: On Thu, Apr 8, 2010 at 12:14 PM, IPv3.com wrote: ... > Imagine this table times ?? 16 > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt > > Imagine a Fully-Automated Management System that can hand YOU a /18 in a /12 > > Imagine there are NO RIRs or Labor Union Bosses or PIMPS driving > around in Pink Cadillacs Imagine there's no countries It isn't hard to do Nothing to kill or die for And no religion too Imagine all the people Living life in peace... Oh...sorry, I thought it was John Lennon tribute day here on NANOG. /me goes back to doing real work now From ipv3.com at gmail.com Thu Apr 8 14:32:44 2010 From: ipv3.com at gmail.com (IPv3.com) Date: Thu, 8 Apr 2010 14:32:44 -0500 Subject: RIRs are More Interested in Selling NEW than Pre-Owned? Message-ID: RIRs are More Interested in Selling NEW than Pre-Owned? It is a myth that IPv4 is "out of space". It has the same space it started with if 32-bits are routed. More bits can easily be used for routing purposes before switching to IPv6. People seem to be happy with 34 bits, one extra bit at each end. 1+32+1 RIRs may not like the reality of Selling Pre-Owned "Vehicles" There are many problems out there. http://www.iblocklist.com/lists.php The push to Sell Brand New Virgin IPv6 Space makes RIR life easy. Easy money. From drc at virtualized.org Thu Apr 8 14:33:44 2010 From: drc at virtualized.org (David Conrad) Date: Thu, 8 Apr 2010 09:33:44 -1000 Subject: "Running out of IPv6" (Re: ARIN IP6 policy for those with legacy IP4 Space) In-Reply-To: <4BBE24CC.2050803@unfix.org> References: <000601cad73d$2cac32a0$860497e0$@org> <201004081826.o38IQpfJ038982@aurora.sol.net> <4BBE24CC.2050803@unfix.org> Message-ID: <5FA13475-81CB-4277-9E3F-33A48133B55C@virtualized.org> On Apr 8, 2010, at 8:47 AM, Jeroen Massar wrote: > [changing topics, so that it actually reflects the content] > > On 2010-04-08 20:33, William Herrin wrote: >> You're aware that RIPE has already made some /19 and /20 IPv6 allocations? >> >> Yes, with suitably questionable delegations, it is possible to run out >> of IPv6 quickly. > > Ever noticed that fat /13 for a certain military network in the ARIN region!? I think that was William's point. > At least those /19 are justifyiable under the HD rules (XX million customers times a /48 and voila). A /13 though, very hard to justify... Both are questionable, it's just a matter of degree. > Also, please note that the current policies and "waste" (ahem) is only > for 2000::/3, if that runs out we can take another 7 looks at how we > should distribute address space without "waste". Unfortunately, since address allocation policy is subject to the whims of the public policy definition process there is a risk (e.g., the proposal to allocate /24s of IPv6 if you knew the magic word or the proposals out of the ITU to allocate country blocks (/8s have been mentioned)). There is no finite resource that people can't waste. Regards, -drc From bruns at 2mbit.com Thu Apr 8 14:35:13 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 08 Apr 2010 13:35:13 -0600 Subject: RIRs are More Interested in Selling NEW than Pre-Owned? In-Reply-To: References: Message-ID: <4BBE2FF1.5070607@2mbit.com> On 4/8/10 1:32 PM, IPv3.com wrote: > RIRs are More Interested in Selling NEW than Pre-Owned? > > It is a myth that IPv4 is "out of space". It has the same space it > started with if 32-bits are routed. > More bits can easily be used for routing purposes before switching to IPv6. > People seem to be happy with 34 bits, one extra bit at each end. 1+32+1 > > RIRs may not like the reality of Selling Pre-Owned "Vehicles" > There are many problems out there. > http://www.iblocklist.com/lists.php > > The push to Sell Brand New Virgin IPv6 Space makes RIR life easy. Easy money. > Can one of the list mods step in and do something about the illegitimate bastard offspring of Guillaume Fortaine? :) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bmanning at vacation.karoshi.com Thu Apr 8 14:39:32 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 8 Apr 2010 19:39:32 +0000 Subject: Behold - the Address-Yenta! In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <4BBE118C.6070602@sprunk.org> <20100408183757.GA9681@vacation.karoshi.com.> Message-ID: <20100408193932.GA10217@vacation.karoshi.com.> On Thu, Apr 08, 2010 at 03:14:50PM -0400, William Herrin wrote: > On Thu, Apr 8, 2010 at 2:37 PM, wrote: > > On Thu, Apr 08, 2010 at 02:22:29PM -0400, William Herrin wrote: > >> On Thu, Apr 8, 2010 at 1:49 PM, Mr. James W. Laferriere > >> > Try that fee while trying to make a living in a depressed econimic > >> > region JUST for an ipv4 /24 Assignment . I don't make enough to cover that > >> > >> Not much sympathy for folks crying the blues about the cost of an > >> address assignment that they're going to turn around and announce into > >> the DFZ... > > > > assuming facts not in evidence there ... but ok. > > Hi Bill, > > If you're not planning to announce a route into the DFZ, we have > RFC1918 or IPv6's ULA, address pools that are 100% and completely free > for your use. er... you misunderstand... there is no single "DFZ" anywhere... it is a fiction. no prefix in existance, save 127.0.0.0, ::1, and 0.0.0.0 is globally reachable. reachability depends on your POV, where "you" is roughly the number of addressable entities on the planet. folks announce a route to their peers, and last i checked, no ASN peered with -everyone-. that said, transient connectivity is even more popular now than it was twenty years ago. folks connect/disconnect/reconnet all the time. this is the primary reason why Globally Unique Addresses are so important - one cna nver tell when they will need to peer with someone else in the future. > > >> ARIN has implemented a structure to facilitate IPv4 address transfers > >> should an open market come to exist. Between an address market and the > >> ever more creative use of NAT, it should be possible for IPv4 > >> addressing to continue after free pool depletion as a zero-sum game. > >> Exactly how long is a matter of debate with speculation ranging from > >> months to decades. > > > > cool. I've used the transfer policy with limited success. > > I guess the interesting thing in your statement (and I suspect > > a trip to the ARIN NRPM is in order) is "should an open market > > come into existence" ... how do you see that happening? > > eBay? last ebay transaction I saw was a posting by Martin Levy - and it was withdrawn after some urging by ARIN. Addresses are not sellable property. So what would an "open market" be in... rights to use? (come to think of it, I have seen submarine cable IRUs for sale on eBAY) > Given a demand and a supply, markets don't traditionally need a whole > lot of help to come into being. Ok... lets say there is a pent up supply ... and no good way to let those with demand know the supply exists. I'll consider acting as the "address Yenta" --- if folks have prefixes they are not using, and would like to let others know there is availablity, I'll be glad to be the "go between". > > but more to my point. If I'm using a single /24 out of my /20 > > (using an antiquated example) - would there be: > > > > ) interest in the other 15 /24s > > ) how would that interest be expressed (so I would know about it) > > ) complaints from the folks running w/o default about > > the new prefixes on offer? ** > > The basic plan (ARIN NRPM section 8.3) is: > > 1. Request and be approved for addresses from ARIN (even though ARIN > won't have any addresses to give). > > 2. Find (pay) someone who has ARIN-managed addresses that they're > willing to give up in the quantity you want. > > 3. Current holder releases addresses to ARIN in the requested (paid) > quantity with instructions to provide those addresses to the > already-authorized recipient (in #1). > > 4. ARIN updates the registration accordingly. I remember this. it suffers from two primary weaknesses: ) finding someone (see my address-Yenta offer above) ) this only works within the ARIN region. > On Thu, Apr 8, 2010 at 2:47 PM, Dorn Hetzel wrote: > > If there was an automatic website that just handed out up to a /40 on > > demand, and charged a one-time fee of $100, I don't think the space would > > ever be exhausted, there isn't enough money. > > 137 billion prefixes would crush the DFZ routers of course, but as we > all know the routing table isn't ARIN's lookout. :-P > > > On Thu, Apr 8, 2010 at 2:55 PM, Owen DeLong wrote: > >> ARIN's unilateral right under the LRSA to reclaim my addresses in the > >> event of a dispute bugs me a tad, as does similar verbiage sprinkled > >> throughout. > > > > Let's clarify here, however... > > Nothing guarantees you that ARIN can not do so if you don't have any > > contract with them. > > Owen, > > Your uneducated YANAL opinion about the governing law in the matter is > duly noted and filed beside my own differing viewpoint. Until and > unless ARIN attempts to forcibly reclaim a block of legacy addresses > from its legacy holder, the question remains theoretical. > > > > The point being that > > while I think continuing to provide a free ride to IPv4 legacy holders > > is a good idea, there is no reason to continue that concept into the > > IPv6 world. > > The reason is that it could be structured to increase the rate of IPv6 > deployment, to the benefit of all. To what degree that would achieve > value for cost is debatable, but it certainly qualifies as more than > "no reason." > > > Regards, > Bill Herrin > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > From ipv3.com at gmail.com Thu Apr 8 14:40:30 2010 From: ipv3.com at gmail.com (IPv3.com) Date: Thu, 8 Apr 2010 14:40:30 -0500 Subject: "There is no finite resource that people can't waste." Message-ID: "There is no finite resource that people can't waste." "There is no finite resource that people can't make even more scarce & Artificially Scarce" ? ....and then Profit very nicely from the Artificial Scarcity & related myths From john at sackheads.org Thu Apr 8 14:49:34 2010 From: john at sackheads.org (John Payne) Date: Thu, 8 Apr 2010 15:49:34 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004081536.o38FaMKQ025021@aurora.sol.net> References: <201004081536.o38FaMKQ025021@aurora.sol.net> Message-ID: On Apr 8, 2010, at 11:36 AM, Joe Greco wrote: > IPv6-only content won't be meaningful for years yet, and IPv6-only > eyeballs will necessarily be given ways to reach v4 for many years > to come. So again, why do WE have to encourage YOU to adopt IPv6? Why should WE care what you do to the point of creating new rules so YOU don't have to pay like everyone else? From ipv3.com at gmail.com Thu Apr 8 14:51:18 2010 From: ipv3.com at gmail.com (IPv3.com) Date: Thu, 8 Apr 2010 14:51:18 -0500 Subject: NANOG Seems to be Dominated by NON-North American People ? Message-ID: NANOG Seems to be Dominated by NON-North American People ? ...odd ARIN seems to have a similar situation ...odd By the way, on likely scenarios, North America could become a Walled Garden making many /8s available for decades. http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt The rest of the world would then have IPv6 Proxy Access. That could be a major boost to the U.S. economy with Information Export Fees. This could be a Great Time to Start an ISP in .USA - Plenty of IPv4+ Address Space. ...and fools are wasting their time and money on IPv6 From drc at virtualized.org Thu Apr 8 14:51:47 2010 From: drc at virtualized.org (David Conrad) Date: Thu, 8 Apr 2010 09:51:47 -1000 Subject: Behold - the Address-Yenta! In-Reply-To: <20100408193932.GA10217@vacation.karoshi.com.> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <4BBE118C.6070602@sprunk.org> <20100408183757.GA9681@vacation.karoshi.com.> <20100408193932.GA10217@vacation.karoshi.com.> Message-ID: BIll, On Apr 8, 2010, at 9:39 AM, bmanning at vacation.karoshi.com wrote: >> If you're not planning to announce a route into the DFZ, we have >> RFC1918 or IPv6's ULA, address pools that are 100% and completely free >> for your use. > > er... you misunderstand... there is no single "DFZ" anywhere... Pedantry alert. > Addresses are not sellable property. Sure they are. I personally know of several cases where addresses have been sold. Right now, people have to go through a bunch of foo, creating dummy companies to hold the IP address assets, transferring the assets, selling the dummy companies, etc., but the end result is the same. Policy changes will make this somewhat less silly. Whether those policy changes will be sufficient to stop the creation of alternative "address title registries" remains to be seen. >> Given a demand and a supply, markets don't traditionally need a whole >> lot of help to come into being. > > Ok... lets say there is a pent up supply ... and no good way to > let those with demand know the supply exists. I'll consider > acting as the "address Yenta" --- if folks have prefixes they > are not using, and would like to let others know there is availablity, > I'll be glad to be the "go between". Given current address space utilization efficiency, it isn't hard to find folks who have more address space than they are using. However, I suspect there are VCs who would be interested in discussing the idea... Regards, -drc From sfouant at shortestpathfirst.net Thu Apr 8 14:56:53 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Thu, 8 Apr 2010 15:56:53 -0400 Subject: RIRs are More Interested in Selling NEW than Pre-Owned? In-Reply-To: <4BBE2FF1.5070607@2mbit.com> References: <4BBE2FF1.5070607@2mbit.com> Message-ID: <013b01cad755$a3705340$ea50f9c0$@net> > -----Original Message----- > From: Brielle Bruns [mailto:bruns at 2mbit.com] > Sent: Thursday, April 08, 2010 3:35 PM > To: nanog at nanog.org > Subject: Re: RIRs are More Interested in Selling NEW than Pre-Owned? > > On 4/8/10 1:32 PM, IPv3.com wrote: > > RIRs are More Interested in Selling NEW than Pre-Owned? > > > > It is a myth that IPv4 is "out of space". It has the same space it > > started with if 32-bits are routed. > > More bits can easily be used for routing purposes before switching to > IPv6. > > People seem to be happy with 34 bits, one extra bit at each end. > 1+32+1 > > > > RIRs may not like the reality of Selling Pre-Owned "Vehicles" > > There are many problems out there. > > http://www.iblocklist.com/lists.php > > > > The push to Sell Brand New Virgin IPv6 Space makes RIR life easy. > Easy money. > > > > Can one of the list mods step in and do something about the > illegitimate > bastard offspring of Guillaume Fortaine? :) At least Jim is being nice and sourcing from the same email consistently. Should be easy to filter his address from the list. But just to be safe, should probably filter anything with a reference to ipv3, ipv5, ipv7, ipv8, and any other cockamamie address schemes... ;) Stefan Fouant, CISSP, JNCIEx2 www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From bill at herrin.us Thu Apr 8 15:01:55 2010 From: bill at herrin.us (William Herrin) Date: Thu, 8 Apr 2010 16:01:55 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004081536.o38FaMKQ025021@aurora.sol.net> Message-ID: On Thu, Apr 8, 2010 at 3:49 PM, John Payne wrote: > So again, why do WE have to encourage YOU to adopt IPv6? > Why should WE care what you do to the point of creating > new rules so YOU don't have to pay like everyone else? Because when WE haven't deployed IPv6 yet and YOU have trouble finding a free IPv4 address for your new server, it'll be YOUR problem too. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From vaf at cisco.com Thu Apr 8 15:02:51 2010 From: vaf at cisco.com (Vince Fuller) Date: Thu, 8 Apr 2010 13:02:51 -0700 Subject: what about 48 bits? In-Reply-To: <4BBA2D35.6070805@foobar.org> References: <20100405105746.750257bf@opy.nosense.org> <20100405025742.GR75640@gerbil.cluepon.net> <4BB96187.6040703@bogus.com> <2B39543C-7EF5-48AE-9E54-3E8A0C714204@cs.columbia.edu> <13353.1270489432@localhost> <0CEC3B65-F639-4B0D-AC0E-F3AF99779EEB@cs.columbia.edu> <4BBA2D35.6070805@foobar.org> Message-ID: <20100408200250.GA2816@vaf-mac1.cisco.com> > To be fair, everything for a vax was somewhat pricey. And slow. > > On an even more unrelated note, does anyone remember the day that > CMU-TEK tcp/ip stopped working some time in the early 1990s? That was a > load of fun. What made it stop working? I was the guy to blame for the IP/TCP/UDP parts of "CMU-TEK" and had long since left CMU by the mid-90s. Dale Moore (still at CMU last time I checked) did the applications. --Vince From kevin at steadfast.net Thu Apr 8 15:03:02 2010 From: kevin at steadfast.net (Kevin Stange) Date: Thu, 08 Apr 2010 15:03:02 -0500 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004081917.o38JHVFK046439@aurora.sol.net> References: <201004081917.o38JHVFK046439@aurora.sol.net> Message-ID: <4BBE3676.5010203@steadfast.net> On 04/08/2010 02:17 PM, Joe Greco wrote: >> If we just eliminated the RIRs and agreements governing terms of access >> to v6 allocations, IF later, we find a problem with the process and >> start to run out of space, we end up in the same situation. Suddenly we >> have to form these organizations again, and institute new allocation >> policies for new allocations, but again lack any recourse for all those >> people that "greedily" ate up as much space as they could. > > Then guard against _that_, which is a real problem. That /is/ the RIRs' function now. ARIN policy is not immutable. Proposals to change it are welcomed. I see no reason that we have to throw ARIN out of this picture in order to solve your perceived problem of too much regulation and overhead. >> I think there's a continued need to keep an organization in charge of >> accounting for the space to whom we as resource holders are accountable >> and whom is also accountable to us. Later on, when we realize we've >> gone wrong somewhere (and it will happen) and need to make changes to >> policy, there is a process by which we can do it where all the parties >> involved already have an established relationship. > > That sets off my radar detector a bit. If you're justifying the need > for current policies with that statement, I'd have to disagree... the > desire to potentially make changes in the future is not itself a > compelling reason to have strongly worded agreements. Even in v4land, > we've actually determined that one of the few relatively serious > reasons we'd like to reclaim space (depletion) is probably impractical. > > With that in mind, claims that there needs to be thorough accounting > kind of comes off like "trust us, we're in charge, we know what we need > but we can't really explain it aside from invoking the boogeyman." ARIN doesn't so simply say "trust us, we're in charge." Every dealing I've ever had with the organization has encouraged me to participate in the policy making process in some regard. Ideally policy should appropriately reflect how the regional users of IP resources feel things should be managed and hand down terms for allocation to match. The intention is for the accountability to go in both directions, from resource holders to the RIR and from the RIR to the community. If you don't think that's working for ARIN, I'm sure ARIN can be fixed. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From mpalmer at hezmatt.org Thu Apr 8 15:05:00 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Fri, 9 Apr 2010 06:05:00 +1000 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004081536.o38FaMKQ025021@aurora.sol.net> <4BBE21CF.2040504@steadfast.net> <4BBE25C3.3010909@steadfast.net> Message-ID: <20100408200500.GJ4242@hezmatt.org> On Thu, Apr 08, 2010 at 02:56:15PM -0400, Dorn Hetzel wrote: > Well, yeah, but that is a separate problem. Anyone for an > announced-prefix-tax ? :) Just add "announced prefixes" to the settlement charges, alongside bits transferred... - Matt -- A friend is someone you can call to help you move. A best friend is someone you can call to help you move a body. From ipv3.com at gmail.com Thu Apr 8 15:10:25 2010 From: ipv3.com at gmail.com (IPv3.com) Date: Thu, 8 Apr 2010 15:10:25 -0500 Subject: IPv4+ 2010 Routable /8s for North America Message-ID: IPv4+ 2010 Routable /8s for North America 12 63 64 65 68 69 70 71 72 74 75 76 99 139 151 192 199 204 205 206 207 216 ...eventually things will "Free Up" http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt From bmanning at vacation.karoshi.com Thu Apr 8 15:13:23 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 8 Apr 2010 20:13:23 +0000 Subject: Behold - the Address-Yenta! In-Reply-To: References: <68107E737FF84E2FB5409B1D516C022F@TAKA> <4BBE118C.6070602@sprunk.org> <20100408183757.GA9681@vacation.karoshi.com.> <20100408193932.GA10217@vacation.karoshi.com.> Message-ID: <20100408201323.GA10560@vacation.karoshi.com.> On Thu, Apr 08, 2010 at 09:51:47AM -1000, David Conrad wrote: > BIll, > > On Apr 8, 2010, at 9:39 AM, bmanning at vacation.karoshi.com wrote: > >> If you're not planning to announce a route into the DFZ, we have > >> RFC1918 or IPv6's ULA, address pools that are 100% and completely free > >> for your use. > > > > er... you misunderstand... there is no single "DFZ" anywhere... > > Pedantry alert. yeah yeah yeah... you passed that class last century. why are you still here? > > > Addresses are not sellable property. > > Sure they are. I personally know of several cases where addresses have been sold. Right now, people have to go through a bunch of foo, creating dummy companies to hold the IP address assets, transferring the assets, selling the dummy companies, etc., but the end result is the same. Policy changes will make this somewhat less silly. Whether those policy changes will be sufficient to stop the creation of alternative "address title registries" remains to be seen. you might want to let the ARIN GC know of the particulars here. selling dummy companies is not selling address space (technically). > >> Given a demand and a supply, markets don't traditionally need a whole > >> lot of help to come into being. > > > > Ok... lets say there is a pent up supply ... and no good way to > > let those with demand know the supply exists. I'll consider > > acting as the "address Yenta" --- if folks have prefixes they > > are not using, and would like to let others know there is availablity, > > I'll be glad to be the "go between". > > Given current address space utilization efficiency, it isn't hard to find folks who have more address space than they are using. However, I suspect there are VCs who would be interested in discussing the idea... bring them on. VC's are you listening? > > Regards, > -drc > From jgreco at ns.sol.net Thu Apr 8 15:14:03 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 8 Apr 2010 15:14:03 -0500 (CDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: from "John Payne" at Apr 08, 2010 03:49:34 PM Message-ID: <201004082014.o38KE3WM051378@aurora.sol.net> > On Apr 8, 2010, at 11:36 AM, Joe Greco wrote: > > > IPv6-only content won't be meaningful for years yet, and IPv6-only > > eyeballs will necessarily be given ways to reach v4 for many years > > to come. > > So again, why do WE have to encourage YOU to adopt IPv6? > Why should WE care what you do to the point of creating new rules so YOU don't have to pay like everyone else? Flip it around: Why should WE care about IPv6? WE would have to sign an onerous RSA with ARIN, giving up some of our rights in the process. WE have sufficient IP space to sit it out awhile; by doing that, WE save cash in a tight economy. WE are not so large that we spend four figures without batting an eyelash, so that's attractive. Further, anyone who is providing IPv6-only content has cut off most of the Internet, so basically no significant content is available on IPv6- only. That means there is no motivation for US to jump on the IPv6 bandwagon. Even more, anyone who is on an IPv6-only eyeball network is cut off from most of the content of the Internet; this means that ISP's will be having to provide IPv6-to-v4 services. Either they'll be good, or if customers complain, WE will be telling them how badly their ISP sucks. *I* am personally convinced that IPv6 is great, but on the other hand, I do not see so much value in v6 that I am prepared to compel the budgeting for ARIN v6 fees, especially since someone from ARIN just described all the ways in which they fritter away money. As a result, the state of affairs simply retards the uptake and adoption of v6 among networks that would otherwise be agreeable to the idea; so, tell me, do you see that as being beneficial to the Internet community at large, or not? Note that I'm taking a strongly opposing stance for the sake of debate, the reality is a bit softer. Given a moderately good offer, we'd almost certainly adopt IPv6. ... 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 danny at tcb.net Thu Apr 8 15:20:23 2010 From: danny at tcb.net (Danny McPherson) Date: Thu, 8 Apr 2010 14:20:23 -0600 Subject: China prefix hijack In-Reply-To: References: <20100408171935.GD30450@staff.dca.net> <001f01cad740$ccf0c390$4401a8c0@jgbpc> <20100408174405.GD4808@dan.olp.net> Message-ID: <81F89E7A-0A21-43B6-89AC-839C69B31521@tcb.net> On Apr 8, 2010, at 11:45 AM, Martin A. Brown wrote: > Just a note of confirmation that 23724 originated as many as 31847 > prefixes during an 18 minute window starting around 15:54 UTC. > They were prepending their own AS, and this is several orders of > magnitude more prefixes than they normally originate. Interestingly, they re-originated these prefixes - as opposed to simply leaking them, which means origin AS-based filters (e.g., as provided by the current RPKI and SIDR work) would have prevented this (however, origin AS-based filters would NOT have prevented the i-root incident a couple weeks back). Most of the incidents we see of this sort with a large number of prefixes are traditional leaks with path preservation - so that does make one raise an eyebrow. Of course, even gross "max prefix" policies would have also helped here to some extent, to at least limit the scope of this incident to a much smaller number of prefixes. One might well observe that RFC 1998-esque policies that employ LOCAL_PREF to prefer prefixes from customers over like prefixes from peers means that ALL ISPs that employ such policies in that transit service hierarchy will first ignore the AS path length when making BGP best path decisions (i.e., if a leaking Chinese provider were a transit customer of a large U.S. provider and were given BGP preference as a result, then all of that U.S. ISPs customers will end up using the Chinese path as opposed to a path learned locally in the U.S. from a peer). Perhaps it's time to rethink application of such policies ubiquitously across peers and customers, or to at least be more selective in such policy application. Just one more incident to illustrate how fragile the routing system is, and how broken the current "routing by rumor" model continues to be. -danny From jay at west.net Thu Apr 8 15:23:06 2010 From: jay at west.net (Jay Hennigan) Date: Thu, 08 Apr 2010 13:23:06 -0700 Subject: BGP hijack from 23724 -> 4134 China? Message-ID: <4BBE3B2A.7070901@west.net> We just got Cyclops alerts showing several of our prefixes sourced from AS23474 propagating through AS4134. Anyone else? aut-num: AS23724 as-name: CHINANET-IDC-BJ-AP descr: IDC, China Telecommunications Corporation country: CN aut-num: AS4134 as-name: CHINANET-BACKBONE descr: No.31,Jin-rong Street descr: Beijing descr: 100032 country: CN -- 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 john at sackheads.org Thu Apr 8 15:27:43 2010 From: john at sackheads.org (John Payne) Date: Thu, 8 Apr 2010 16:27:43 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004081536.o38FaMKQ025021@aurora.sol.net> Message-ID: <6C604EC4-ED91-46C7-91F1-87F3FB6E3B20@sackheads.org> On Apr 8, 2010, at 4:01 PM, William Herrin wrote: > On Thu, Apr 8, 2010 at 3:49 PM, John Payne wrote: >> So again, why do WE have to encourage YOU to adopt IPv6? >> Why should WE care what you do to the point of creating >> new rules so YOU don't have to pay like everyone else? > > Because when WE haven't deployed IPv6 yet and YOU have trouble finding > a free IPv4 address for your new server, it'll be YOUR problem too. Sure... if I'm in the minority. If/when I'm not, it's then more your problem than mine :) From bill at herrin.us Thu Apr 8 15:33:11 2010 From: bill at herrin.us (William Herrin) Date: Thu, 8 Apr 2010 16:33:11 -0400 Subject: Behold - the Address-Yenta! In-Reply-To: <20100408193932.GA10217@vacation.karoshi.com.> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <4BBE118C.6070602@sprunk.org> <20100408183757.GA9681@vacation.karoshi.com.> <20100408193932.GA10217@vacation.karoshi.com.> Message-ID: On Thu, Apr 8, 2010 at 3:39 PM, wrote: > ? ? ? ?er... you misunderstand... there is no single "DFZ" anywhere... > ? ? ? ?it is a fiction. Meh. Fiction or no, it does a suitably effective job connecting my users to my servers when and where they want to connect. > ? ? ? ?last ebay transaction I saw was a posting by Martin Levy - and it was > ? ? ? ?withdrawn after some urging by ARIN. Section 8.3 is new. Just happened last year. > Addresses are not sellable > ? ? ?property. ?So what would an "open market" be in... rights to use? > ? ? ? ?(come to think of it, I have seen submarine cable IRUs for sale on eBAY) The market would be for contracts to release particular blocks of addresses to ARIN for re-registration to the buyer under the terms of ARIN NRPM section 8.3. The legal fiction is that you're buying the contract, not the addresses. As for whether IP addresses will ever be sellable property... I think it serves to recall that native Americans had no concept of real estate when the Europeans first arrived. They fought the notion hard once they finally realized the settlers were serious about it. > ? ? ? ?Ok... lets say there is a pent up supply ... ?and no good way to > ? ? ? ?let those with demand know the supply exists. ? I'll consider > ? ? ? ?acting as the "address Yenta" ? --- ? if folks have prefixes they > ? ? ? ?are not using, and would like to let others know there is availablity, > ? ? ? ?I'll be glad to be the "go between". Works for me. Maybe I'll drop you a line when the IANA pool finally exhausts. I have some nice real estate down in the swamp that I'm using for relatively low-value applications... > ? ? ? ?I remember this. ?it suffers from two primary weaknesses: > ? ? ? ?) finding someone (see my address-Yenta offer above) With you volunteering, that problem is solved. See? Easy! > ? ? ? ?) this only works within the ARIN region. The other regions have their own structures... NIRs and LIRs that aren't tied to ISP service and whose practices differ from the RIR, for example. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From raymond at prolocation.net Thu Apr 8 15:33:35 2010 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Thu, 8 Apr 2010 22:33:35 +0200 (CEST) Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <4BBE3B2A.7070901@west.net> References: <4BBE3B2A.7070901@west.net> Message-ID: Hi! > We just got Cyclops alerts showing several of our prefixes sourced from > AS23474 propagating through AS4134. Anyone else? > > aut-num: AS23724 > as-name: CHINANET-IDC-BJ-AP > descr: IDC, China Telecommunications Corporation > country: CN > > aut-num: AS4134 > as-name: CHINANET-BACKBONE > descr: No.31,Jin-rong Street > descr: Beijing > descr: 100032 > country: CN More alerts from : 88.159.0.0/16 being advertised with aspath 286 4134 23724 23724. route: 88.159.0.0/16 descr: Edutel Network origin: AS39309 mnt-by: MNT-EDUTEL source: RIPE # Filtered Cant someone properlyu filter the crap inside Chinanet? This is silly. Bye, Raymond. From john at sackheads.org Thu Apr 8 15:35:19 2010 From: john at sackheads.org (John Payne) Date: Thu, 8 Apr 2010 16:35:19 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004082014.o38KE3WM051378@aurora.sol.net> References: <201004082014.o38KE3WM051378@aurora.sol.net> Message-ID: On Apr 8, 2010, at 4:14 PM, Joe Greco wrote: >> On Apr 8, 2010, at 11:36 AM, Joe Greco wrote: >> >>> IPv6-only content won't be meaningful for years yet, and IPv6-only >>> eyeballs will necessarily be given ways to reach v4 for many years >>> to come. >> >> So again, why do WE have to encourage YOU to adopt IPv6? >> Why should WE care what you do to the point of creating new rules so YOU don't have to pay like everyone else? > > Flip it around: Why should WE care about IPv6? WE would have to sign > an onerous RSA with ARIN, giving up some of our rights in the process. > WE have sufficient IP space to sit it out awhile; by doing that, WE > save cash in a tight economy. WE are not so large that we spend four > figures without batting an eyelash, so that's attractive. So don't. If your business plan doesn't involve paying to adopt IPv6, don't adopt it. > > Further, anyone who is providing IPv6-only content has cut off most of > the Internet, so basically no significant content is available on IPv6- > only. That means there is no motivation for US to jump on the IPv6 > bandwagon. If you have no motivation, don't jump. You have enough IPv4 space to not worry about not being able to get more. Don't create work for yourself that you don't need to. > > Even more, anyone who is on an IPv6-only eyeball network is cut off from > most of the content of the Internet; this means that ISP's will be having > to provide IPv6-to-v4 services. Either they'll be good, or if customers > complain, WE will be telling them how badly their ISP sucks. Yep, and their ISP will be telling them how you suck because you haven't moved with the rest of the world to suppoorting IPv6 (whether or not that's true... same as whether or not their ISP sucks is true). > *I* am personally convinced that IPv6 is great, but on the other hand, > I do not see so much value in v6 that I am prepared to compel the > budgeting for ARIN v6 fees, especially since someone from ARIN just > described all the ways in which they fritter away money. Well, if you join ARIN you could propose policy to get you IPv6 space for free, so you can continue to not support the registration services you implicitly rely on. Just sayin'. > As a result, the state of affairs simply retards the uptake and adoption > of v6 among networks that would otherwise be agreeable to the idea; so, > tell me, do you see that as being beneficial to the Internet community > at large, or not? If you have content or eyeballs that are important to me, I will find a way of getting to you. If you don't, I don't care. > > Note that I'm taking a strongly opposing stance for the sake of debate, > the reality is a bit softer. Given a moderately good offer, we'd almost > certainly adopt IPv6. If you gave me salad for free, I'd almost certainly eat healthier. From jgreco at ns.sol.net Thu Apr 8 15:35:19 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 8 Apr 2010 15:35:19 -0500 (CDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4BBE3676.5010203@steadfast.net> from "Kevin Stange" at Apr 08, 2010 03:03:02 PM Message-ID: <201004082035.o38KZJPJ052110@aurora.sol.net> > On 04/08/2010 02:17 PM, Joe Greco wrote: > >> If we just eliminated the RIRs and agreements governing terms of acces= > s > >> to v6 allocations, IF later, we find a problem with the process and > >> start to run out of space, we end up in the same situation. Suddenly = > we > >> have to form these organizations again, and institute new allocation > >> policies for new allocations, but again lack any recourse for all thos= > e > >> people that "greedily" ate up as much space as they could. > >=20 > > Then guard against _that_, which is a real problem. > > That /is/ the RIRs' function now. ARIN policy is not immutable. > Proposals to change it are welcomed. I see no reason that we have to > throw ARIN out of this picture in order to solve your perceived problem > of too much regulation and overhead. The problem, as I've heard it, is that ARIN's fees are steep in order to pay for various costs. Since there isn't the economy of scale of hundreds of millions of domain names, and instead you just have ... what? Probably less than a hundred thousand objects that are revenue-generating? If you charge $1/yr for each registered object, that means your organizational budget is sufficient for one full time person, maybe two. At $100/yr, you have enough funding for some office space, some gear, and a small staff. So when you run into expensive stuff, like litigation, the best course of action is to avoid it unless you absolutely can't. Further, if you've suffered mission creep and are funding other things such as IPv6 educational outreach, that's going to run up your costs as well. An established entity like ARIN typically has a very rough time going on any sort of diet. Further, companies typically do not segregate their "products" well: if IPv4 policy enforcement runs into legal wrangling and lawsuits, ARIN as a whole gets sued, and it is tempting to spread the resulting expenses over all their products. Segregation into two (or more!) entities is a trivial way to fix that, though it also brings about other challenges. > >> I think there's a continued need to keep an organization in charge of > >> accounting for the space to whom we as resource holders are accountabl= > e > >> and whom is also accountable to us. Later on, when we realize we've > >> gone wrong somewhere (and it will happen) and need to make changes to > >> policy, there is a process by which we can do it where all the parties= > > >> involved already have an established relationship. > >=20 > > That sets off my radar detector a bit. If you're justifying the need=20 > > for current policies with that statement, I'd have to disagree... the > > desire to potentially make changes in the future is not itself a=20 > > compelling reason to have strongly worded agreements. Even in v4land, > > we've actually determined that one of the few relatively serious=20 > > reasons we'd like to reclaim space (depletion) is probably impractical.= > > >=20 > > With that in mind, claims that there needs to be thorough accounting > > kind of comes off like "trust us, we're in charge, we know what we need= > > > but we can't really explain it aside from invoking the boogeyman." > > ARIN doesn't so simply say "trust us, we're in charge." Every dealing > I've ever had with the organization has encouraged me to participate in > the policy making process in some regard. Ideally policy should > appropriately reflect how the regional users of IP resources feel things > should be managed and hand down terms for allocation to match. > > The intention is for the accountability to go in both directions, from > resource holders to the RIR and from the RIR to the community. If you > don't think that's working for ARIN, I'm sure ARIN can be fixed. I have my doubts, based on a ~decade of observation. I don't think ARIN is deliberately evil, but I think there are some bits that'd be hard to fix. ... 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 bruns at 2mbit.com Thu Apr 8 15:36:19 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 08 Apr 2010 14:36:19 -0600 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <4BBE3B2A.7070901@west.net> References: <4BBE3B2A.7070901@west.net> Message-ID: <4BBE3E43.2050407@2mbit.com> On 4/8/10 2:23 PM, Jay Hennigan wrote: > We just got Cyclops alerts showing several of our prefixes sourced from > AS23474 propagating through AS4134. Anyone else? > > aut-num: AS23724 > as-name: CHINANET-IDC-BJ-AP > descr: IDC, China Telecommunications Corporation > country: CN > > aut-num: AS4134 > as-name: CHINANET-BACKBONE > descr: No.31,Jin-rong Street > descr: Beijing > descr: 100032 > country: CN > > -- > 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 > I'm starting to wonder if someone is 'testing the waters' in China to see what they can get away with. I hate to be like this, but there's a reason why I have all of China filtered on my routers. Amazing how much SSH hammering, spam, and other nastiness went away within minutes of the filtering going in place. There comes a point where 'accidental' and 'isolated incident' become "we no care" and "spam not illegal". And no, i'm not quoting that to mock, but rather repeat exactly what admins in China send to me in response to abuse reports and blocking in the AHBL. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From Valdis.Kletnieks at vt.edu Thu Apr 8 15:36:36 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 08 Apr 2010 16:36:36 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: Your message of "Thu, 08 Apr 2010 16:01:55 EDT." References: <201004081536.o38FaMKQ025021@aurora.sol.net> Message-ID: <4247.1270758996@localhost> On Thu, 08 Apr 2010 16:01:55 EDT, William Herrin said: > On Thu, Apr 8, 2010 at 3:49 PM, John Payne wrote: > > So again, why do WE have to encourage YOU to adopt IPv6? > > Why should WE care what you do to the point of creating > > new rules so YOU don't have to pay like everyone else? > > Because when WE haven't deployed IPv6 yet and YOU have trouble finding > a free IPv4 address for your new server, it'll be YOUR problem too. No, because John will just deploy a IPv6-only server, and it will be *your* support desk catching the "why can't I reach John's service" calls. You *really* don't want to be the last guy to deploy IPv6 among your competitors. -------------- 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 Apr 8 15:44:09 2010 From: bill at herrin.us (William Herrin) Date: Thu, 8 Apr 2010 16:44:09 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <6C604EC4-ED91-46C7-91F1-87F3FB6E3B20@sackheads.org> References: <201004081536.o38FaMKQ025021@aurora.sol.net> <6C604EC4-ED91-46C7-91F1-87F3FB6E3B20@sackheads.org> Message-ID: On Thu, Apr 8, 2010 at 4:27 PM, John Payne wrote: > On Apr 8, 2010, at 4:01 PM, William Herrin wrote: >> Because when WE haven't deployed IPv6 yet and YOU have trouble finding >> a free IPv4 address for your new server, it'll be YOUR problem too. > > Sure... if I'm in the minority. ?If/when I'm not, it's then more your > problem than mine :) John, I think you'll find that the guy deploying the IPv6-only client -or- server is going to be in the minority for a long time to come. But if you want to bet against me, more power to you. 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 Apr 8 15:47:58 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 08 Apr 2010 16:47:58 -0400 Subject: RIRs are More Interested in Selling NEW than Pre-Owned? In-Reply-To: Your message of "Thu, 08 Apr 2010 14:32:44 CDT." References: Message-ID: <5403.1270759678@localhost> On Thu, 08 Apr 2010 14:32:44 CDT, "IPv3.com" said: > People seem to be happy with 34 bits, one extra bit at each end. 1+32+1 It's interesting to see that people can be this reality-challenged and still ruled competent to manage their own affairs. But I'll let the list admins make the call on 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 jay at west.net Thu Apr 8 15:49:08 2010 From: jay at west.net (Jay Hennigan) Date: Thu, 08 Apr 2010 13:49:08 -0700 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <4BBE3E43.2050407@2mbit.com> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> Message-ID: <4BBE4144.8020202@west.net> On 4/8/10 1:36 PM, Brielle Bruns wrote: > I'm starting to wonder if someone is 'testing the waters' in China to > see what they can get away with. I hate to be like this, but there's a > reason why I have all of China filtered on my routers. > > Amazing how much SSH hammering, spam, and other nastiness went away > within minutes of the filtering going in place. > > There comes a point where 'accidental' and 'isolated incident' become > "we no care" and "spam not illegal". And no, i'm not quoting that to > mock, but rather repeat exactly what admins in China send to me in > response to abuse reports and blocking in the AHBL. I think the folks at Google have been down the same path. -- 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 john at sackheads.org Thu Apr 8 15:51:09 2010 From: john at sackheads.org (John Payne) Date: Thu, 8 Apr 2010 16:51:09 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004081536.o38FaMKQ025021@aurora.sol.net> <6C604EC4-ED91-46C7-91F1-87F3FB6E3B20@sackheads.org> Message-ID: On Apr 8, 2010, at 4:44 PM, William Herrin wrote: > On Thu, Apr 8, 2010 at 4:27 PM, John Payne wrote: >> On Apr 8, 2010, at 4:01 PM, William Herrin wrote: >>> Because when WE haven't deployed IPv6 yet and YOU have trouble >>> finding >>> a free IPv4 address for your new server, it'll be YOUR problem too. >> >> Sure... if I'm in the minority. If/when I'm not, it's then more your >> problem than mine :) > > John, > > I think you'll find that the guy deploying the IPv6-only client -or- > server is going to be in the minority for a long time to come. But if > you want to bet against me, more power to you. I hope you're right, but you put up the scenario of me being unable to get a v4 address. I suspect I won't be the first there, and I hope that by the time that is an issue for me, I will be in the majority already :) From jul_bsd at yahoo.fr Thu Apr 8 15:57:31 2010 From: jul_bsd at yahoo.fr (jul) Date: Thu, 08 Apr 2010 22:57:31 +0200 Subject: China prefix hijack In-Reply-To: <4BBE0566.6080208@Janoszka.pl> References: <4BBE0566.6080208@Janoszka.pl> Message-ID: <4BBE433B.6030204@yahoo.fr> I also see some of this from France. On this incident/error, even if tools like BGPMon, watchmy.net and others exactly did their roles, I asking myself if there are some other public tools which can help. CIDR returns Chinanet as the biggest announcer (but could be the case previously) 97074688 Largest address span announced by an AS (/32s) AS4134: CHINANET-BACKBONE No.31,Jin-rong Street on http://www.cidr-report.org/as2.0/ Same stats from http://www.ris.ripe.net/dashboard/4134 I'm not sure either of them is real-time. There is also a "hole" in http://www.cymru.com/BGP/bgp_prefixes.html So, how each one has assess the impact of this on his network ? How could we check where route's propagation stop(ed) ? Thanks to Renesys and Team Cymru for the stats of how many prefixes/countries where affected. I hope most Tier1 operators have rules to filter too big announces changes to avoid the Youtube/Pakistan Telecom effect or i-root as said previously. thanks Best regards, Jul Grzegorz Janoszka wrote on 08/04/10 18:33: > > Just half an hour ago China Telecom hijacked one of our prefixes: > > Your prefix: X.Y.Z.0/19: > Prefix Description: NETNAME > Update time: 2010-04-08 15:58 (UTC) > Detected by #peers: 1 > Detected prefix: X.Y.Z.0/19 > Announced by: AS23724 (CHINANET-IDC-BJ-AP IDC, China > Telecommunications Corporation) > Upstream AS: AS4134 (CHINANET-BACKBONE No.31,Jin-rong Street) > ASpath: 39792 4134 23724 23724 > > Luckily it had to be limited as only one BGPmon peer saw it. Anyone else > noticed it? > From owen at delong.com Thu Apr 8 15:54:38 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 8 Apr 2010 13:54:38 -0700 Subject: "Running out of IPv6" (Re: ARIN IP6 policy for those with legacy IP4 Space) In-Reply-To: References: <000601cad73d$2cac32a0$860497e0$@org> <201004081826.o38IQpfJ038982@aurora.sol.net> <4BBE24CC.2050803@unfix.org> Message-ID: <601EE254-AB0B-4126-8B7E-162B844B03CE@delong.com> On Apr 8, 2010, at 12:10 PM, Chris Grundemann wrote: > On Thu, Apr 8, 2010 at 12:47, Jeroen Massar wrote: >> [changing topics, so that it actually reflects the content] >> >> On 2010-04-08 20:33, William Herrin wrote: >>> Yes, with suitably questionable delegations, it is possible to run out >>> of IPv6 quickly. > > The bottom line (IMHO) is that IPv6 is NOT infinite and propagating > that myth will lead to waste. That being said, the IPv6 space is MUCH > larger than IPv4. Somewhere between 16 million and 17 billion times > larger based on current standards by my math[1]. > Agreed >> Ever noticed that fat /13 for a certain military network in the ARIN >> region!? >> >> At least those /19 are justifyiable under the HD rules (XX million >> customers times a /48 and voila). A /13 though, very hard to justify... > > Not every customer needs a /48. In fact most probably don't. > Whether they need it or not, it is common allocation/assignment practice. I agree that smaller (SOHO, for example) customers should get a /56 by default and a /48 on request, but, this is by no means a universal truth of current practice. Owen From wavetossed at googlemail.com Thu Apr 8 16:03:38 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Thu, 8 Apr 2010 22:03:38 +0100 Subject: Likely /8 Scenario - Carriers will TAKE what they want ? In-Reply-To: References: Message-ID: and what makes you think that there is anyone looking after the mailing lists any more. There have been few network operational threads in recent months, and the Jim Fleming IPv3 bot is given free rein on the NANOG lists. Go look at the traffic for nanaog-futures this month. 100% of the postings are from Fleming. Soon he will be telling us about how IPv16 is one better than IPv6 or that the average domain name should only be four letters long. In fact, although the postings seem loony, I think they are really an attempt to drive traffic to his various sites in order to earn money from Google AdSense and similar schemes. On 8 April 2010 20:07, Jack Carrozzo wrote: > Might want to save the we're-all-going-to-die for nanog-lounge or > whatever was created and leave the more likely operational scenarios > here. > > Just sayin' > > -J > > On Thu, Apr 8, 2010 at 2:53 PM, IPv3.com wrote: >> Likely /8 Scenario - Carriers will TAKE what they want ? >> >> As /8s are needed by Carriers (not ISPs) they will likely be able to >> just take them. >> Who will stop them. They have the Imperial Walker Routers & Gear. >> >> http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt >> >> http://en.wikipedia.org/wiki/Walker_%28Star_Wars%29 >> >> > > From andree+nanog at toonk.nl Thu Apr 8 16:08:26 2010 From: andree+nanog at toonk.nl (Andree Toonk) Date: Thu, 08 Apr 2010 14:08:26 -0700 Subject: China prefix hijack In-Reply-To: <4BBE433B.6030204@yahoo.fr> References: <4BBE0566.6080208@Janoszka.pl> <4BBE433B.6030204@yahoo.fr> Message-ID: <4BBE45CA.9010007@toonk.nl> Hi Jul, list .-- My secret spy satellite informs me that at 08/04/10 1:57 PM jul wrote: > So, how each one has assess the impact of this on his network ? How > could we check where route's propagation stop(ed) ? > Thanks to Renesys and Team Cymru for the stats of how many > prefixes/countries where affected. Some additional information such as a list of all prefixes affected, geographical impact & some more information regarding this incident can be found here: http://bgpmon.net/blog/?p=282 Cheers, Andree From lists at internetpolicyagency.com Thu Apr 8 16:13:00 2010 From: lists at internetpolicyagency.com (Roland Perry) Date: Thu, 8 Apr 2010 22:13:00 +0100 Subject: what about 48 bits? In-Reply-To: <201004071118.o37BIvK1022393@aurora.sol.net> References: <201004071118.o37BIvK1022393@aurora.sol.net> Message-ID: In article <201004071118.o37BIvK1022393 at aurora.sol.net>, Joe Greco writes >Unfortunately, power-cycling crashed PC's is (was?) pretty common, and >many users are (were?) also trained to shut off PC's when done, so here >you've introduced something that is by-design going to fail periodically. OK, I agree that fitting a PC-powered hub into a client PC isn't the best decision in the world. But losing one segment of a 10Base-T LAN (which was the technology I used) is not the end of the world, and I took the precaution of installing the hub in my server. Despite these potential operational banana skins, it was still a product that tipped me irrevocably into the world of Ethernet (having earlier toyed with pale imitations). -- Roland Perry From bill at herrin.us Thu Apr 8 16:14:28 2010 From: bill at herrin.us (William Herrin) Date: Thu, 8 Apr 2010 17:14:28 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004081536.o38FaMKQ025021@aurora.sol.net> <6C604EC4-ED91-46C7-91F1-87F3FB6E3B20@sackheads.org> Message-ID: On Thu, Apr 8, 2010 at 4:51 PM, John Payne wrote: > On Apr 8, 2010, at 4:44 PM, William Herrin wrote: >> I think you'll find that the guy deploying the IPv6-only client -or- >> server is going to be in the minority for a long time to come. But if >> you want to bet against me, more power to you. > > I hope you're right, but you put up the scenario of me being unable to get a > v4 address. I suspect I won't be the first there, and I hope that by the > time that is an issue for me, I will be in the majority already :) John, You'll be able to get another v4 address. It'll cost you noticeably more than it does now, but you'll be able to afford it. Thing is, if you induce me and others to deploy IPv6 now, you may not have to get another v4 address then, nor pay for it. So if there's a way you can induce me to deploy IPv6 now that doesn't cost you any money now or later, well, that's ultimately money that stays in your pocket. Keeps money in my pocket too since I'll have the same problem, but what do you care about that? It's your money that matters, not mine. Inducing behavior that ultimately reduces everybody's cost "serves the public interest." That's what organizations like ARIN are for: serving the public interest. Regards, Bill -- 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 Thu Apr 8 16:17:31 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Thu, 8 Apr 2010 22:17:31 +0100 Subject: NANOG Seems to be Dominated by NON-North American People ? In-Reply-To: References: Message-ID: > NANOG Seems to be Dominated by NON-North American People ? > ...odd When was the last time that you attended a NANOG meeting? When was the last time that you read the NANOG charter, in particular this line: The purpose of NANOG is to provide forums in the North American region for education and the sharing of knowledge for the Internet operations community. Last time I looked, the Internet was very international so it should be no surprise that the Internet operations community is also very international. > ARIN seems to have a similar situation > ...odd That is an outright lie. The ARIN members, the ARIN meeting participants and the ARIN mailing list participants are all overwhelmingly North American. > This could be a Great Time to Start an ISP in .USA - Plenty of IPv4+ > Address Space. > ...and fools are wasting their time and money on IPv6 I agree. If you want a solid investment, I recently acquired the Brooklyn Bridge in New York. If you are interested in making a serious proposal I would be willing to sell it to you. The income from tolls is quite high over the long term, but I'm afraid that I'm not able to properly manage it being so far from New York at present. This is an open offer. If anyone else on the list is interested in buying the bridge, I will entertain any offers. --Michael Dillon :-J From lists at internetpolicyagency.com Thu Apr 8 16:20:08 2010 From: lists at internetpolicyagency.com (Roland Perry) Date: Thu, 8 Apr 2010 22:20:08 +0100 Subject: Hubs on a NIC (was:Re: what about 48 bits?) In-Reply-To: References: <201004071503.o37F3HPI030585@aurora.sol.net> Message-ID: In article , Steven Bellovin writes >> Remember, it was this strange time when people were uncertain about how >> networks were going to evolve, and what the next thing would be, and >> even then, 10baseT was being deployed over Cat3 (sometimes recycled/ >> repurposed), so any sort of "enabling" gadget such as these cards had a >> tendency to be abused in various ways. > >Right -- the wire and pin assignments for 10BaseT and 100BaseT were >designed to permit sharing the cable between Ethernet and phone. I wired a new-build house (of mine) like that in 1995. The CAT5 cable was expensive enough that it made sense to share. And it worked. The bigger challenge was getting Internet to the house, not round the house. Ten years later, both voice and data would probably have been better done by wireless (DECT and wifi respectively). -- Roland Perry From john at sackheads.org Thu Apr 8 16:26:26 2010 From: john at sackheads.org (John Payne) Date: Thu, 8 Apr 2010 17:26:26 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004081536.o38FaMKQ025021@aurora.sol.net> <6C604EC4-ED91-46C7-91F1-87F3FB6E3B20@sackheads.org> Message-ID: On Apr 8, 2010, at 5:14 PM, William Herrin wrote: > On Thu, Apr 8, 2010 at 4:51 PM, John Payne wrote: >> On Apr 8, 2010, at 4:44 PM, William Herrin wrote: >>> I think you'll find that the guy deploying the IPv6-only client -or- >>> server is going to be in the minority for a long time to come. But if >>> you want to bet against me, more power to you. >> >> I hope you're right, but you put up the scenario of me being unable to get a >> v4 address. I suspect I won't be the first there, and I hope that by the >> time that is an issue for me, I will be in the majority already :) > > John, > > You'll be able to get another v4 address. It'll cost you noticeably > more than it does now, but you'll be able to afford it. Thing is, if > you induce me and others to deploy IPv6 now, you may not have to get > another v4 address then, nor pay for it. So if there's a way you can > induce me to deploy IPv6 now that doesn't cost you any money now or > later, well, that's ultimately money that stays in your pocket. a) if I don't have to get an IPv4 address then Ill be standing up a v6 only server, by which time, again, I hope to be in the majority :) b) ARIN or RIRv6 has costs that are covered by registration fees. How does having a whole bunch of freeloaders save me money? Doesn't it increase my share of the costs? Doesn't giving you free IPv6 now continue my costs into perpetuity whereas just ignoring you may add some operational cost until you're either in an insignificant percentage or you give up and start playing by the same rules as everyone else? > > Keeps money in my pocket too since I'll have the same problem, but > what do you care about that? It's your money that matters, not mine. > > Inducing behavior that ultimately reduces everybody's cost "serves the > public interest." That's what organizations like ARIN are for: serving > the public interest. But I don't agree that giving you a free ride reduces everyone's costs. In fact, I think it increases everyone else's costs. This comes on top of my annual reading of the distribution of the US tax burden.... there are some parallels to be drawn in terms of fairness. From wavetossed at googlemail.com Thu Apr 8 16:32:37 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Thu, 8 Apr 2010 22:32:37 +0100 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004081536.o38FaMKQ025021@aurora.sol.net> References: <201004081536.o38FaMKQ025021@aurora.sol.net> Message-ID: > 1) Justify why we need a heavy bureaucracy such as ARIN for IPv6 > ? numbering resources, Because the members of ARIN (and the other four RIRs) want it that way. And because nobody has yet made a serious proposal to ICANN that would replace ARIN. > 2) Tell me why something like the old pre-depletion pre-ARIN model > ? of InterNIC and just handing out prefixes with substantially less > ? paper-pushing wouldn't result in a cheaper-to-run RIR. Because the ARIN members, who pay most of ARIN's fees, are not complaining about the level of those fees. This means that they think the fees are cheap enough, or else they would demand that the fees be changed. All ARIN fees are set by the ARIN members. --Michael Dillon P.S. When you send your proposal to ICANN, please post a notice here on the NANOG list so that we can all go have a look at it. From owen at delong.com Thu Apr 8 16:38:15 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 8 Apr 2010 14:38:15 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004082014.o38KE3WM051378@aurora.sol.net> Message-ID: <7E2D995F-80BB-46E3-8B8F-E155C83066FF@delong.com> > >> *I* am personally convinced that IPv6 is great, but on the other hand, >> I do not see so much value in v6 that I am prepared to compel the >> budgeting for ARIN v6 fees, especially since someone from ARIN just >> described all the ways in which they fritter away money. > > Well, if you join ARIN you could propose policy to get you IPv6 space for free, so you can continue to not support the registration services you implicitly rely on. > Just sayin'. Clarification required here: You do not have to join ARIN to propose policy. Fees are not policy. You do not have to join ARIN to propose changes to fees through the ACSP. You do have to join ARIN to vote in AC and BoT elections. Owen From wavetossed at googlemail.com Thu Apr 8 16:41:07 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Thu, 8 Apr 2010 22:41:07 +0100 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <000601cad73d$2cac32a0$860497e0$@org> <201004081826.o38IQpfJ038982@aurora.sol.net> Message-ID: > You're aware that RIPE has already made some /19 and /20 IPv6 allocations? 10 years ago ARIN rarely allocated less than a /19 or a /20 in IPv4. And we are still breathing today. > Yes, with suitably questionable delegations, it is possible to run out > of IPv6 quickly. Fortunately, there haven't been any questionable IPv6 delegations noticed anywhere yet. --Michael Dillon P.S. A block of /19 in IPv4 is the same percentage of the total IPV4 address space as a block of /19 in IPv6 is of the total IPv6 address space. From owen at delong.com Thu Apr 8 16:40:58 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 8 Apr 2010 14:40:58 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004082035.o38KZJPJ052110@aurora.sol.net> References: <201004082035.o38KZJPJ052110@aurora.sol.net> Message-ID: <8889118F-25DC-42FE-9057-AD5FF1463F43@delong.com> > > I have my doubts, based on a ~decade of observation. I don't think ARIN > is deliberately evil, but I think there are some bits that'd be hard to > fix. > I believe that anything at ARIN which the community at large and the membership can come to consensus is broken will be relatively easy to fix. Perhaps the true issue is that what you see as broken is perceived as "working as intended" by much of the community and membership? Owen From bill at herrin.us Thu Apr 8 16:47:14 2010 From: bill at herrin.us (William Herrin) Date: Thu, 8 Apr 2010 17:47:14 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004081536.o38FaMKQ025021@aurora.sol.net> <6C604EC4-ED91-46C7-91F1-87F3FB6E3B20@sackheads.org> Message-ID: On Thu, Apr 8, 2010 at 5:26 PM, John Payne wrote: > b) ARIN or RIRv6 has costs that are covered by registration fees. > ?How does having a whole bunch of freeloaders save me money? 'Cause if you're clever about it, they're not freeloaders forever... they only get to be freeloaders until, as you so succinctly put it, their presence pushes you into the majority that finds it acceptable to deploy IPv6-only servers. What I might do, and I'm just talking here, but what I might do in ARIN's shoes is preemptively allocate /32s or assign /48s to ARIN orgs whose ASes currently announce only IPv4 prefixes. The deal is: everybody gets em, no assignment fee or evaluation beyond the fact that you're announcing IPv4 now, free for two years after which you either sign the contract and start paying the annual, or you don't and the address block is reclaimed by ARIN. Gives me a $1250 incentive to deploy IPv6 now instead of waiting, and costs you nothing now since I wouldn't have spent the $1250 now anyway. Probably costs you nothing later too, because after two years I'll be paying annuals that I might not otherwise have had to pay -and- since my assignment was done in bulk, ARIN staff will never spend the time (time=money) individually processing my initial assignment. >> Inducing behavior that ultimately reduces everybody's cost "serves the >> public interest." That's what organizations like ARIN are for: serving >> the public interest. > > But I don't agree that giving you a free ride reduces everyone's >costs. ?In fact, I think it increases everyone else's costs. Fair enough. I won't begrudge you the choice. Just remember years from now when you cough up the cash for that extra v4 address: you had another option. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From patrick at ianai.net Thu Apr 8 16:49:41 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 8 Apr 2010 17:49:41 -0400 Subject: Cheers to the Communication Committee [was: Likely /8 Scenario - Carriers will TAKE what they want ?] In-Reply-To: References: Message-ID: <8F349E33-B6CB-4DD5-9090-0F07869B08C0@ianai.net> On Apr 8, 2010, at 5:03 PM, Michael Dillon wrote: > and what makes you think that there is anyone looking after the > mailing lists any more. There have been few network operational > threads in recent months, and the Jim Fleming IPv3 bot is given free > rein on the NANOG lists. [snip] I guarantee you the Communications Committee is on the job. What's more, they are doing a GREAT job - for no money and apparently no gratitude. It is worse than thankless, no matter what they do they will be derided. Filter someone and they get flamed. Leave someone allowed to post and they get reamed. I'm shocked anyone would actually want the job. So, I propose a new rule: To flame the CC, you MUST have volunteered to be on the CC. IOW: Put up or shut up. Since I have not volunteered to be on the CC, and would not serve if asked, I will only thank them profusely and beg them not to give up amid the criticism they constantly receive. Thank you Communications Committee Members! -- TTFN, patrick From jay at west.net Thu Apr 8 16:53:43 2010 From: jay at west.net (Jay Hennigan) Date: Thu, 08 Apr 2010 14:53:43 -0700 Subject: Finding content in your job title In-Reply-To: <4BB2C0D9.4020607@ibctech.ca> References: <4BB2BE2C.9000901@ibctech.ca> <4BB2C0D9.4020607@ibctech.ca> Message-ID: <4BBE5067.1060002@west.net> On 3/30/10 8:26 PM, Steve Bertrand wrote: > I'd put 'janitor' on my business card for all I really care. Or on your T-shirt? Like the ones from NANOG 42 that read "Custodians of the Internet"? -- 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 jwbensley at gmail.com Thu Apr 8 17:03:26 2010 From: jwbensley at gmail.com (James Bensley) Date: Thu, 8 Apr 2010 23:03:26 +0100 Subject: NANOG Seems to be Dominated by NON-North American People ? In-Reply-To: References: Message-ID: I got $5, litterally. Will that Do? Otherwise, > ...and fools are wasting their time and money on IPv6 No offence chap its to late to be saying that. IPv6 is where we are all going, some are already there. You are going to have to embrace it sooner or later or suffer the wrath of unsupported technologies which as we all know, is hideous! -- Regards, James. http://www.jamesbensley.co.cc/ From john at sackheads.org Thu Apr 8 17:05:52 2010 From: john at sackheads.org (John Payne) Date: Thu, 8 Apr 2010 18:05:52 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <7E2D995F-80BB-46E3-8B8F-E155C83066FF@delong.com> References: <201004082014.o38KE3WM051378@aurora.sol.net> <7E2D995F-80BB-46E3-8B8F-E155C83066FF@delong.com> Message-ID: <41B2ABF3-297B-4CA6-AA49-F969E5B9A2A5@sackheads.org> On Apr 8, 2010, at 5:38 PM, Owen DeLong wrote: >> >>> *I* am personally convinced that IPv6 is great, but on the other >>> hand, >>> I do not see so much value in v6 that I am prepared to compel the >>> budgeting for ARIN v6 fees, especially since someone from ARIN just >>> described all the ways in which they fritter away money. >> >> Well, if you join ARIN you could propose policy to get you IPv6 >> space for free, so you can continue to not support the registration >> services you implicitly rely on. >> Just sayin'. > > Clarification required here: > > You do not have to join ARIN to propose policy. > > Fees are not policy. > > You do not have to join ARIN to propose changes to fees through the > ACSP. > > You do have to join ARIN to vote in AC and BoT elections. Thanks Owen.. I was taking member driven literally :) From franck at genius.com Thu Apr 8 17:09:31 2010 From: franck at genius.com (Franck Martin) Date: Fri, 9 Apr 2010 10:09:31 +1200 (MAGST) Subject: NANOG Seems to be Dominated by NON-North American People ? In-Reply-To: Message-ID: <29128598.29.1270764568589.JavaMail.franck@franck-martins-macbook-pro.local> ----- "James Bensley" wrote: > > > ...and fools are wasting their time and money on IPv6 > > No offence chap its to late to be saying that. IPv6 is where we are > all going, some are already there. You are going to have to embrace > it > sooner or later or suffer the wrath of unsupported technologies which > as we all know, is hideous! > And if you are in the valley check that: http://www.sfbayisoc.org/IPv6Panel2010 From wavetossed at googlemail.com Thu Apr 8 17:39:45 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Thu, 8 Apr 2010 23:39:45 +0100 Subject: Cheers to the Communication Committee [was: Likely /8 Scenario - Carriers will TAKE what they want ?] In-Reply-To: <8F349E33-B6CB-4DD5-9090-0F07869B08C0@ianai.net> References: <8F349E33-B6CB-4DD5-9090-0F07869B08C0@ianai.net> Message-ID: > I guarantee you the Communications Committee is on the job. ?What's more, they are doing a GREAT job - for no money and apparently no gratitude. ?It is worse than thankless, no matter what they do they will be derided. ?Filter someone and they get flamed. ?Leave someone allowed to post and they get reamed. ?I'm shocked anyone would actually want the job. So why can't the Communications Committee do a little communicating. Sure it's thankless work if you do it in secret and in silence. But the occasional message to the list wouldn't hurt. People WOULD feel thankful if they see that the CC is making an attempt. > So, I propose a new rule: To flame the CC, you MUST have volunteered to be on the CC. Right, so you are an unvolunteer on the CC. Why do we only hear from unvolunteers? --Michael Dillon From smb at cs.columbia.edu Thu Apr 8 17:42:37 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 8 Apr 2010 18:42:37 -0400 Subject: Cheers to the Communication Committee [was: Likely /8 Scenario - Carriers will TAKE what they want ?] In-Reply-To: References: <8F349E33-B6CB-4DD5-9090-0F07869B08C0@ianai.net> Message-ID: <7F754E1C-36B5-46A2-ABCD-FBAC81A53EB1@cs.columbia.edu> On Apr 8, 2010, at 6:39 45PM, Michael Dillon wrote: >> I guarantee you the Communications Committee is on the job. What's more, they are doing a GREAT job - for no money and apparently no gratitude. It is worse than thankless, no matter what they do they will be derided. Filter someone and they get flamed. Leave someone allowed to post and they get reamed. I'm shocked anyone would actually want the job. > > So why can't the Communications Committee do a little communicating. > Sure it's thankless work if you do it in secret and in silence. But > the occasional message to the list wouldn't hurt. People WOULD feel > thankful if they see that the CC is making an attempt. > >> So, I propose a new rule: To flame the CC, you MUST have volunteered to be on the CC. > > Right, so you are an unvolunteer on the CC. Why do we only hear from > unvolunteers? > There are some benefits to them not acting too quickly -- I finally had enough motivation to figure out what the bugs were in my "plonk" script... --Steve Bellovin, http://www.cs.columbia.edu/~smb From jcurran at arin.net Thu Apr 8 17:46:34 2010 From: jcurran at arin.net (John Curran) Date: Thu, 8 Apr 2010 18:46:34 -0400 Subject: Behold - the Address-Yenta! In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <4BBE118C.6070602@sprunk.org> <20100408183757.GA9681@vacation.karoshi.com> <20100408193932.GA10217@vacation.karoshi.com> Message-ID: <98D4754C-9F6F-4C12-8849-F0747C5E9136@arin.net> On Apr 8, 2010, at 3:51 PM, David Conrad wrote: > Sure they are. I personally know of several cases where addresses have been sold. Right now, people have to go through a bunch of foo, creating dummy companies to hold the IP address assets, transferring the assets, selling the dummy companies, etc., but the end result is the same. David - Please report these events to: : "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." We do investigate, and if we can determine falsified information was used to effect a transfer, we will revert the transfer and/or initiate resource review as appropriate. /John John Curran President and CEO ARIN From patrick at ianai.net Thu Apr 8 17:49:46 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 8 Apr 2010 18:49:46 -0400 Subject: Cheers to the Communication Committee [was: Likely /8 Scenario - Carriers will TAKE what they want ?] In-Reply-To: References: <8F349E33-B6CB-4DD5-9090-0F07869B08C0@ianai.net> Message-ID: <5AE1A14A-9400-4E19-AB58-1C8AA4FC7C4D@ianai.net> [Reply-to set.] On Apr 8, 2010, at 6:39 PM, Michael Dillon wrote: >> I guarantee you the Communications Committee is on the job. What's more, they are doing a GREAT job - for no money and apparently no gratitude. It is worse than thankless, no matter what they do they will be derided. Filter someone and they get flamed. Leave someone allowed to post and they get reamed. I'm shocked anyone would actually want the job. > > So why can't the Communications Committee do a little communicating. What would you have them say? I am not at all certain commenting publicly on individual posters is a good idea. So should they say "yeah, we've read the blather too, and we're .. uh .. " what? Also, the CC is required to at least skim every post. So believe me, they know what is happening - more than most since they can't plonk the k00ks. Oh, and feeding the trolls only makes their job harder. Perhaps you could pitch in by resisting temptation? Perhaps ALL of you could pitch in? :) -- TTFN, patrick From dwhite at olp.net Thu Apr 8 18:05:09 2010 From: dwhite at olp.net (Dan White) Date: Thu, 8 Apr 2010 18:05:09 -0500 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <20100408180001.GH3358@vacation.karoshi.com.> References: <201004081536.o38FaMKQ025021@aurora.sol.net> <250CFBF9-844D-4057-B769-7B87941AF910@delong.com> <20100408171740.GE3358@vacation.karoshi.com.> <20100408175026.GE4808@dan.olp.net> <20100408180001.GH3358@vacation.karoshi.com.> Message-ID: <20100408230509.GC4818@dan.olp.net> On 08/04/10?18:00?+0000, bmanning at vacation.karoshi.com wrote: >On Thu, Apr 08, 2010 at 12:50:26PM -0500, Dan White wrote: >> On 08/04/10 17:17 +0000, bmanning at vacation.karoshi.com wrote: >> > in the IPv4 space, it was common to have a min allocation size of >> > a /20 ... or 4,096 addresses ... and yet this amnt of space was >> > allocated to someone who only needed to address "3 servers"... say >> > six total out of a pool of four thousand ninty six. >> >> Granted, that may have been the case many years ago. >> >> However, this was not our experience when we obtained addresses, and the >> ARIN rules as I understand them would not allow such an allocation today. > > i picked a fairly recent example - the min allocation > size has fluctuated over time. still it is not the case > that most folks will get -exactly- what they need - they > will - in nearly every case - get more address space than > they need - due to the min allocation rules We did, on our first allocation. We were well over 90% utilization and when we asked our upstream ISP for more addresses, we were informed they would not provide us a 17th /24. We scrambled to get our documentation together for ARIN. We had to show efficient use of those 16 /24s, and we had to document our immediate (12-24 month) need for addresses to get them. >> > Thats a huge amnt of wasted space. If our wise and pragmatic leaders >> > (drc, jc, et.al.) are correct, then IPv4 will be around for a very >> > long time. >> > >> > What, if any, plan exists to improve the utilization density of the >> > existant IPv4 pool? >> >> I believe your question is based on an outdated assumption. > > and that outdated assumption is? The assumption that ARIN allocations are based on anything other than 12-24 month need (with only a few exceptions). If there are a significant number of sparse allocations of IPv4 blocks in ARIN, then that's a good indication that allocation rules need to be updated. -- Dan White From mksmith at adhost.com Thu Apr 8 18:07:16 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 8 Apr 2010 16:07:16 -0700 Subject: Cheers to the Communication Committee [was: Likely /8 Scenario - Carriers will TAKE what they want ?] In-Reply-To: References: <8F349E33-B6CB-4DD5-9090-0F07869B08C0@ianai.net> Message-ID: <17838240D9A5544AAA5FF95F8D52031607D2C922@ad-exh01.adhost.lan> > -----Original Message----- > From: Michael Dillon [mailto:wavetossed at googlemail.com] > Sent: Thursday, April 08, 2010 3:40 PM > To: NANOG list > Subject: Re: Cheers to the Communication Committee [was: Likely /8 > Scenario - Carriers will TAKE what they want ?] > > > I guarantee you the Communications Committee is on the job. ?What's > more, they are doing a GREAT job - for no money and apparently no > gratitude. ?It is worse than thankless, no matter what they do they > will be derided. ?Filter someone and they get flamed. ?Leave someone > allowed to post and they get reamed. ?I'm shocked anyone would actually > want the job. > > So why can't the Communications Committee do a little communicating. > Sure it's thankless work if you do it in secret and in silence. But > the occasional message to the list wouldn't hurt. People WOULD feel > thankful if they see that the CC is making an attempt. > > > So, I propose a new rule: To flame the CC, you MUST have volunteered > to be on the CC. > > Right, so you are an unvolunteer on the CC. Why do we only hear from > unvolunteers? > Hello: The Communications Committee follows a published procedure for handling violations of the AUP, found at http://www.nanog.org/governance/communications/warningpolicy.php. The process is not instantaneous, but is designed to insure we are not acting with undue haste when taking action against a particular list participant. We are always open to suggestions and comments regarding the process and the best forum for that is nanog-futures. This is also an appropriate venue for discussing the idea of more formal and/or frequent notifications from the Communications Committee regarding actions we have taken. Kind Regards, Michael Smith On behalf of the Communications Committee From gem at rellim.com Thu Apr 8 18:18:07 2010 From: gem at rellim.com (Gary E. Miller) Date: Thu, 8 Apr 2010 16:18:07 -0700 (PDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <22087.1270676886@localhost> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo Owen! Since I just need one /64 that is $1,250/yr for the /64. That puts me at a large competitive disadvantage to the big boys. RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 On Thu, 8 Apr 2010, Owen DeLong wrote: > This assumes that small = /40 and large = /22. > > Still, with more realistic numbers: > > The small guy (/48) pays $0.019073486 per /64 > The large guy (/24) pays $0.000000032741808 per /64 > > FWIW. > > Owen > > On Apr 7, 2010, at 2:48 PM, Valdis.Kletnieks at vt.edu wrote: > > > On Wed, 07 Apr 2010 14:17:49 PDT, "Gary E. Miller" said: > > > >> Then scroll down to the fees you can expect in 2013. Especially note > >> how the small guys get hit much harder per IP. > > > > The small guys pay: $0.000074505805969 per /64. ($1250 / (2^(64-40)) > > The big guys pay: $0.000000008185452 per /64. ($36000 / (2^(64-22)) > > > > The small guys are still paying less than 1/100th of a penny per /64. Assuming > > your salary plus overhead is $40/hour, each *second* of your time is worth > > more than the cost of 150 /64s. > > > > Oh, the inhumanity. > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFLvmQxBmnRqz71OvMRAr2dAKC4BrqBI94hvvyKEa+mLh4oML7yVwCfScFR 60z+bDBMHOvTRQwQJPW6SCo= =9zBu -----END PGP SIGNATURE----- From owen at delong.com Thu Apr 8 18:25:42 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 8 Apr 2010 16:25:42 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <22087.1270676886@localhost> Message-ID: You are mistaken. If you only need one /64, you cannot possibly be an IPv6 ISP. As such, you would only pay the end-user price of $1250 one-time and $100/year. That $100/year also covers your IPv4 space and your autonomous system number. Owen On Apr 8, 2010, at 4:18 PM, Gary E. Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Yo Owen! > > Since I just need one /64 that is $1,250/yr for the /64. > > That puts me at a large competitive disadvantage to the big boys. > > RGDS > GARY > - --------------------------------------------------------------------------- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 > gem at rellim.com Tel:+1(541)382-8588 > > On Thu, 8 Apr 2010, Owen DeLong wrote: > >> This assumes that small = /40 and large = /22. >> >> Still, with more realistic numbers: >> >> The small guy (/48) pays $0.019073486 per /64 >> The large guy (/24) pays $0.000000032741808 per /64 >> >> FWIW. >> >> Owen >> >> On Apr 7, 2010, at 2:48 PM, Valdis.Kletnieks at vt.edu wrote: >> >>> On Wed, 07 Apr 2010 14:17:49 PDT, "Gary E. Miller" said: >>> >>>> Then scroll down to the fees you can expect in 2013. Especially note >>>> how the small guys get hit much harder per IP. >>> >>> The small guys pay: $0.000074505805969 per /64. ($1250 / (2^(64-40)) >>> The big guys pay: $0.000000008185452 per /64. ($36000 / (2^(64-22)) >>> >>> The small guys are still paying less than 1/100th of a penny per /64. Assuming >>> your salary plus overhead is $40/hour, each *second* of your time is worth >>> more than the cost of 150 /64s. >>> >>> Oh, the inhumanity. >> >> >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > > iD8DBQFLvmQxBmnRqz71OvMRAr2dAKC4BrqBI94hvvyKEa+mLh4oML7yVwCfScFR > 60z+bDBMHOvTRQwQJPW6SCo= > =9zBu > -----END PGP SIGNATURE----- From bmanning at vacation.karoshi.com Thu Apr 8 18:30:40 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 8 Apr 2010 23:30:40 +0000 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <20100408230509.GC4818@dan.olp.net> References: <201004081536.o38FaMKQ025021@aurora.sol.net> <250CFBF9-844D-4057-B769-7B87941AF910@delong.com> <20100408171740.GE3358@vacation.karoshi.com.> <20100408175026.GE4808@dan.olp.net> <20100408180001.GH3358@vacation.karoshi.com.> <20100408230509.GC4818@dan.olp.net> Message-ID: <20100408233040.GA2124@vacation.karoshi.com.> On Thu, Apr 08, 2010 at 06:05:09PM -0500, Dan White wrote: > >>> > >>> What, if any, plan exists to improve the utilization density of the > >>> existant IPv4 pool? > >> > >>I believe your question is based on an outdated assumption. > > > > and that outdated assumption is? > > The assumption that ARIN allocations are based on anything other than 12-24 > month need (with only a few exceptions). allocations are based on: ) current policy ) demonstrated need always have (even pre-ARIN, pre-RIR) ... when the policy was "there is a network and host split" then every qualified applicant got a /8. and your point about getting "enough" for a 12-24 month need backs up my assertion that you are allocated more than you need. there is some "padding" for you to grow into. which you may or may not do. strict needs based allocation would give you -exactly- what you need at the time of the request - sort of like a DHCP assignment no? > If there are a significant number of sparse allocations of IPv4 blocks in > ARIN, then that's a good indication that allocation rules need to be > updated. the tricky parts there are: ) how is utilization defined? ) how to accomodate historical and legacy delegations that had different assignment rules than are currently in effect. ) is it -worth- the cost to effectively manage a resource pool or are we willing to unilterally declare a "chernobyl Zone of Alienation" around the IPv4 pool that we have, by our own unwillingness, agreed to consider "toxic" and too costly to manage... and proceed to use the exact same policies/procedures on the IPv6 pool - which despite zelots claims to the contrary - is finite and we stand a very real chance of screwing it up too. I'd like to see the community work toward a real 80% utiliztion of the IPv4 pool (since I know for a fact taht there is lots of sparse allocation out there...) Just saying. > -- > Dan White From matthew at matthew.at Thu Apr 8 18:33:27 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 08 Apr 2010 16:33:27 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <22087.1270676886@localhost> Message-ID: <4BBE67C7.5080309@matthew.at> Owen DeLong wrote: > You are mistaken. > > If you only need one /64, you cannot possibly be an IPv6 ISP. > > As such, you would only pay the end-user price of $1250 one-time and $100/year. > > That $100/year also covers your IPv4 space and your autonomous system number. > > Only $100/year (and an RSA) more than you're paying now. Or, infinitely more, for those of us who think in percentages. Matthew Kaufman From drc at virtualized.org Thu Apr 8 18:51:42 2010 From: drc at virtualized.org (David Conrad) Date: Thu, 8 Apr 2010 13:51:42 -1000 Subject: Behold - the Address-Yenta! In-Reply-To: <98D4754C-9F6F-4C12-8849-F0747C5E9136@arin.net> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <4BBE118C.6070602@sprunk.org> <20100408183757.GA9681@vacation.karoshi.com> <20100408193932.GA10217@vacation.karoshi.com> <98D4754C-9F6F-4C12-8849-F0747C5E9136@arin.net> Message-ID: <30233E8E-2CC5-4347-93AD-8A3A8CF5C808@virtualized.org> John, In the cases I'm aware of (which were some time ago), there was (to my knowledge) no fraud involved. Or are you indicating the mechanisms I described are in some way fraudulent? Regards, -drc On Apr 8, 2010, at 12:46 PM, John Curran wrote: > On Apr 8, 2010, at 3:51 PM, David Conrad wrote: >> Sure they are. I personally know of several cases where addresses have been sold. Right now, people have to go through a bunch of foo, creating dummy companies to hold the IP address assets, transferring the assets, selling the dummy companies, etc., but the end result is the same. > > David - > > Please report these events to: : > > "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." > > We do investigate, and if we can determine falsified information was used > to effect a transfer, we will revert the transfer and/or initiate resource > review as appropriate. > > /John > > John Curran > President and CEO > ARIN > > From jcurran at arin.net Thu Apr 8 18:55:46 2010 From: jcurran at arin.net (John Curran) Date: Thu, 8 Apr 2010 19:55:46 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <612B4477-10B0-4B95-8B03-02ACE59DDA76@via.net> References: <201004081536.o38FaMKQ025021@aurora.sol.net> <250CFBF9-844D-4057-B769-7B87941AF910@delong.com> <20100408171740.GE3358@vacation.karoshi.com> <20100408175026.GE4808@dan.olp.net> <612B4477-10B0-4B95-8B03-02ACE59DDA76@via.net> Message-ID: On Apr 8, 2010, at 2:29 PM, joe mcguckin wrote: > I think the more interesting discussion is: > - Where is ARIN and the RIR's headed? > - What will ARIN look like 10 years from now? Joe - Excellent questions... The direction with respect to ARIN is that the Board has spent significant time considering this issue and the guidance provided to date is that ARIN is to focus on its core mission of providing allocation and registration services, and be supportive of other related organizations (e.g. NANOG, ICANN, ISOC) which perform related functions in the community. This approach has reduced the risk of mission creep (at least as far as I can tell... :-) From a practical matter, it also means that we need to consider a future for ARIN which provides a core address registry function, modest IPv4 updates and modest IPv6 new allocation activity, and likely a very stable policy framework. This vision of the future is highly compatible with automation, and ARIN is indeed working aggressively in this area with ARIN Online. I do think that automation plus a reduction in activity will result in a modest reduction in overall costs, but the costs associated with having an open community-based organization aren't necessarily changing: - If you have the community to elect AC and Board members, then you have a membership/election function (which implies specific costs in the organization). - If you have the community set policy via an open policy process, then you have a policy process, policy proposal administration, and public policy meetings (which again implies more costs to the organization, roughly proportional to the policy activity). - If you participate in the global policy process (coordinating with other RIR's, ICANN, and now the ITU), then there is yet another set of costs to be covered by the organization. I'm committed to keeping the costs reasonable and proper for the mission, but its the community that needs to think about that mission and what they want ARIN (and the RIR community as a whole) to be doing 10+ years from now... Input can be provided in many forms, including on the mailing lists, in-person and remotely in the Public Policy Meeting, via the various consultations that ARIN does with respect to services and fees, and directly via running for the ARIN Board in the annual election process. Thank you for raising this topic! /John John Curran President and CEO ARIN From nanog2 at adns.net Thu Apr 8 18:57:28 2010 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Thu, 8 Apr 2010 18:57:28 -0500 Subject: "Running out of IPv6" (Re: ARIN IP6 policy for those with legacyIP4 Space) References: <000601cad73d$2cac32a0$860497e0$@org><201004081826.o38IQpfJ038982@aurora.sol.net><4BBE24CC.2050803@unfix.org> <601EE254-AB0B-4126-8B7E-162B844B03CE@delong.com> Message-ID: <424EBE79812D4637BA6AC1B0A2AA5517@TAKA> What I would need if I were to go with IP6 would be to have a parallel address for every one of my current addresses. Right now we have 2 - legacy /24's and one legacy /23 - thats it. I'd just need the "equivalent" IP6 space. We could just get that from our current provider (Steadfast in this case), but it would not be portable and with our root servers, (INS - please, not interested in discussing the merits of ICANN vs Inclusive Namespace), we would need portable IPs that wouldn't change. ARIN does provide microallocations, but ICANN forced them to put "for ICANN approved root service only" into their policy for microallocations, so that leaves us out. John ----- Original Message ----- From: "Owen DeLong" To: "Chris Grundemann" Cc: "NANOG list" ; "Joe Greco" Sent: Thursday, April 08, 2010 3:54 PM Subject: Re: "Running out of IPv6" (Re: ARIN IP6 policy for those with legacyIP4 Space) > > On Apr 8, 2010, at 12:10 PM, Chris Grundemann wrote: > >> On Thu, Apr 8, 2010 at 12:47, Jeroen Massar wrote: >>> [changing topics, so that it actually reflects the content] >>> >>> On 2010-04-08 20:33, William Herrin wrote: >>>> Yes, with suitably questionable delegations, it is possible to run out >>>> of IPv6 quickly. >> >> The bottom line (IMHO) is that IPv6 is NOT infinite and propagating >> that myth will lead to waste. That being said, the IPv6 space is MUCH >> larger than IPv4. Somewhere between 16 million and 17 billion times >> larger based on current standards by my math[1]. >> > Agreed > >>> Ever noticed that fat /13 for a certain military network in the ARIN >>> region!? >>> >>> At least those /19 are justifyiable under the HD rules (XX million >>> customers times a /48 and voila). A /13 though, very hard to justify... >> >> Not every customer needs a /48. In fact most probably don't. >> > Whether they need it or not, it is common allocation/assignment > practice. I agree that smaller (SOHO, for example) customers should > get a /56 by default and a /48 on request, but, this is by no means > a universal truth of current practice. > > Owen > > > From jcurran at arin.net Thu Apr 8 19:02:52 2010 From: jcurran at arin.net (John Curran) Date: Thu, 8 Apr 2010 20:02:52 -0400 Subject: Behold - the Address-Yenta! In-Reply-To: <30233E8E-2CC5-4347-93AD-8A3A8CF5C808@virtualized.org> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <4BBE118C.6070602@sprunk.org> <20100408183757.GA9681@vacation.karoshi.com> <20100408193932.GA10217@vacation.karoshi.com> <98D4754C-9F6F-4C12-8849-F0747C5E9136@arin.net> <30233E8E-2CC5-4347-93AD-8A3A8CF5C808@virtualized.org> Message-ID: <88FE8260-668C-435F-BBF0-45AA9EF929FD@arin.net> On Apr 8, 2010, at 7:51 PM, David Conrad wrote: > John, > > In the cases I'm aware of (which were some time ago), there was (to my knowledge) no fraud involved. If you see more recent cases of this occurring, please report them. > Or are you indicating the mechanisms I described are in some way fraudulent? Potentially, yes. Sincerely, /John John Curran President and CEO ARIN From wavetossed at googlemail.com Thu Apr 8 19:16:27 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Fri, 9 Apr 2010 01:16:27 +0100 Subject: "Running out of IPv6" (Re: ARIN IP6 policy for those with legacyIP4 Space) In-Reply-To: <424EBE79812D4637BA6AC1B0A2AA5517@TAKA> References: <000601cad73d$2cac32a0$860497e0$@org> <201004081826.o38IQpfJ038982@aurora.sol.net> <4BBE24CC.2050803@unfix.org> <601EE254-AB0B-4126-8B7E-162B844B03CE@delong.com> <424EBE79812D4637BA6AC1B0A2AA5517@TAKA> Message-ID: > What I would need if I were to go with IP6 would be to have a parallel > address for every one of > my current addresses. Right now we have 2 - legacy /24's and one legacy /23 > - thats it. > > I'd just need the "equivalent" ?IP6 space. The key question is "are you an ISP?". If the answer is yes, then the IPv6 equivalent is a /32 block. If no, then it depends on whether more than one site is involved, since the allocation size would be a /48 per site. IPv6 is a combination of classful and classless addressing. The result of that is that all allocations are sized to be more addresses than you could possibly ever need in the majority of cases. > ARIN does provide microallocations, but ICANN forced them to put "for ICANN > approved > root service only" into their policy for microallocations, so that leaves us > out. You fit under "Direct assignments from ARIN to end-user organizations" and should have no problem getting a /48. If you need multiple sites then "IPv6 Multiple Discrete Networks" would apply. --Michael Dillon From owen at delong.com Thu Apr 8 19:14:16 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 8 Apr 2010 17:14:16 -0700 Subject: "Running out of IPv6" (Re: ARIN IP6 policy for those with legacyIP4 Space) In-Reply-To: <424EBE79812D4637BA6AC1B0A2AA5517@TAKA> References: <000601cad73d$2cac32a0$860497e0$@org><201004081826.o38IQpfJ038982@aurora.sol.net><4BBE24CC.2050803@unfix.org> <601EE254-AB0B-4126-8B7E-162B844B03CE@delong.com> <424EBE79812D4637BA6AC1B0A2AA5517@TAKA> Message-ID: <174F7BB3-A9AB-4B52-AB9C-454D5166BD4C@delong.com> On Apr 8, 2010, at 4:57 PM, John Palmer (NANOG Acct) wrote: > What I would need if I were to go with IP6 would be to have a parallel address for every one of > my current addresses. Right now we have 2 - legacy /24's and one legacy /23 - thats it. > > I'd just need the "equivalent" IP6 space. > We could just get that from our current provider (Steadfast in this case), but it would not > be portable and with our root servers, (INS - please, not interested in discussing the merits of ICANN vs Inclusive Namespace), we would need portable IPs that wouldn't change. > The problem is that equivalent for IPv6 is not calculated on the host boundary. N = the number of subnets you have in IPv4. N * /64 = the bare minimum amount of IPv6 space you need. If you are an ISP, then, it becomes a bit more complicated. N = the number of customers you have that have a single subnet O = the number of customers you have that are SO/HO or small business and can get by with a /56 and do not request more. P = the rest of your IP transit customers. (N+256(O)+65536(P)) * /64 = the bare minimum amount of IPv6 space you need for customers. You must, then, add a /64 for each of your own infrastructure networks as well. > ARIN does provide microallocations, but ICANN forced them to put "for ICANN approved > root service only" into their policy for microallocations, so that leaves us out. > ICANN can't force anything into ARIN policy. If you want that wording changed in ARIN policy, you can submit a policy proposal. If it gains community consensus, the wording will change and ICANN/IANA will have to live with that. IANA policies are set through a bottom up process that comes from the RIRs, not the other way around. Owen > ----- Original Message ----- From: "Owen DeLong" > To: "Chris Grundemann" > Cc: "NANOG list" ; "Joe Greco" > Sent: Thursday, April 08, 2010 3:54 PM > Subject: Re: "Running out of IPv6" (Re: ARIN IP6 policy for those with legacyIP4 Space) > > >> On Apr 8, 2010, at 12:10 PM, Chris Grundemann wrote: >>> On Thu, Apr 8, 2010 at 12:47, Jeroen Massar wrote: >>>> [changing topics, so that it actually reflects the content] >>>> On 2010-04-08 20:33, William Herrin wrote: >>>>> Yes, with suitably questionable delegations, it is possible to run out >>>>> of IPv6 quickly. >>> The bottom line (IMHO) is that IPv6 is NOT infinite and propagating >>> that myth will lead to waste. That being said, the IPv6 space is MUCH >>> larger than IPv4. Somewhere between 16 million and 17 billion times >>> larger based on current standards by my math[1]. >> Agreed >>>> Ever noticed that fat /13 for a certain military network in the ARIN >>>> region!? >>>> At least those /19 are justifyiable under the HD rules (XX million >>>> customers times a /48 and voila). A /13 though, very hard to justify... >>> Not every customer needs a /48. In fact most probably don't. >> Whether they need it or not, it is common allocation/assignment >> practice. I agree that smaller (SOHO, for example) customers should >> get a /56 by default and a /48 on request, but, this is by no means >> a universal truth of current practice. >> Owen >> > From pfunix at gmail.com Thu Apr 8 19:29:07 2010 From: pfunix at gmail.com (Beavis) Date: Thu, 8 Apr 2010 18:29:07 -0600 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <4BBE3E43.2050407@2mbit.com> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> Message-ID: Is it possible for you to share that filter list you have for china? im getting bogged down by those ssh-bruts as well coming in from china. -B On Thu, Apr 8, 2010 at 2:36 PM, Brielle Bruns wrote: > On 4/8/10 2:23 PM, Jay Hennigan wrote: >> >> We just got Cyclops alerts showing several of our prefixes sourced from >> AS23474 propagating through AS4134. ?Anyone else? >> >> aut-num: ? ? ?AS23724 >> as-name: ? ? ?CHINANET-IDC-BJ-AP >> descr: ? ? ? ?IDC, China Telecommunications Corporation >> country: ? ? ?CN >> >> aut-num: ? ? ?AS4134 >> as-name: ? ? ?CHINANET-BACKBONE >> descr: ? ? ? ?No.31,Jin-rong Street >> descr: ? ? ? ?Beijing >> descr: ? ? ? ?100032 >> country: ? ? ?CN >> >> -- >> 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 >> > > I'm starting to wonder if someone is 'testing the waters' in China to see > what they can get away with. I hate to be like this, but there's a reason > why I have all of China filtered on my routers. > > Amazing how much ?SSH hammering, spam, and other nastiness went away within > minutes of the filtering going in place. > > There comes a point where 'accidental' and 'isolated incident' become "we no > care" and "spam not illegal". ?And no, i'm not quoting that to mock, but > rather repeat exactly what admins in China send to me in response to abuse > reports and blocking in the AHBL. > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org ? ?/ ? ? http://www.ahbl.org > > -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From stephen at sprunk.org Thu Apr 8 19:44:32 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 08 Apr 2010 19:44:32 -0500 Subject: Juniper's artificial feature blocking (was legacy /8) In-Reply-To: References: <1004041933.AA21122@ivan.Harhan.ORG> Message-ID: <4BBE7870.6020400@sprunk.org> On 04 Apr 2010 16:07, James Hess wrote: > Using a 'key' is slightly less of a network operator nightmare than > having 100 featuresets, and thousands of mystery meat images for the > same software version. At least you don't need to go buy a new > software image, and do a full upgrade procedure to gain feature access. > > Applying a key seems less risky and less likely that downtime is > needed, when you decide that you now need this feature. Indeed. Just as importantly, developing a single image with license-enabled features saves both vendors and customers a lot of time on QA, acceptance testing, etc. Since you're always running the same image, you only need to test it once, with all features enabled, to be sure that everything works; if there are different images for different feature sets, you have to run a full test suite on each image. That's a lot of extra work for no real benefit. Having to switch from one image to another to enable a particular feature also entails additional risk, downtime, etc. that simply loading a license key does not. > Even CPU manufacturers are noted for artificially restricting features > in software (such as VT or hyper-threading, even artificially > disabling cores). Not all buyers of L3 switches need or want to payfor > that, and there is more $$$ to be made from those that do. > > The manufacturer can either segment their market by not offering > OSPFv3 on the device, release a new higher-end hardware model for V3 > support at 10x the cost, or offer an add-on license, as an incremental > upgrade to a larger number of users (including the installed base). Indeed. Vendors face a lot of price pressure, so being able to disable non-mandatory features to meet low-end customers' price demands is a major competitive advantage. However, they still need revenue to support the development that the handful of high-end customers demand for "new" or "optional" features, and charging for licenses to enable those features seems to be the best way that anyone has figured out to do that. Heck, I work with one vendor that requires separate licenses for virtually every checkbox in their GUI; turning up one customer port may involve purchasing dozens of new licenses. The customers of their product don't like it, sure, but suggest that they pay the full cost of enabling all options on all ports and they flip out. Licensed features enable customers to purchase only what they need, not what some marketing puke decides they need (or some one-size-must-fit-all pricing scheme, which rarely works well). S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From bruns at 2mbit.com Thu Apr 8 20:42:01 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 08 Apr 2010 19:42:01 -0600 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> Message-ID: <4BBE85E9.2050302@2mbit.com> On 4/8/10 6:29 PM, Beavis wrote: > Is it possible for you to share that filter list you have for china? > im getting bogged down by those ssh-bruts as well coming in from > china. > > Sure, check off-list momentarily, you'll have a nice Foundry formatted ACL that can easily be adjusted to work with cisco or anything else that uses a similar format. Anyone else want a copy of the ACLs while i've got it in front of me? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From w.d.clayton at gmail.com Thu Apr 8 20:42:51 2010 From: w.d.clayton at gmail.com (Will Clayton) Date: Thu, 8 Apr 2010 20:42:51 -0500 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> Message-ID: Do share! On Thu, Apr 8, 2010 at 7:29 PM, Beavis wrote: > Is it possible for you to share that filter list you have for china? > im getting bogged down by those ssh-bruts as well coming in from > china. > > > -B > > On Thu, Apr 8, 2010 at 2:36 PM, Brielle Bruns wrote: > > On 4/8/10 2:23 PM, Jay Hennigan wrote: > >> > >> We just got Cyclops alerts showing several of our prefixes sourced from > >> AS23474 propagating through AS4134. Anyone else? > >> > >> aut-num: AS23724 > >> as-name: CHINANET-IDC-BJ-AP > >> descr: IDC, China Telecommunications Corporation > >> country: CN > >> > >> aut-num: AS4134 > >> as-name: CHINANET-BACKBONE > >> descr: No.31,Jin-rong Street > >> descr: Beijing > >> descr: 100032 > >> country: CN > >> > >> -- > >> 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 > >> > > > > I'm starting to wonder if someone is 'testing the waters' in China to see > > what they can get away with. I hate to be like this, but there's a reason > > why I have all of China filtered on my routers. > > > > Amazing how much SSH hammering, spam, and other nastiness went away > within > > minutes of the filtering going in place. > > > > There comes a point where 'accidental' and 'isolated incident' become "we > no > > care" and "spam not illegal". And no, i'm not quoting that to mock, but > > rather repeat exactly what admins in China send to me in response to > abuse > > reports and blocking in the AHBL. > > > > -- > > Brielle Bruns > > The Summit Open Source Development Group > > http://www.sosdg.org / http://www.ahbl.org > > > > > > > > -- > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > > From aaron at wholesaleinternet.net Thu Apr 8 20:50:36 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Thu, 8 Apr 2010 20:50:36 -0500 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> Message-ID: <031b01cad787$0fdf9c30$2f9ed490$@net> Please. -----Original Message----- From: Will Clayton [mailto:w.d.clayton at gmail.com] Sent: Thursday, April 08, 2010 8:43 PM To: Beavis Cc: nanog at nanog.org Subject: Re: BGP hijack from 23724 -> 4134 China? Do share! On Thu, Apr 8, 2010 at 7:29 PM, Beavis wrote: > Is it possible for you to share that filter list you have for china? > im getting bogged down by those ssh-bruts as well coming in from > china. > > > -B > > On Thu, Apr 8, 2010 at 2:36 PM, Brielle Bruns wrote: > > On 4/8/10 2:23 PM, Jay Hennigan wrote: > >> > >> We just got Cyclops alerts showing several of our prefixes sourced from > >> AS23474 propagating through AS4134. Anyone else? > >> > >> aut-num: AS23724 > >> as-name: CHINANET-IDC-BJ-AP > >> descr: IDC, China Telecommunications Corporation > >> country: CN > >> > >> aut-num: AS4134 > >> as-name: CHINANET-BACKBONE > >> descr: No.31,Jin-rong Street > >> descr: Beijing > >> descr: 100032 > >> country: CN > >> > >> -- > >> 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 > >> > > > > I'm starting to wonder if someone is 'testing the waters' in China to see > > what they can get away with. I hate to be like this, but there's a reason > > why I have all of China filtered on my routers. > > > > Amazing how much SSH hammering, spam, and other nastiness went away > within > > minutes of the filtering going in place. > > > > There comes a point where 'accidental' and 'isolated incident' become "we > no > > care" and "spam not illegal". And no, i'm not quoting that to mock, but > > rather repeat exactly what admins in China send to me in response to > abuse > > reports and blocking in the AHBL. > > > > -- > > Brielle Bruns > > The Summit Open Source Development Group > > http://www.sosdg.org / http://www.ahbl.org > > > > > > > > -- > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > > No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.801 / Virus Database: 271.1.1/2796 - Release Date: 04/08/10 13:32:00 From bruns at 2mbit.com Thu Apr 8 21:05:40 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 08 Apr 2010 20:05:40 -0600 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <031b01cad787$0fdf9c30$2f9ed490$@net> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <031b01cad787$0fdf9c30$2f9ed490$@net> Message-ID: <4BBE8B74.7040508@2mbit.com> On 4/8/10 7:50 PM, Aaron Wendel wrote: > Please. > Since there's been alot of requests for the ACLs, i've gone ahead and put the info on our wiki for easy access. http://wiki.sosdg.org/sosdg:internal:chinafilter Hope it comes in handy, and please let me know if i'm missing anything. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From lesmith at ecsis.net Thu Apr 8 21:09:54 2010 From: lesmith at ecsis.net (Larry Smith) Date: Thu, 8 Apr 2010 21:09:54 -0500 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <031b01cad787$0fdf9c30$2f9ed490$@net> References: <4BBE3B2A.7070901@west.net> <031b01cad787$0fdf9c30$2f9ed490$@net> Message-ID: <201004082109.54686.lesmith@ecsis.net> +1 On Thu April 8 2010 20:50, Aaron Wendel wrote: > Please. > > -----Original Message----- > From: Will Clayton [mailto:w.d.clayton at gmail.com] > Sent: Thursday, April 08, 2010 8:43 PM > To: Beavis > Cc: nanog at nanog.org > Subject: Re: BGP hijack from 23724 -> 4134 China? > > Do share! > > On Thu, Apr 8, 2010 at 7:29 PM, Beavis wrote: > > Is it possible for you to share that filter list you have for china? > > im getting bogged down by those ssh-bruts as well coming in from > > china. > > > > > > -B > > > > On Thu, Apr 8, 2010 at 2:36 PM, Brielle Bruns wrote: > > > On 4/8/10 2:23 PM, Jay Hennigan wrote: > > >> We just got Cyclops alerts showing several of our prefixes sourced > > >> from AS23474 propagating through AS4134. Anyone else? > > >> > > >> aut-num: AS23724 > > >> as-name: CHINANET-IDC-BJ-AP > > >> descr: IDC, China Telecommunications Corporation > > >> country: CN > > >> > > >> aut-num: AS4134 > > >> as-name: CHINANET-BACKBONE > > >> descr: No.31,Jin-rong Street > > >> descr: Beijing > > >> descr: 100032 > > >> country: CN > > >> > > >> -- > > >> 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 > > > > > > I'm starting to wonder if someone is 'testing the waters' in China to > > see > > > > what they can get away with. I hate to be like this, but there's a > > reason > > > > why I have all of China filtered on my routers. > > > > > > Amazing how much SSH hammering, spam, and other nastiness went away > > > within minutes of the filtering going in place. > > > There comes a point where 'accidental' and 'isolated incident' become > > > "we no > > > care" and "spam not illegal". And no, i'm not quoting that to mock, > > > but rather repeat exactly what admins in China send to me in response > > > to abuse reports and blocking in the AHBL. > > > From danny at tcb.net Thu Apr 8 21:17:52 2010 From: danny at tcb.net (Danny McPherson) Date: Thu, 8 Apr 2010 20:17:52 -0600 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <4BBE8B74.7040508@2mbit.com> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <031b01cad787$0fdf9c30$2f9ed490$@net> <4BBE8B74.7040508@2mbit.com> Message-ID: <1C1064B0-8CCC-4141-8AB3-4A2F29D95716@tcb.net> On Apr 8, 2010, at 8:05 PM, Brielle Bruns wrote: > > Since there's been alot of requests for the ACLs, i've gone ahead and put the info on our wiki for easy access. > > http://wiki.sosdg.org/sosdg:internal:chinafilter > > Hope it comes in handy, and please let me know if i'm missing anything. If you're going to post this and folks are actually going to consider employing it I suspect it'd be well worthwhile to include on that page how you generated it and how you keep it updated -- so that it can be updated by others as necessary. Additionally, folks should note that this policy would have made zero difference in this particularly incident, most of you likely realize that. Furthermore, a policy such as this does nothing to mitigate exfiltration of data TO those address blocks you've listed. FWIW, this is a lot like putting a bandaid on a headache - it's not going to do much good in reality, and likely cause more harm than good in properly secured networks - but it might make some folks feel a little better. -danny From bruns at 2mbit.com Thu Apr 8 21:35:15 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 08 Apr 2010 20:35:15 -0600 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <1C1064B0-8CCC-4141-8AB3-4A2F29D95716@tcb.net> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <031b01cad787$0fdf9c30$2f9ed490$@net> <4BBE8B74.7040508@2mbit.com> <1C1064B0-8CCC-4141-8AB3-4A2F29D95716@tcb.net> Message-ID: <4BBE9263.6050100@2mbit.com> On 4/8/10 8:17 PM, Danny McPherson wrote: > > On Apr 8, 2010, at 8:05 PM, Brielle Bruns wrote: >> >> Since there's been alot of requests for the ACLs, i've gone ahead and put the info on our wiki for easy access. >> >> http://wiki.sosdg.org/sosdg:internal:chinafilter >> >> Hope it comes in handy, and please let me know if i'm missing anything. > > If you're going to post this and folks are actually going to consider > employing it I suspect it'd be well worthwhile to include on that page > how you generated it and how you keep it updated -- so that it can be > updated by others as necessary. > Its sorta a mess to generate that final list. The best way, is to take the County IP Blocks list, use a tool like cidr-convert.c (http://www.spamshield.org/cidr-convert.c) to aggregate blocks. For Foundry, there's the ability to enter into an input mode for ACLs where you can dump a list of CIDR blocks, and it will handle the conversion into access-list commands. I grabbed that access-list from the routers directly, so thats why it's been generated already. If there's a tool for UNIX/Linux that can generate the wildcard masks from CIDR in bulk for use in creating ACLs, I'd be happy to put it up on the page. > Additionally, folks should note that this policy would have made zero > difference in this particularly incident, most of you likely realize that. > Furthermore, a policy such as this does nothing to mitigate exfiltration > of data TO those address blocks you've listed. > Of course, this wont fix the prefix leaks. I think everyone here knows that. :) > FWIW, this is a lot like putting a bandaid on a headache - it's not going > to do much good in reality, and likely cause more harm than good in properly > secured networks - but it might make some folks feel a little better. > More harm then good is a matter of opinion. Denying all of mainland China reduces the amount of attacks on my network. If you consider that masking security problems rather then fixing them, then *shrugs*. Its just one of many layers. It also allows me to make and enforce the statement that I will not tolerate the bullshit China pulls. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From joelja at bogus.com Thu Apr 8 21:38:06 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 08 Apr 2010 19:38:06 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <20100408130052.GD22122@skywalker.creative.net.au> References: <5C00010B-856A-4ADC-A3EF-6E4CC7E9D170@sackheads.org> <201004081251.o38Cpl5W017606@aurora.sol.net> <20100408130052.GD22122@skywalker.creative.net.au> Message-ID: <4BBE930E.5040407@bogus.com> On 04/08/2010 06:00 AM, Adrian Chadd wrote: > On Thu, Apr 08, 2010, Joe Greco wrote: > >> Because a legacy holder doesn't care about ARIN; a legacy holder has >> usable space that cannot be reclaimed by ARIN and who is not paying >> anything to ARIN. The point here is that this situation does not >> encourage adoption of IPv6, where suddenly there'd be an annual fee >> and a contract for the space. "ARIN" is incidental, simply the RIR >> responsible in this case. > > Out of curiousity, I wonder whether the adoption of the internet > in the 90s would have occured if IPv4 addresses were allocated, managed > and controlled like they are today. The growth of the internet since 1992 has occurred under conditions of gradually increasing scarcity.that scarcity is so normal that people don't really think about what it's like not to have it. > > > > Adrian > > From goemon at anime.net Thu Apr 8 22:15:28 2010 From: goemon at anime.net (goemon at anime.net) Date: Thu, 8 Apr 2010 20:15:28 -0700 (PDT) Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <1C1064B0-8CCC-4141-8AB3-4A2F29D95716@tcb.net> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <031b01cad787$0fdf9c30$2f9ed490$@net> <4BBE8B74.7040508@2mbit.com> <1C1064B0-8CCC-4141-8AB3-4A2F29D95716@tcb.net> Message-ID: On Thu, 8 Apr 2010, Danny McPherson wrote: > FWIW, this is a lot like putting a bandaid on a headache - it's not going > to do much good in reality, and likely cause more harm than good in properly > secured networks - but it might make some folks feel a little better. behavior modification. chinanet doesn't listen to complaints from victims. perhaps they'll listen to complaints from customers when they can't reach anyone anymore. this is after all how spam RBLs work. providers don't care one whit about everyone who gets spammed, but they care if their customers walk because they can't reach anyone. -Dan From bill at herrin.us Thu Apr 8 22:29:18 2010 From: bill at herrin.us (William Herrin) Date: Thu, 8 Apr 2010 23:29:18 -0400 Subject: "Running out of IPv6" (Re: ARIN IP6 policy for those with legacyIP4 Space) In-Reply-To: <424EBE79812D4637BA6AC1B0A2AA5517@TAKA> References: <000601cad73d$2cac32a0$860497e0$@org> <201004081826.o38IQpfJ038982@aurora.sol.net> <4BBE24CC.2050803@unfix.org> <601EE254-AB0B-4126-8B7E-162B844B03CE@delong.com> <424EBE79812D4637BA6AC1B0A2AA5517@TAKA> Message-ID: On Thu, Apr 8, 2010 at 7:57 PM, John Palmer (NANOG Acct) wrote: > What I would need if I were to go with IP6 would be to have a parallel > address for every one of > my current addresses. Right now we have 2 - legacy /24's and one legacy /23 > - thats it. > > I'd just need the "equivalent" ?IP6 space. John, IPv6 assignment is LAN-centric rather than address centric, so think about how many LANs you have. LANs are rigged to always be /64. Stateless autoconfiguration doesn't work right if they're bigger or smaller. You need a /64 for each LAN including the ones now served with RFC 1918 addresses. You'll want to set aside one /64 from which you'll assign /126's to your point to points and /128's to your router loopbacks. If you have downstream customers, even if they're just dialups, expect to assign at least a /60 to each one. Many folks recommend /56 or /48. Delegation on 4-bit boundaries is convenient in IPv6 the same way delegation on 8-bit boundaries is convenient in IPv4. Since your downstream customers may have an internal LAN and a DMZ, you'll want to provide at least two LANs by stepping up to the next 4-bit boundary above /64. ARIN details vary depending on whether or not your an ISP and whether you're connecting a single network or multiple sites independently connected to the Internet. I recommend you hire or befriend someone with experience interacting with ARIN who can go over your network's details with you. ARIN staff are friendly and helpful but there are some magic words and phrases that will get you the result you want and it can be hard to un-say the wrong thing. If you want to look before you leap, do a google search for "6to4" or get a free IPv6 tunnel via tunnelbroker.net. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From danny at tcb.net Thu Apr 8 23:05:23 2010 From: danny at tcb.net (Danny McPherson) Date: Thu, 8 Apr 2010 22:05:23 -0600 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <4BBE9263.6050100@2mbit.com> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <031b01cad787$0fdf9c30$2f9ed490$@net> <4BBE8B74.7040508@2mbit.com> <1C1064B0-8CCC-4141-8AB3-4A2F29D95716@tcb.net> <4BBE9263.6050100@2mbit.com> Message-ID: On Apr 8, 2010, at 8:35 PM, Brielle Bruns wrote: > > More harm then good is a matter of opinion. Denying all of mainland China reduces the amount of attacks on my network. If you consider that masking security problems rather then fixing them, then *shrugs*. Its just one of many layers. It also allows me to make and enforce the statement that I will not tolerate the bullshit China pulls. FWIW, I get it - folks are surely going to implement local security policies that are first aligned with corporate [and national] security objectives. My concern is that if people think bogon filters break stuff, just wait until a couple thousand networks start selectively filtering countries based on some notion of geoIP mappings (e.g., CN today, KP and IR tomorrow, etc..), when in many cases prefixes span lots of national boundaries (as do many ASNs) - the Internet will continue to fragment and brokenness will result. As an example of how such network filtering policies might well become an operational problem consider a client using Online Certificate Status Protocol (OCSP) with X.509 digital certificates before setting up a secure connection to a web server somewhere in Asia (the server itself may well NOT be inside of China). The client, wanting to inquire as to the state (revocation status) of a particular certificate generated by that CNNIC CA embedded in their Firefox client, reaches out to an OCSP server that's authoritative for the cert - in this case CNNIC. Unfortunately, CNNIC, which primarily resides within 218.241.0.0/16, isn't reachable because of this entry in your ACL: access-list 199 deny ip 218.240.0.0 0.7.255.255 any Now, whether you or any of the users on your network choose to leave that CNNIC CA (or others) enabled in your client is a separate issue, but default drop policies such as you're recommending can certainly result in some collateral damage that can be very tedious to debug, and possibly even broaden attack surfaces themselves. I'm not particularly a fan of bogon filters for reasons outlined here and elsewhere many times before - and bogon addresses theoretically don't have live clients and servers folks might be legitimately be transacting with. -danny From mysidia at gmail.com Fri Apr 9 00:53:14 2010 From: mysidia at gmail.com (James Hess) Date: Fri, 9 Apr 2010 00:53:14 -0500 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <4BBE9263.6050100@2mbit.com> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <031b01cad787$0fdf9c30$2f9ed490$@net> <4BBE8B74.7040508@2mbit.com> <1C1064B0-8CCC-4141-8AB3-4A2F29D95716@tcb.net> <4BBE9263.6050100@2mbit.com> Message-ID: On Thu, Apr 8, 2010 at 9:35 PM, Brielle Bruns wrote: > I grabbed that access-list from the routers directly, so thats why it's been > generated already. ?If there's a tool for UNIX/Linux that can generate the > wildcard masks from CIDR in bulk for use in creating ACLs, I'd be happy to > put it up on the page. UNIX/Linux users can probably accomplish using simple scripting, since there are perl modules such as NetAddr::IP available. eg #!/usr/bin/perl use Net::CIDR qw/cidradd/; use NetAddr::IP; @list=(); while (<>) { chomp; while ( $_ =~ s/^\s*([a-fA-F0-9:.]+)\/(\d+)\s*/ / ) { @list = cidradd($1 . '/' . $2, @list); } } for (@list) { $ip = new NetAddr::IP($_); print "access-list 199 deny " . $ip->addr() . " " . $ip->wildcard() . "\n" ; } -- -J From daniel.karrenberg at ripe.net Fri Apr 9 01:22:37 2010 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 9 Apr 2010 08:22:37 +0200 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <4BBE3E43.2050407@2mbit.com> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> Message-ID: <20100409062237.GD1087@reif.karrenberg.net> On 08.04 14:36, Brielle Bruns wrote: > > I'm starting to wonder if someone is 'testing the waters' in China to > see what they can get away with. I hate to be like this, but there's a > reason why I have all of China filtered on my routers. Beware of prejudice influencing observations and their interpretation. > .... > Amazing how much SSH hammering, spam, and other nastiness went away > within minutes of the filtering going in place. Objectively for my networks the vast majority of the SSH hammering, spam and other nastiness would go away if I filtered out the prefixes allocated by ARIN. I do not do that because I want to talk to hosts at these addressses. Sometimes I even want to talk to hosts that originnate the nastiness. I certainly do not want my upstreams start preventing me from doing that. **** Selectively preventing packet flow is *not* a security measure. **** Selectively preventing packet flow leads to unexpected and hard to diagnose breakage. **** Many independent actors selectively preventing packet flow will eventually partition the Internet sufficiently to break it beyond recognition. Preventing packet flow may be necessary to mitigate DoS and to do local security; I have pulled out the network cable before too. However doing it at many different places in the network according to local policies leads to bad breakage. Daniel From ops.lists at gmail.com Fri Apr 9 01:28:02 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 9 Apr 2010 11:58:02 +0530 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <20100409062237.GD1087@reif.karrenberg.net> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <20100409062237.GD1087@reif.karrenberg.net> Message-ID: It depends. Preventing packet flow from a rather more carefully selected list of prefixes may actually make sense. These for example - www.spamhaus.org/drop/ Filtering prefixes that your customers may actually exchange valid email / traffic with, and that are not 100% bad is not the best way to go. Block specific prefixes from China, the USA, Eastern Europe, wherever - that are a specific threat to your network .. great. Even better if you are able to manage that blocking and avoid turning your router ACLs into a sort of Hotel California for prefixes. On Fri, Apr 9, 2010 at 11:52 AM, Daniel Karrenberg wrote: > > > **** Selectively preventing packet flow is *not* a security measure. > > **** Selectively preventing packet flow leads to unexpected and hard to diagnose breakage. > > **** Many independent actors selectively preventing packet flow will eventually > ? ? partition the Internet sufficiently to break it beyond recognition. -- Suresh Ramasubramanian (ops.lists at gmail.com) From daniel.karrenberg at ripe.net Fri Apr 9 02:02:14 2010 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 9 Apr 2010 09:02:14 +0200 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <4BBE3E43.2050407@2mbit.com> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> Message-ID: <20100409070214.GE1087@reif.karrenberg.net> :-) ;-) ;-) And now for the political analysis in our morning programming broadcasted to North America: Beware of unintentionally helping the Chinese government to implement the Great Firewall by blocking packet flow right there in the land of Free Speech(TM). The satisfaction of vigorously loosing shots will qiuckly dissipate as soon as the bullets start impacting feet very nearby. Now let us return to our regular mix of operationally tinted programming. :-) ;-) ;-) From randy at psg.com Fri Apr 9 03:12:11 2010 From: randy at psg.com (Randy Bush) Date: Fri, 09 Apr 2010 17:12:11 +0900 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004081251.o38Cpl5W017606@aurora.sol.net> References: <5C00010B-856A-4ADC-A3EF-6E4CC7E9D170@sackheads.org> Message-ID: > Because a legacy holder doesn't care about ARIN i do not think that statement is defensible there is a difference between caring and being willing to give up rights for no benefit From william.allen.simpson at gmail.com Fri Apr 9 03:14:53 2010 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Fri, 09 Apr 2010 04:14:53 -0400 Subject: Behold - the Address-Yenta! In-Reply-To: <88FE8260-668C-435F-BBF0-45AA9EF929FD@arin.net> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <4BBE118C.6070602@sprunk.org> <20100408183757.GA9681@vacation.karoshi.com> <20100408193932.GA10217@vacation.karoshi.com> <98D4754C-9F6F-4C12-8849-F0747C5E9136@arin.net> <30233E8E-2CC5-4347-93AD-8A3A8CF5C808@virtualized.org> <88FE8260-668C-435F-BBF0-45AA9EF929FD@arin.net> Message-ID: <4BBEE1FD.6030804@gmail.com> On 4/8/10 8:02 PM, John Curran wrote: > On Apr 8, 2010, at 7:51 PM, David Conrad wrote: >> In the cases I'm aware of (which were some time ago), there was (to my knowledge) no fraud involved. > > If you see more recent cases of this occurring, please report them. > >> Or are you indicating the mechanisms I described are in some way fraudulent? > > Potentially, yes. > And with no statute of limitations! Not all things are "solved" by laws. Or economics. Thanks for taking up this issue, John. From william.allen.simpson at gmail.com Fri Apr 9 03:16:45 2010 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Fri, 09 Apr 2010 04:16:45 -0400 Subject: APNIC's report on traffic directed to 1.0.0.0/8 In-Reply-To: References: Message-ID: <4BBEE26D.1020302@gmail.com> On 4/7/10 10:22 PM, Scott Howard wrote: > http://mailman.apnic.net/mailing-lists/apnic-talk/archive/2010/04/msg00002.html > > (There's also a PDF version with easier to enlarge images at > http://www.potaroo.net/studies/1slash8/1slash8.pdf ) > It was a nice read. But it didn't indicate where (source AS, or country, or whatever) the traffic was originating. Any data? From randy at psg.com Fri Apr 9 03:17:31 2010 From: randy at psg.com (Randy Bush) Date: Fri, 09 Apr 2010 17:17:31 +0900 Subject: Behold - the Address-Yenta! In-Reply-To: <88FE8260-668C-435F-BBF0-45AA9EF929FD@arin.net> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <4BBE118C.6070602@sprunk.org> <20100408183757.GA9681@vacation.karoshi.com> <20100408193932.GA10217@vacation.karoshi.com> <98D4754C-9F6F-4C12-8849-F0747C5E9136@arin.net> <30233E8E-2CC5-4347-93AD-8A3A8CF5C808@virtualized.org> <88FE8260-668C-435F-BBF0-45AA9EF929FD@arin.net> Message-ID: >> Or are you indicating the mechanisms I described are in some way >> fraudulent? > Potentially, yes. pfui. the current security level is chartreuse. you will get 15,000 free flier miles for spying on your neighbor. john, addresses are assets. people will transfer assets. get over it. two female ostriches are walking down the beach one looks behind & says "don't look now, but two males are following us" the other says, "let's walk faster," so they do the first looks behind and says "they are catching up!" so they break into a trot the first looks behind and says "they are still catching up!" so they start running full tilt the first looks behind and says "they are catching up even more quickly!" they both slam on the brakes and stick their heads in the sand a minute later the two males arrive the males look around and say, "where did they go?" randy From randy at psg.com Fri Apr 9 03:21:25 2010 From: randy at psg.com (Randy Bush) Date: Fri, 09 Apr 2010 17:21:25 +0900 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004081536.o38FaMKQ025021@aurora.sol.net> <250CFBF9-844D-4057-B769-7B87941AF910@delong.com> <20100408171740.GE3358@vacation.karoshi.com> <20100408175026.GE4808@dan.olp.net> <612B4477-10B0-4B95-8B03-02ACE59DDA76@via.net> Message-ID: > Excellent questions... The direction with respect to ARIN is that the > Board has spent significant time considering this issue and the > guidance provided to date is that ARIN is to focus on its core mission > of providing allocation and registration services, and be supportive > of other related organizations (e.g. NANOG, ICANN, ISOC) which perform > related functions in the community. This approach has reduced the > risk of mission creep (at least as far as I can tell... :-) > > From a practical matter, it also means that we need to consider a > future for ARIN which provides a core address registry function, > modest IPv4 updates and modest IPv6 new allocation activity, and > likely a very stable policy framework. This vision of the future is > highly compatible with automation, and ARIN is indeed working > aggressively in this area with ARIN Online. I do think that > automation plus a reduction in activity will result in a modest > reduction in overall costs, but the costs associated with having an > open community-based organization aren't necessarily changing: i think this is realistic, wise, and admirable. it is damned hard for an organization to resist mission creep, etc., and focus on mission, especially when that means long term shrinkage. the board and management are to be commended. randy From jgreco at ns.sol.net Fri Apr 9 06:09:19 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 9 Apr 2010 06:09:19 -0500 (CDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: from "Michael Dillon" at Apr 08, 2010 10:32:37 PM Message-ID: <201004091109.o39B9JjB023629@aurora.sol.net> > > 1) Justify why we need a heavy bureaucracy such as ARIN for IPv6 > > ? numbering resources, > > Because the members of ARIN (and the other four RIRs) want it that way. > And because nobody has yet made a serious proposal to ICANN that > would replace ARIN. Using the organization to justify the need for the organization is circular reasoning. > > 2) Tell me why something like the old pre-depletion pre-ARIN model > > ? of InterNIC and just handing out prefixes with substantially less > > ? paper-pushing wouldn't result in a cheaper-to-run RIR. > > Because the ARIN members, who pay most of ARIN's fees, are not > complaining about the level of those fees. This means that they > think the fees are cheap enough, or else they would demand that > the fees be changed. All ARIN fees are set by the ARIN members. Again, ... Anyways, the non-answers to these questions are very illuminating. ... 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 jgreco at ns.sol.net Fri Apr 9 06:21:46 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 9 Apr 2010 06:21:46 -0500 (CDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <8889118F-25DC-42FE-9057-AD5FF1463F43@delong.com> from "Owen DeLong" at Apr 08, 2010 02:40:58 PM Message-ID: <201004091121.o39BLkLL025885@aurora.sol.net> > > I have my doubts, based on a ~decade of observation. I don't think ARIN > > is deliberately evil, but I think there are some bits that'd be hard to > > fix. > > I believe that anything at ARIN which the community at large and the membership > can come to consensus is broken will be relatively easy to fix. > > Perhaps the true issue is that what you see as broken is perceived as "working > as intended" by much of the community and membership? That's a great point. Would you agree, then, that much of the community and membership implicitly sees little value in IPv6? You can claim that's a bit of a stretch, but quite frankly, the RIR policies, the sketchy support by providers, the lack of v6 support in much common gear, and so many other things seem to be all conspiring against v6 adoption. I need only point to v6 adoption rates to support that statement. This is an impediment that I've been idly pondering for some years now, which is why I rattle cages to encourage discussion whenever I see a promising opportunity. Put differently, you work in this arena too... you've presumably talked to stakeholders. Can you list some of the reasons people have provided for not adopting v6, and are any of them related to the v6 policies regarding address space? ... 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 marty at supine.com Fri Apr 9 06:27:13 2010 From: marty at supine.com (Martin Barry) Date: Fri, 9 Apr 2010 13:27:13 +0200 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004091109.o39B9JjB023629@aurora.sol.net> References: <201004091109.o39B9JjB023629@aurora.sol.net> Message-ID: <20100409112713.GB21811@merboo.mamista.net> $quoted_author = "Joe Greco" ; > > Using the organization to justify the need for the organization is > circular reasoning. I would have thought the role ARIN (and the other RIRs) has to play is clear from it's charter (registration of number resources to ensure uniqueness and fair allocation of a finite resource). And the need for someone or something to serve that role is best highlighted when it fails (e.g. duplicate ASes in RIPE and ARIN last year). > Anyways, the non-answers to these questions are very illuminating. Feel free to not deploy IPv6. Or get a /48 from a tunnel broker or your ISP. You have plenty of options, just one of which is provider independent space from ARIN. cheers Marty From cian.brennan at redbrick.dcu.ie Fri Apr 9 06:27:20 2010 From: cian.brennan at redbrick.dcu.ie (Cian Brennan) Date: Fri, 9 Apr 2010 12:27:20 +0100 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004091109.o39B9JjB023629@aurora.sol.net> References: <201004091109.o39B9JjB023629@aurora.sol.net> Message-ID: <20100409112720.GA19230@minerva.redbrick.dcu.ie> On Fri, Apr 09, 2010 at 06:09:19AM -0500, Joe Greco wrote: > > > 1) Justify why we need a heavy bureaucracy such as ARIN for IPv6 > > > ? numbering resources, > > > > Because the members of ARIN (and the other four RIRs) want it that way. > > And because nobody has yet made a serious proposal to ICANN that > > would replace ARIN. > > Using the organization to justify the need for the organization is > circular reasoning. > > > > 2) Tell me why something like the old pre-depletion pre-ARIN model > > > ? of InterNIC and just handing out prefixes with substantially less > > > ? paper-pushing wouldn't result in a cheaper-to-run RIR. > > > > Because the ARIN members, who pay most of ARIN's fees, are not > > complaining about the level of those fees. This means that they > > think the fees are cheap enough, or else they would demand that > > the fees be changed. All ARIN fees are set by the ARIN members. > > Again, ... > > Anyways, the non-answers to these questions are very illuminating. > This is an answer though. The vast majority of people who need address space in North America are ARIN members. These ARIN members are happy with the current organisation. If the set of people who need IP address tend towards being happy with the current system, there is no reason to change it for a new system, which they may not be happy with. > ... 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 marty at supine.com Fri Apr 9 06:39:19 2010 From: marty at supine.com (Martin Barry) Date: Fri, 9 Apr 2010 13:39:19 +0200 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004091121.o39BLkLL025885@aurora.sol.net> References: <8889118F-25DC-42FE-9057-AD5FF1463F43@delong.com> <201004091121.o39BLkLL025885@aurora.sol.net> Message-ID: <20100409113919.GC21811@merboo.mamista.net> $quoted_author = "Joe Greco" ; > > > Perhaps the true issue is that what you see as broken is perceived as "working > > as intended" by much of the community and membership? > > That's a great point. Would you agree, then, that much of the community > and membership implicitly sees little value in IPv6? Is that orthogonal to Owen's statement? > You can claim that's a bit of a stretch, but quite frankly, the RIR > policies, the sketchy support by providers, the lack of v6 support in > much common gear, and so many other things seem to be all conspiring > against v6 adoption. I need only point to v6 adoption rates to support > that statement. Which rates would those be? http://www.ipv6actnow.org/info/statistics/ IPv6 has had a slow start but it's certainly picking up. cheers Marty From jcurran at arin.net Fri Apr 9 06:43:23 2010 From: jcurran at arin.net (John Curran) Date: Fri, 9 Apr 2010 07:43:23 -0400 Subject: Behold - the Address-Yenta! In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <4BBE118C.6070602@sprunk.org> <20100408183757.GA9681@vacation.karoshi.com> <20100408193932.GA10217@vacation.karoshi.com> <98D4754C-9F6F-4C12-8849-F0747C5E9136@arin.net> <30233E8E-2CC5-4347-93AD-8A3A8CF5C808@virtualized.org> <88FE8260-668C-435F-BBF0-45AA9EF929FD@arin.net> Message-ID: On Apr 9, 2010, at 4:17 AM, Randy Bush wrote: > > john, addresses are assets. ... Randy - You may believe that IP addresses are assets; feel free to do so. ARIN's position follows RFC 2008 and RFC 2050 and will continue to do so until the community directs otherwise. For the legal discussion, see: > people will transfer assets. get over it. ARIN recognizes transfers of IP address blocks to designated recipients under the transfer policy which was extensively discussed by this community and adopted in June of last year: Other regional registries have also adopted transfer policies. That is not the question. The question discussed is the practice of performing resource review as a result of fraudulent applications. This is clearly intended by the community in NRPM section 12 so ARIN will do its best to enforce the policy as adopted. /John John Curran President and CEO ARIN From trejrco at gmail.com Fri Apr 9 06:46:19 2010 From: trejrco at gmail.com (TJ) Date: Fri, 9 Apr 2010 07:46:19 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004091121.o39BLkLL025885@aurora.sol.net> References: <8889118F-25DC-42FE-9057-AD5FF1463F43@delong.com> <201004091121.o39BLkLL025885@aurora.sol.net> Message-ID: In my experience ARIN/RIR policies have not been a noticeable barrier to IPv6 adoption. Lack of IA/security gear tops the list for my clients, with WAN Acceleration a runner-up. /TJ On Apr 9, 2010 7:23 AM, "Joe Greco" wrote: > > I have my doubts, based on a ~decade of observation. I don't think ARIN > > is deliberately evil, but I think there are some bits that'd be hard to > > fix. > > I believe that anything at ARIN which the community at large and the membership > can come to consensus is broken will be relatively easy to fix. > > Perhaps the true issue is that what you see as broken is perceived as "working > as intended" by much of the community and membership? That's a great point. Would you agree, then, that much of the community and membership implicitly sees little value in IPv6? You can claim that's a bit of a stretch, but quite frankly, the RIR policies, the sketchy support by providers, the lack of v6 support in much common gear, and so many other things seem to be all conspiring against v6 adoption. I need only point to v6 adoption rates to support that statement. This is an impediment that I've been idly pondering for some years now, which is why I rattle cages to encourage discussion whenever I see a promising opportunity. Put differently, you work in this arena too... you've presumably talked to stakeholders. Can you list some of the reasons people have provided for not adopting v6, and are any of them related to the v6 policies regarding address space? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it th... From randy at psg.com Fri Apr 9 06:47:05 2010 From: randy at psg.com (Randy Bush) Date: Fri, 09 Apr 2010 20:47:05 +0900 Subject: Behold - the Address-Yenta! In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <4BBE118C.6070602@sprunk.org> <20100408183757.GA9681@vacation.karoshi.com> <20100408193932.GA10217@vacation.karoshi.com> <98D4754C-9F6F-4C12-8849-F0747C5E9136@arin.net> <30233E8E-2CC5-4347-93AD-8A3A8CF5C808@virtualized.org> <88FE8260-668C-435F-BBF0-45AA9EF929FD@arin.net> Message-ID: > The question discussed is the practice of performing resource review > as a result of fraudulent applications. no. what was being discussed was transfers. you turned left, asserted that they were fraudulent, and told people to turn in their neighbors. randy From randy at psg.com Fri Apr 9 06:56:43 2010 From: randy at psg.com (Randy Bush) Date: Fri, 09 Apr 2010 20:56:43 +0900 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <20100409112720.GA19230@minerva.redbrick.dcu.ie> References: <201004091109.o39B9JjB023629@aurora.sol.net> <20100409112720.GA19230@minerva.redbrick.dcu.ie> Message-ID: > The vast majority of people who need address space in North America > are ARIN members. These ARIN members are happy with the current > organisation. If the set of people who need IP address tend towards > being happy with the current system, there is no reason to change it > for a new system, which they may not be happy with. not a useful argument. it amounts to the vast majority of the rich are happy being rich. randy From jcurran at arin.net Fri Apr 9 07:13:48 2010 From: jcurran at arin.net (John Curran) Date: Fri, 9 Apr 2010 08:13:48 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004082035.o38KZJPJ052110@aurora.sol.net> References: <201004082035.o38KZJPJ052110@aurora.sol.net> Message-ID: <41F7BA3B-B0D5-4398-BB5E-90B263830D8C@arin.net> On Apr 8, 2010, at 4:35 PM, Joe Greco wrote: > > The problem, as I've heard it, is that ARIN's fees are steep in order to > pay for various costs. Since there isn't the economy of scale of hundreds > of millions of domain names, and instead you just have ... what? Probably > less than a hundred thousand objects that are revenue-generating? If you > charge $1/yr for each registered object, that means your organizational > budget is sufficient for one full time person, maybe two. At $100/yr, you > have enough funding for some office space, some gear, and a small staff. Joe - Your financial breakdown is heading the right direction, but let help out with some more information (FYI - ARIN's 2009 Budget is available at https://www.arin.net/about_us/corp_docs/budget.html, and the 2010 one should be there sometime next week.) ARIN runs about a $15M annual operating expense. As you noted below, it can be hard to separate into distinct "products', and in fact, in some cases it is not appropriate to separate since one function (e.g. support for public policy development) might actually be a prerequisite for another (i.e.new address allocations). I am actually working to get more service- oriented cost information going forward, but this is non-trivial to make happen. In terms of fees, we have about 3500 ISPs (whose registration subscription service fees cover the bulk of ARIN's expenses, i.e. an average of several thousand dollars per ISP per year) In other fees, we have over 1000 end-user organization and presently about 800 legacy RSA holders which pay $100/year for maintenance. This doesn't really cover much expense, and that is quite appropriate since handling registration services requests (and the supporting public policy process) does dominant the expenses of ARIN, at least today. The question is how that evolves over time, particularly if the level of registration services requests in an post-IPv6 world is very modest. At that point, ARIN's expenses will be predominantly registry systems support, and whatever public policy process the community wishes us to maintain. These costs will need to be predominantly covered by the maintenance fees, and will support the objects in the database, which includes the resource records of 3500 ISPs, 1000+ enduser organizations, the signed LRSA holders, and estimated 15000 legacy resource holders who have not signed an LRSA... At the end of the day, the Board of Trustees will determine the best fee schedule to provide for cost-recovery of whatever functions are needed for the mission at that time. > So when you run into expensive stuff, like litigation, the best course of > action is to avoid it unless you absolutely can't. Correct. > Further, if you've suffered mission creep and are funding other things > such as IPv6 educational outreach, that's going to run up your costs as > well. Presently, IPv6 outreach is not considered "mission creep", as it has been an overwhelming request of the community both online and in the public policy meetings. > An established entity like ARIN typically has a very rough time going on > any sort of diet. Further, companies typically do not segregate their > "products" well: if IPv4 policy enforcement runs into legal wrangling > and lawsuits, ARIN as a whole gets sued, and it is tempting to spread > the resulting expenses over all their products. Segregation into two > (or more!) entities is a trivial way to fix that, though it also brings > about other challenges. Absolutely correct. I think it is possible to understand those costs better, but in some cases they can't be put into separate organizations without some changes to structural assumptions about ARIN's mission. > I have my doubts, based on a ~decade of observation. I don't think ARIN > is deliberately evil, but I think there are some bits that'd be hard to > fix. Joe - If you want to improve ARIN policy, jump right in. If you want to propose policy for the sake of changing the nature of the organization, that's also fine, if you contact me I'll assist in providing estimates of cost savings and structural changes that can result from your proposals. At the end of the day, it will be the community's discussion of your proposal, and the AC & Boards consideration of the discussion which will decide the matter. /John John Curran President and CEO ARIN From jgreco at ns.sol.net Fri Apr 9 07:27:28 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 9 Apr 2010 07:27:28 -0500 (CDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: from "Randy Bush" at Apr 09, 2010 05:12:11 PM Message-ID: <201004091227.o39CRSva030382@aurora.sol.net> [context restored] > > > If you don't have a contract with ARIN, why should ARIN provide > > > you with anything? > > [I replied] > > Because a legacy holder doesn't care about ARIN > > i do not think that statement is defensible > > there is a difference between caring and being willing to give up rights > for no benefit I meant in the context of an answer to the question above. A legacy holder doesn't really care _who_ is currently providing the services that InterNIC once provided. It doesn't matter to me if our legacy space is currently "handled" by ARIN, RIPE, APNIC, ICANN, or whatever. Put less tersely: We were assigned space, under a policy whose purpose was primarily to guarantee uniqueness in IPv4 numbering. As with other legacy holders, we obtained portable space to avoid the technical problems associated with renumbering, problems with in-addr.arpa subdelegation, etc. Part of that was an understanding that the space was ours (let's not get distracted by any "ownership" debate, but just agree for the sake of this point that it was definitely understood that we'd possess it). This served the good of the Internet by promoting stability within an AS and allowed us to spend engineering time on finer points (such as maintaining PTR's) rather than renumbering gear every time we changed upstreams. Eventually InterNIC was disbanded, and components went in various directions. ARIN landed the numbering assignment portion of InterNIC. Along with that, maintenance of the legacy resources drifted along to ARIN. ARIN might not have a contract with us, or with other legacy holders. It wasn't our choice for ARIN to be tasked with holding up InterNIC's end of things. However, it's likely that they've concluded that they better do so, because if they don't, it'll probably turn into a costly legal battle on many fronts, and I doubt ARIN has the budget for that. As a legacy holder, we don't really care who is currently "responsible" for legacy maintenance/etc. However, whoever it is, if they're not going to take on those responsibilities, that's a problem. The previous poster asked, "If you don't have a contract with ARIN, why should ARIN provide you with anything?" Well, the flip side to that is, "ARIN doesn't have a contract with us, but we still have copies of the InterNIC policies under which we were assigned space, and ARIN undertook those duties, so ARIN is actually the one with significant worries if they were to try to pull anything, otherwise, we don't really care." Is that a suitable defense of that statement (which might not have been saying quite what you thought)? ... 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 jcurran at istaff.org Fri Apr 9 07:34:36 2010 From: jcurran at istaff.org (John Curran) Date: Fri, 9 Apr 2010 08:34:36 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4BBE25C3.3010909@steadfast.net> References: <201004081536.o38FaMKQ025021@aurora.sol.net> <4BBE21CF.2040504@steadfast.net> <4BBE25C3.3010909@steadfast.net> Message-ID: On Apr 8, 2010, at 2:51 PM, Kevin Stange wrote: > > On 04/08/2010 01:47 PM, Dorn Hetzel wrote: >> If there was an automatic website that just handed out up to a /40 on >> demand, and charged a one-time fee of $100, I don't think the space >> would ever be exhausted, there isn't enough money. > > I'd hate to see that routing table. Another bright gentleman many years ago suggested that we have an online website which allows anyone to pay a fee and get an address block. This is not inconceivable, but does completely set aside hierarchical routing which is currently an underlying mechanism for making our addressing framework scalable. Another way to accomplish this would be a functional global model for the settlement of costs relating to routing entries, and which would effectively be against routing entries caused by unique "provider-independent" prefixes. ISPs today don't get specifically compensated for routing a PI address block, but they do get to participate in the various RIR processes and have some say in the impacts of public policies as they are discussed. Historically, this has proved to be sufficient input that ISPs generally respect the tradeoffs inherent in the approved policy, and will route the result. If you have an economic mechanism which handles this function instead, and an abundance of resources (e.g. IPv6), then it might be possible to operate under very different assumptions than the present Internet registry system, and the resulting costs of operating the registry portion could be minimal. The implementation of this is left as an exercise for the reader... /John p.s. These are my personal thoughts only and in no way reflect any position of ARIN or the ARIN Board of Trustees. I provide them solely to help outline some of the tradeoffs inherent in the current Registry system. From rsk at gsp.org Fri Apr 9 06:34:53 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 9 Apr 2010 07:34:53 -0400 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> Message-ID: <20100409113453.GA11452@gsp.org> On Thu, Apr 08, 2010 at 06:29:07PM -0600, Beavis wrote: > Is it possible for you to share that filter list you have for china? See ipdeny.com for allocations covering about 225 countries. Alternatively, please see http://www.okean.com/asianspamblocks.html for lists that cover China and Korea only. The former is furnished in CIDR; the latter in CIDR, Apache htaccess, Cisco ACL, and Linux iptables. ---Rsk From jcurran at arin.net Fri Apr 9 08:14:15 2010 From: jcurran at arin.net (John Curran) Date: Fri, 9 Apr 2010 09:14:15 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004091227.o39CRSva030382@aurora.sol.net> References: <201004091227.o39CRSva030382@aurora.sol.net> Message-ID: On Apr 9, 2010, at 8:27 AM, Joe Greco wrote: > Eventually InterNIC was disbanded, and components went in various > directions. ARIN landed the numbering assignment portion of InterNIC. > Along with that, maintenance of the legacy resources drifted along to > ARIN. Correct (ARIN is the successor registry) > ARIN might not have a contract with us, or with other legacy holders. > It wasn't our choice for ARIN to be tasked with holding up InterNIC's > end of things. However, it's likely that they've concluded that they > better do so, because if they don't, it'll probably turn into a costly > legal battle on many fronts, and I doubt ARIN has the budget for that. ARIN has a budget which includes legal reserves for contingencies such as these, but would need to have a clear direction supported by the community before taking any action in this area. > As a legacy holder, we don't really care who is currently "responsible" > for legacy maintenance/etc. However, whoever it is, if they're not > going to take on those responsibilities, that's a problem. > > The previous poster asked, "If you don't have a contract with ARIN, > why should ARIN provide you with anything?" > > Well, the flip side to that is, "ARIN doesn't have a contract with us, > but we still have copies of the InterNIC policies under which we were > assigned space, and ARIN undertook those duties, so ARIN is actually > the one with significant worries if they were to try to pull anything, > otherwise, we don't really care." Alas, Joe, ARIN will follow the policies directed by the community with respect to service provided to legacy address holders, and invites you to participate in that community to help establish those policies. If the community directs ARIN to provide some set of services to legacy address holders for free, or on a cost recovery, or whatever, ARIN will comply. You may not have realized it when you received your address allocation, but you were implicitly joining a community which includes the IAB/IETF, IANA, and ARIN, and opting to ignore that community does not necessarily mean you won't be affected by its policies. /John John Curran President and CEO ARIN From cmaurand at xyonet.com Fri Apr 9 08:58:21 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Fri, 09 Apr 2010 09:58:21 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <22087.1270676886@localhost> Message-ID: <4BBF327D.3020401@xyonet.com> On 4/8/2010 7:18 PM, Gary E. Miller wrote: > Since I just need one /64 that is $1,250/yr for the /64. > > That puts me at a large competitive disadvantage to the big boys. > According to the docs that I read that's 1250 for the first year and 100/yr thereafter. The big boys pay more up front, but pay $100.00 per year thereafter. There's the competitive disadvantage. AT&T, Comcast, Time-Warner pay $100.00/yr for huge address space while the little by pays $100.00/yr for a comparatively tiny one. Something's not quite right with that structure. Cheers, Curtis From Rod.Beck at hiberniaatlantic.com Fri Apr 9 08:59:40 2010 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Fri, 9 Apr 2010 14:59:40 +0100 Subject: FCC dealt major blow in net neutrality ruling favoring Comcast References: <42DF9B4B-8614-43F9-802D-9586AA7AD0FB@ianai.net> <4BBB8009.1060408@csuohio.edu> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB03957DBA@bert.HiberniaAtlantic.local> In Europe you rarely encounter courts circumscribing regulatory power. And it is well known that the District Court is dominated by anti-regulatory judges. -----Original Message----- From: Michael Holstein [mailto:michael.holstein at csuohio.edu] Sent: Tue 4/6/2010 7:40 PM To: Patrick W. Gilmore Cc: NANOG list Subject: Re: FCC dealt major blow in net neutrality ruling favoring Comcast > > > Seems on-topic, even though policy related. > From jcurran at arin.net Fri Apr 9 09:10:03 2010 From: jcurran at arin.net (John Curran) Date: Fri, 9 Apr 2010 10:10:03 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4BBF327D.3020401@xyonet.com> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <22087.1270676886@localhost> <4BBF327D.3020401@xyonet.com> Message-ID: <857E2DE9-8DBD-4829-8123-064AEFC63E60@arin.net> On Apr 9, 2010, at 9:58 AM, Curtis Maurand wrote: > > According to the docs that I read that's 1250 for the first year and 100/yr thereafter. The big boys pay more up front, but pay $100.00 per year thereafter. There's the competitive disadvantage. AT&T, Comcast, Time-Warner pay $100.00/yr for huge address space while the little by pays $100.00/yr for a comparatively tiny one. Something's not quite right with that structure. A large *end-user* pays maintenance fees of $100/year. ISPs pay an annual registration services subscription fee each year, proportional to the size of aggregate address space held. /John John Curran President and CEO ARIN From jcurran at arin.net Fri Apr 9 09:14:04 2010 From: jcurran at arin.net (John Curran) Date: Fri, 9 Apr 2010 10:14:04 -0400 Subject: ARIN XXV Policy Discussions References: <4BBF3404.5080209@arin.net> Message-ID: <23415B91-5C50-4E8D-AF3A-CB8EE77504BE@arin.net> One important note for NANOG folks - The ARIN XXV Public Policy and Members Meeting will be held in 10 days in Toronto. There are policy proposals which may effect you being discussed. You may participate in discussing these on the ARIN PPML mailing list or during the meeting via remote participation (details attached). My apologies for forwarding this message, but I would be remiss to not bring these policy discussions to your attention. Thank you! /John John Curran President and CEO ARIN Begin forwarded message: From: Member Services > Date: April 9, 2010 10:04:52 AM EDT To: arin-announce at arin.net Subject: [arin-announce] ARIN XXV Policy Discussions The ARIN XXV Public Policy and Members Meeting will be held very soon in Toronto. Whether you?re attending in person or participating remotely, be sure to review the agenda so you don?t miss your chance to share your thoughts during the policy discussions: Monday, 19 April 2010-3: Customer Confidentiality 2010-6: Simplified M&A transfer policy 2010-2: /24 End User Minimum Assignment Unit 2010-5: Reduce and Simplify IPv4 Initial Allocations Tuesday, 20 April 2010-7: Simplified IPv6 policy 2010-8: Rework of IPv6 assignment criteria 2010-4: Rework of IPv6 allocation criteria 2010-1: Waiting List for Unmet IPv4 Requests View the agenda for specific times at https://www.arin.net/ARIN-XXV/agenda.html. The agenda is subject to change, but we will make every effort not to change the times for policy discussions. We will be sending daily agenda updates to all attendees and registered remote participants. You can also follow us on Twitter @TeamARIN for schedule updates. Be sure to use the #arin25 tag for your own tweets about the meeting. Complete information on the text of the draft policies being discussed is available at https://www.arin.net/policy/proposals/. If you?re not able to be there in person, you can still take advantage of remote participation features that will allow your voice to be heard during critical policy discussions. In addition to following the video or audio webcast, you can read along with the live transcript, submit questions and comments, and vote in straw polls via Jabber chat. To register as a remote participant, learn more about the remote participation services, or access the meeting materials please go to https://www.arin.net/ARIN-XXV/remote.html. We look forward to your participation. Regards, Member Services American Registry for Internet Numbers (ARIN) From michael.holstein at csuohio.edu Fri Apr 9 09:27:36 2010 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Fri, 09 Apr 2010 10:27:36 -0400 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <031b01cad787$0fdf9c30$2f9ed490$@net> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <031b01cad787$0fdf9c30$2f9ed490$@net> Message-ID: <4BBF3958.2020600@csuohio.edu> >> Is it possible for you to share that filter list you have for china? >> im getting bogged down by those ssh-bruts as well coming in from >> china. >> >> Good ones available here : in several notations (including Cisco ACL) : http://www.okean.com/antispam/china.html Cheers, Michael Holstein Cleveland State University From tglassey at earthlink.net Fri Apr 9 09:30:31 2010 From: tglassey at earthlink.net (todd glassey) Date: Fri, 09 Apr 2010 07:30:31 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4BBE1341.2000706@sprunk.org> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <20100407194030.A3660@egps.egps.com> <4BBE1341.2000706@sprunk.org> Message-ID: <4BBF3A07.4010005@earthlink.net> On 4/8/2010 10:32 AM, Stephen Sprunk wrote: > On 07 Apr 2010 18:40, N. Yaakov Ziskind wrote: >> I don't think the issue is *money* (at least the big issue; money is >> *always* an issue), but rather the all-of-sudden jump from being >> unregulated to regulated, whatever that means. > > ARIN is not a regulator. The "jump" is from not paying for services > that you have no contract for to paying for services that you do have a > contract for. BULL SH*T, ARIN makes determinations as to how many IP addresses it will issue and in that sense it is exactly a regulator. > >> I would think multiple times before making that jump. Hence my suggestion to set up a separate organization to request IPv6 space, and thus not 'endanger' whatever I had before. >> > > Signing an RSA to get new space does not _in any way_ "endanger" or > otherwise affect legacy resources. Putting legacy resources under LRSA > (or RSA, if you wished) is a completely separate action and is, for now > at least, completely optional. You do not need to set up a separate > organization; all that does is waste your time and ARIN's. > > S > -------------- next part -------------- A non-text attachment was scrubbed... Name: tglassey.vcf Type: text/x-vcard Size: 133 bytes Desc: not available URL: From cmaurand at xyonet.com Fri Apr 9 09:46:29 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Fri, 09 Apr 2010 10:46:29 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <857E2DE9-8DBD-4829-8123-064AEFC63E60@arin.net> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <22087.1270676886@localhost> <4BBF327D.3020401@xyonet.com> <857E2DE9-8DBD-4829-8123-064AEFC63E60@arin.net> Message-ID: <4BBF3DC5.9000700@xyonet.com> On 4/9/2010 10:10 AM, John Curran wrote: > A large *end-user* pays maintenance fees of $100/year. ISPs > pay an annual registration services subscription fee each year, > proportional to the size of aggregate address space held. > > I stand corrected. I misunderstood the doc. I could never read. :-) --Curtis From bbillon-ml at splio.fr Fri Apr 9 10:17:39 2010 From: bbillon-ml at splio.fr (Benjamin BILLON) Date: Fri, 09 Apr 2010 17:17:39 +0200 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <4BBF3958.2020600@csuohio.edu> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <031b01cad787$0fdf9c30$2f9ed490$@net> <4BBF3958.2020600@csuohio.edu> Message-ID: <4BBF4513.3070909@splio.fr> So basically, the idea is to disconnect China's Internet even more than what it inflicts to itself? How fun. What was the FCC/Comcast case about again? I'm totally against this practice, but if you (stupidly) want to apply it, do it for good. http://ftp.apnic.net/stats/apnic/delegated-apnic-latest grep '|CN|ipv4|' and to get your network length from the number of IP in the range: $len=32-log($num_of_IP)/log(2) Michael Holstein a ?crit : >>> Is it possible for you to share that filter list you have for china? >>> im getting bogged down by those ssh-bruts as well coming in from >>> china. >>> >>> >>> > > Good ones available here : in several notations (including Cisco ACL) : > > http://www.okean.com/antispam/china.html > > Cheers, > > Michael Holstein > Cleveland State University > > From bobp+nanog at webster.tsc.com Fri Apr 9 10:13:20 2010 From: bobp+nanog at webster.tsc.com (Bob Poortinga) Date: Fri, 9 Apr 2010 11:13:20 -0400 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <4BBE3B2A.7070901@west.net> References: <4BBE3B2A.7070901@west.net> Message-ID: <20100409151320.GA12429@tico.tsc.com> Jay Hennigan writes: > We just got Cyclops alerts showing several of our prefixes sourced from > AS23474 propagating through AS4134. Anyone else? For the record, yes. Two of our blocks were announced via 7575 4134 23724 yesterday. First seen by Cyclops at 2010-04-08 15:57:13 UTC and lasted about 20 minutes. Does AS7575, Australian Academic and Reasearch Network, do any filtering? -- Bob Poortinga K9SQL Technology Service Corp. Bloomington, Indiana US From owen at delong.com Fri Apr 9 10:56:39 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Apr 2010 08:56:39 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004091109.o39B9JjB023629@aurora.sol.net> References: <201004091109.o39B9JjB023629@aurora.sol.net> Message-ID: On Apr 9, 2010, at 4:09 AM, Joe Greco wrote: >>> 1) Justify why we need a heavy bureaucracy such as ARIN for IPv6 >>> numbering resources, >> >> Because the members of ARIN (and the other four RIRs) want it that way. >> And because nobody has yet made a serious proposal to ICANN that >> would replace ARIN. > > Using the organization to justify the need for the organization is > circular reasoning. > He didn't use the organization. He used the members of the organizations. The fact is that the majority of the members of the organization(s) are sufficiently happy with the status quo that they have not seen fit to change it. If the members of ARIN want to change or eliminate the organization, it is within their power to do so. >>> 2) Tell me why something like the old pre-depletion pre-ARIN model >>> of InterNIC and just handing out prefixes with substantially less >>> paper-pushing wouldn't result in a cheaper-to-run RIR. >> >> Because the ARIN members, who pay most of ARIN's fees, are not >> complaining about the level of those fees. This means that they >> think the fees are cheap enough, or else they would demand that >> the fees be changed. All ARIN fees are set by the ARIN members. > > Again, ... > > Anyways, the non-answers to these questions are very illuminating. > While this may not be the answer you wanted, I do not think it is a non-answer. ARIN is a membership driven organization. The members have the power to change the organization. There will be another election this fall. If you think there is significant support for changing the organization, then you should run for the Board of Trustees and champion those changes. Owen From owen at delong.com Fri Apr 9 11:04:19 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Apr 2010 09:04:19 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <20100409112720.GA19230@minerva.redbrick.dcu.ie> References: <201004091109.o39B9JjB023629@aurora.sol.net> <20100409112720.GA19230@minerva.redbrick.dcu.ie> Message-ID: <517A869E-5E18-4175-A37C-338C3AF80147@delong.com> >> > This is an answer though. The vast majority of people who need address space in > North America are ARIN members. These ARIN members are happy with the current > organisation. If the set of people who need IP address tend towards being happy > with the current system, there is no reason to change it for a new system, > which they may not be happy with. Actually, I don't believe that is completely true. The vast majority of address space in North America is given to ARIN members. However, the vast majority of people who need address space in North America are end users, most of whom get their address space from ARIN members or descendent LIRs from ARIN members. In some cases, they are end users who get address space from ARIN but are not ARIN members. Some end users are ARIN members, but, I do not believe the majority of them are. I'm not saying there is anything wrong with it being this way, just that it is an important distinction in address consumption vs. membership. Owen From owen at delong.com Fri Apr 9 11:16:43 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Apr 2010 09:16:43 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <20100409113919.GC21811@merboo.mamista.net> References: <8889118F-25DC-42FE-9057-AD5FF1463F43@delong.com> <201004091121.o39BLkLL025885@aurora.sol.net> <20100409113919.GC21811@merboo.mamista.net> Message-ID: On Apr 9, 2010, at 4:39 AM, Martin Barry wrote: > $quoted_author = "Joe Greco" ; >> >>> Perhaps the true issue is that what you see as broken is perceived as "working >>> as intended" by much of the community and membership? >> >> That's a great point. Would you agree, then, that much of the community >> and membership implicitly sees little value in IPv6? > I really don't know how much or how little value is seen in IPv6 by "much" of the community. I see tremendous value in IPv6. I also see a number of flaws in IPv6 (failure to include a scalable routing paradigm, for example). Nonetheless, IPv4 is unsustainable going forward (NAT is bad enough, LSN is even worse). I do believe that IPv6 is being deployed and that deployment is accelerating. I'm actually in a pretty good position to see that happen since I have access to flow statistics for a good portion of the IPv6 internet. The IPv6 internet today is already carrying more traffic than the IPv4 internet carried 10 years ago. Many others see value in IPv6. Comcast and Verizon have both announced residential customer IPv6 trials. Google, You Tube and Netflix are all available as production services on IPv6. Yahoo has publicly announced plans to have production services on IPv6 in the near future although they have not yet announced specific dates. I leave it up to you to consider whether that constitutes "much" of the community or not. > Is that orthogonal to Owen's statement? > I don't see how the term orthogonal would apply here. > >> You can claim that's a bit of a stretch, but quite frankly, the RIR >> policies, the sketchy support by providers, the lack of v6 support in >> much common gear, and so many other things seem to be all conspiring >> against v6 adoption. I need only point to v6 adoption rates to support >> that statement. > > Which rates would those be? > > http://www.ipv6actnow.org/info/statistics/ > > IPv6 has had a slow start but it's certainly picking up. > IPv6 started approximately 20 years behind IPv4. It's already caught up with IPv4 traffic levels of 10 years ago. Deployment is accelerating and IPv4 will hit a sustainability wall in the near future. Owen From drc at virtualized.org Fri Apr 9 11:20:31 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 9 Apr 2010 06:20:31 -1000 Subject: Behold - the Address-Yenta! In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <4BBE118C.6070602@sprunk.org> <20100408183757.GA9681@vacation.karoshi.com> <20100408193932.GA10217@vacation.karoshi.com> <98D4754C-9F6F-4C12-8849-F0747C5E9136@arin.net> <30233E8E-2CC5-4347-93AD-8A3A8CF5C808@virtualized.org> <88FE8260-668C-435F-BBF0-45AA9EF929FD@arin.net> Message-ID: John, On Apr 9, 2010, at 1:43 AM, John Curran wrote: > ARIN's position follows RFC 2008 This seems to be contradicted by ARIN's (perfectly reasonable) policies regarding the assignment of provider independent address space to end users. As to whether addresses are assets, I suspect we'll have to wait until the courts rule. I'm sure folks at Networld+InterOp, Apple, HP, etc. will be quite surprised if the courts rule according to ARIN's views. > The question discussed is the practice of performing resource review as a > result of fraudulent applications. Actually, no. The question was whether the practice of creating a company to hold IP addresses then selling that company to another organization was considered by ARIN to be fraudulent. In the particular (historical) cases I'm aware of, the address space in question was legacy /24s and the transfers were done (as I understand it) according to ARIN policies of the time. Speaking personally (of course), I'll admit a certain lack of comfort with the idea of ARIN (or any RIR) acting as lawmaker, police, judge, jury, and (assuming RPKI gets deployed) executioner. Regards, -drc From owen at delong.com Fri Apr 9 11:30:08 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Apr 2010 09:30:08 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004091121.o39BLkLL025885@aurora.sol.net> References: <201004091121.o39BLkLL025885@aurora.sol.net> Message-ID: <9815F8F0-9337-4BCB-9941-9465437A2B1C@delong.com> > Put differently, you work in this arena too... you've presumably > talked to stakeholders. Can you list some of the reasons people have > provided for not adopting v6, and are any of them related to the v6 > policies regarding address space? Reasons: + Fear People simply fear deploying new technology to their environment. + Uncertainty The future is uncertain. Many people fail to realize that IPv4's future is even more uncertain than that of IPv6. + Doubt You are not the only one expressing doubt in IPv6. The reality, however, is that I think that LSN and a multi-layer NAT internet are even more worthy of doubt than IPv6. + Inertia Many people are approaching this like driving at night with the headlights off. They refuse to alter course until they can see the wall. There is a wall coming in two years whether you can see it or not. If you have not begun to deploy IPv6 (changed course), then there will soon come a point where the accident has already occurred, even though you cannot yet see the wall and have not yet made physical contact with it. A classic example of this phenomenon would be a certain large unsinkable ship where the captain chose to try and make better time to New York rather than use a lower speed to have time to avoid ice bergs. The ship never arrived in New York and its name became an adjective to describe large disasters. Owen From davei at otd.com Fri Apr 9 11:56:37 2010 From: davei at otd.com (Dave Israel) Date: Fri, 09 Apr 2010 12:56:37 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <9815F8F0-9337-4BCB-9941-9465437A2B1C@delong.com> References: <201004091121.o39BLkLL025885@aurora.sol.net> <9815F8F0-9337-4BCB-9941-9465437A2B1C@delong.com> Message-ID: <4BBF5C45.3070406@otd.com> On 4/9/2010 12:30 PM, Owen DeLong wrote: >> Put differently, you work in this arena too... you've presumably >> talked to stakeholders. Can you list some of the reasons people have >> provided for not adopting v6, and are any of them related to the v6 >> policies regarding address space? >> > Reasons: > (many excellent reasons removed) Let me just add on: +Bonus Fear: Because IPv6 deployments are small and vendors are still ironing out software, there's concern that deploying it in a production network could cause issues. (Whether or not this fear is legitimate with vendor x, y, or z isn't the issue. The fear exists.) +Bonus Uncertainty: There is a lack of consensus on how IPv6 is to be deployed. For example, look at the ongoing debates on point to point network sizes and the /64 network boundary in general. There's also no tangible benefit to deploying IPv6 right now, and the tangible danger that your v6 deployment will just have to be redone because there's some flaw in the current v6 protocol or best practices that will be uncovered. +Bonus Doubt: Because we've been told that "IPv4 will be dead in 2 years" for the last 20 years, and that "IPv6 will be deployed and a way of life in 2 years" for the past 10, nobody really believes it anymore. There's been an ongoing chant of "wolf" for so long, many people won't believe it until things are much, much worse. -Dave From drc at virtualized.org Fri Apr 9 12:02:12 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 9 Apr 2010 07:02:12 -1000 Subject: NAT444 vs IPv6 (was RE: legacy /8) In-Reply-To: <002401cad699$7761f810$6625e830$@org> References: <4BB65B39.8010902@mompl.net> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <19E7C0EA-03D9-43A4-9E65-57565F2144C2@virtualized.org> <002401cad699$7761f810$6625e830$@org> Message-ID: <586CF32C-43E7-4D32-90EE-E28C41266A2C@virtualized.org> On Apr 7, 2010, at 11:29 AM, Lee Howard wrote: >> Can you provide pointers to these analyses? Any evidence-backed data showing how CGN >> is more expensive would be very helpful. > > It depends. ... > That math may or may not make sense for your network.. Right. My question was more along the lines of pointers to written up case studies, empirical analyses, actual cost comparisons, etc. between CGNs and IPv6 that could be presented (in summarized form) to executives, government officials, etc. Regards, -drc From owen at delong.com Fri Apr 9 11:59:17 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Apr 2010 09:59:17 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004091227.o39CRSva030382@aurora.sol.net> References: <201004091227.o39CRSva030382@aurora.sol.net> Message-ID: > > Put less tersely: > > We were assigned space, under a policy whose purpose was primarily to > guarantee uniqueness in IPv4 numbering. As with other legacy holders, > we obtained portable space to avoid the technical problems associated > with renumbering, problems with in-addr.arpa subdelegation, etc. > So far, correct. > Part of that was an understanding that the space was ours (let's not > get distracted by any "ownership" debate, but just agree for the sake > of this point that it was definitely understood that we'd possess it). > This served the good of the Internet by promoting stability within an > AS and allowed us to spend engineering time on finer points (such as > maintaining PTR's) rather than renumbering gear every time we changed > upstreams. > This is fictitious unless you are claiming that your allocation predates: RFC2050 November, 1996 RFC1466 May, 1993 RFC1174 August, 1990 Prior to that, it was less clear, but, the concept was still generally justified need so long as that need persisted. > Eventually InterNIC was disbanded, and components went in various > directions. ARIN landed the numbering assignment portion of InterNIC. > Along with that, maintenance of the legacy resources drifted along to > ARIN. > Actually, ARIN was spun off from InterNIC (containing most of the same staff that had been doing the job at InterNIC) well before InterNIC was disbanded. > ARIN might not have a contract with us, or with other legacy holders. > It wasn't our choice for ARIN to be tasked with holding up InterNIC's > end of things. However, it's likely that they've concluded that they > better do so, because if they don't, it'll probably turn into a costly > legal battle on many fronts, and I doubt ARIN has the budget for that. > This is going to be one of those situations that could become a legal battle on many fronts either way. On the one hand you have legacy holders who have no contractual right to services from anyone (If you want to pursue InterNIC for failing to live up to whatever agreement you have/had with them, I wish you the very best of luck in that endeavor, especially since you don't have a written contract from them, either). On the other hand, in a relatively short timeframe, you are likely to have litigants asking why ARIN has failed to reclaim/reuse the underutilized IPv4 space sitting in so many legacy registrations. Which of those two bodies of litigants is larger or better funded is left as an exercise for the reader. Nonetheless, ARIN is going to be in an interesting position between those two groups (which one is rock and which is hard place is also left as an exercise for the reader) going forward regardless of what action is taken by ARIN in this area. That is why the legacy RSA is important. It represents ARIN trying very hard to codify and defend the rights of the legacy holders. > As a legacy holder, we don't really care who is currently "responsible" > for legacy maintenance/etc. However, whoever it is, if they're not > going to take on those responsibilities, that's a problem. > You assume that anyone is currently responsible. What documentation do you have that there is any such responsibility? As a point in fact, ARIN has, for the good of the community, extended the courtesy of maintaining those records and providing services to legacy holders free of charge because it is perceived as being in the best interests of the community. > The previous poster asked, "If you don't have a contract with ARIN, > why should ARIN provide you with anything?" > > Well, the flip side to that is, "ARIN doesn't have a contract with us, > but we still have copies of the InterNIC policies under which we were > assigned space, and ARIN undertook those duties, so ARIN is actually > the one with significant worries if they were to try to pull anything, > otherwise, we don't really care." > Could you please provide those to Steve Ryan, John Curran, and, ideally, I'd like to see them too. > Is that a suitable defense of that statement (which might not have > been saying quite what you thought)? > I don't know. I have yet to see the content of the documents which you claim are your defense. Owen From wavetossed at googlemail.com Fri Apr 9 12:05:43 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Fri, 9 Apr 2010 18:05:43 +0100 Subject: "Running out of IPv6" (Re: ARIN IP6 policy for those with legacyIP4 Space) In-Reply-To: References: <000601cad73d$2cac32a0$860497e0$@org> <201004081826.o38IQpfJ038982@aurora.sol.net> <4BBE24CC.2050803@unfix.org> <601EE254-AB0B-4126-8B7E-162B844B03CE@delong.com> <424EBE79812D4637BA6AC1B0A2AA5517@TAKA> Message-ID: > If you have downstream customers, even if they're just dialups, expect > to assign at least a /60 to each one. Many folks recommend /56 or /48. ARIN counts a /56 or a /48 per customer, your choice. There is no point in allocating less. More to the point, soon the IPv4 address shortage and the transition to IPv6 will hit the mainstream press, and hundred of writers will be writing advice columns about it. From their point of view, more for the customer at the same price is better, and I fully expect that they will be advising folks to make their ISP choice based on how much address space is allocated. If you allocate less than a /56 per customer, then you won't be able to sell to new customers or hang on to old ones. Just don't do it, because you are only damaging your own business. ARIN will not give you a discount or give you better terms just because you allocate a /60 to dialup customers. There is simply no benefit to you or to the networking community in allocating a prefix longer than /56. --Michael Dillon From owen at delong.com Fri Apr 9 12:04:35 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Apr 2010 10:04:35 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4BBF327D.3020401@xyonet.com> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <22087.1270676886@localhost> <4BBF327D.3020401@xyonet.com> Message-ID: <3BBAA47A-8B6C-4486-B650-B737E97B2D65@delong.com> On Apr 9, 2010, at 6:58 AM, Curtis Maurand wrote: > On 4/8/2010 7:18 PM, Gary E. Miller wrote: >> Since I just need one /64 that is $1,250/yr for the /64. >> >> That puts me at a large competitive disadvantage to the big boys. >> > > According to the docs that I read that's 1250 for the first year and 100/yr thereafter. The big boys pay more up front, but pay $100.00 per year thereafter. There's the competitive disadvantage. AT&T, Comcast, Time-Warner pay $100.00/yr for huge address space while the little by pays $100.00/yr for a comparatively tiny one. Something's not quite right with that structure. > > Cheers, > Curtis > No. AT&T, Comcast, Time-Warner are not End-Users. They are ISPs. They pay ISP fees. I believe each of the ones you mention are in the "X-large" category, thus paying $18,000/year, not $100/year. An ISP which needs less than a /40 (which currently has no supporting allocation policy) would pay $1250/year. However, the nature of current IPv6 allocation policy is that an ISP would get a /32 and the minimum ISP IPv6 fee would, therefore, be $2,250/year. An end user pays $1,250 for anything smaller than a /40 (usually a /48) once, then, $100/year thereafter for ALL of their resources. Owen From owen at delong.com Fri Apr 9 12:07:58 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Apr 2010 10:07:58 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4BBF3A07.4010005@earthlink.net> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <20100407194030.A3660@egps.egps.com> <4BBE1341.2000706@sprunk.org> <4BBF3A07.4010005@earthlink.net> Message-ID: <2BB98A16-3FC3-4DBE-B197-4614D8B3D2CE@delong.com> On Apr 9, 2010, at 7:30 AM, todd glassey wrote: > On 4/8/2010 10:32 AM, Stephen Sprunk wrote: >> On 07 Apr 2010 18:40, N. Yaakov Ziskind wrote: >>> I don't think the issue is *money* (at least the big issue; money is >>> *always* an issue), but rather the all-of-sudden jump from being >>> unregulated to regulated, whatever that means. >> >> ARIN is not a regulator. The "jump" is from not paying for services >> that you have no contract for to paying for services that you do have a >> contract for. > > BULL SH*T, ARIN makes determinations as to how many IP addresses it will > issue and in that sense it is exactly a regulator. > No, ARIN is not a regulator. Regulators have guns or access to people with guns to enforce the regulations that they enact. ARIN has no such power. The FCC is a regulator. The California PUC is a regulator. ARIN is not a regulator. Owen From vixie at isc.org Fri Apr 9 12:17:23 2010 From: vixie at isc.org (Paul Vixie) Date: Fri, 09 Apr 2010 17:17:23 +0000 Subject: China prefix hijack In-Reply-To: (Martin A. Brown's message of "Thu\, 8 Apr 2010 19\:45\:56 +0200") References: <20100408171935.GD30450@staff.dca.net> <001f01cad740$ccf0c390$4401a8c0@jgbpc> <20100408174405.GD4808@dan.olp.net> Message-ID: "Martin A. Brown" writes: > Just a note of confirmation that 23724 originated as many as 31847 > prefixes during an 18 minute window starting around 15:54 UTC. > They were prepending their own AS, and this is several orders of > magnitude more prefixes than they normally originate. a couple of times when CIX still existed, i fscked up badly and sent a full deaggregated table to some peers. (the perils of running BGP3 and BGP4 on the same router, plus on-the-job-training for yours truly.) it's also happened a half dozen times by fat fingers other than mine. then there are the people who advertise 0/0, and all the people who accept 0/0. historians may say of the nanog@ m/l archives, "much hilarity ensued." are we all freaking out especially much because this is coming from china today, and we suppose there must be some kind of geopolitical intent because china-vs-google's been in the news a lot today? i'm more inclined to blame the heavy solar wind this month and to assume that chinanet's routers don't use ECC on the RAM containing their RIBs and that chinanet's router jockeys are in quite a sweat about this bad publicity. -- Paul Vixie KI6YSY From rdobbins at arbor.net Fri Apr 9 12:23:02 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 9 Apr 2010 17:23:02 +0000 Subject: China prefix hijack In-Reply-To: References: <20100408171935.GD30450@staff.dca.net> <001f01cad740$ccf0c390$4401a8c0@jgbpc> <20100408174405.GD4808@dan.olp.net> Message-ID: <7A33430D-283C-4402-99F9-4E11DCE9C295@arbor.net> On Apr 10, 2010, at 12:17 AM, Paul Vixie wrote: > are we all freaking out especially much because this is coming from china today, and we suppose there must be some kind of geopolitical intent because china-vs-google's been in the news a lot today? There's been a fair amount of speculation that at least some of these incidents may be related to censorship mechanisms, and a further tendency to conflate them, rather than looking more closely at the dynamics of each occurrence. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From drc at virtualized.org Fri Apr 9 12:26:25 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 9 Apr 2010 07:26:25 -1000 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004081536.o38FaMKQ025021@aurora.sol.net> <4BBE21CF.2040504@steadfast.net> <4BBE25C3.3010909@steadfast.net> Message-ID: <3C21D416-1009-4F93-A6BF-D8995E91DD25@virtualized.org> On Apr 9, 2010, at 2:34 AM, John Curran wrote: > Another bright gentleman many years ago suggested that we have an online > website which allows anyone to pay a fee and get an address block. This > is not inconceivable, but does completely set aside hierarchical routing > which is currently an underlying mechanism for making our addressing > framework scalable. Doesn't end user PI assignment already do this? Note I'm not arguing against end user PI assignment policy, rather just making the observation that given IPv6 did not address routing scalability, the path we're heading down is obvious, the only question is how fast. The problem is that ARIN is getting in the way of people (some of which are ARIN members) dumping nitrous into the combustion chamber. This doesn't seem like a stable, long term viable situation to me. Regards, -drc From drc at virtualized.org Fri Apr 9 12:34:00 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 9 Apr 2010 07:34:00 -1000 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <2BB98A16-3FC3-4DBE-B197-4614D8B3D2CE@delong.com> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <20100407194030.A3660@egps.egps.com> <4BBE1341.2000706@sprunk.org> <4BBF3A07.4010005@earthlink.net> <2BB98A16-3FC3-4DBE-B197-4614D8B3D2CE@delong.com> Message-ID: Owen, On Apr 9, 2010, at 7:07 AM, Owen DeLong wrote: > No, ARIN is not a regulator. Regulators have guns or access to people with > guns to enforce the regulations that they enact. ARIN has no such power. I'm a little confused on the distinction you're making. Today, ARIN can remove whois data/reverse delegations as a way of enforcing 'regulations'. In the future, assuming RPKI is deployed, ARIN could, in theory, revoke the certification of a resource. While not a gun, these are means of coercion. Are you being literal when you say "gun" or figurative? Regards, -drc From drc at virtualized.org Fri Apr 9 12:36:03 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 9 Apr 2010 07:36:03 -1000 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004081536.o38FaMKQ025021@aurora.sol.net> Message-ID: <8BD18449-053C-47EE-8935-31C607086F70@virtualized.org> On Apr 8, 2010, at 11:32 AM, Michael Dillon wrote: > All ARIN fees are set by the ARIN members. No they are not. Regards, -drc From bill at herrin.us Fri Apr 9 12:43:50 2010 From: bill at herrin.us (William Herrin) Date: Fri, 9 Apr 2010 13:43:50 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <2BB98A16-3FC3-4DBE-B197-4614D8B3D2CE@delong.com> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <20100407194030.A3660@egps.egps.com> <4BBE1341.2000706@sprunk.org> <4BBF3A07.4010005@earthlink.net> <2BB98A16-3FC3-4DBE-B197-4614D8B3D2CE@delong.com> Message-ID: On Fri, Apr 9, 2010 at 1:07 PM, Owen DeLong wrote: > On Apr 9, 2010, at 7:30 AM, todd glassey wrote: >> BULL SH*T, ARIN makes determinations as to how many IP addresses it will >> issue and in that sense it is exactly a regulator. >> > No, ARIN is not a regulator. ?Regulators have guns or access to people with > guns to enforce the regulations that they enact. ARIN has no such power. > > The FCC is a regulator. ?The California PUC is a regulator. ARIN is not > a regulator. Last I heard, the FCC has access to people with law degrees not guns. Much like ARIN, really. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bross at pobox.com Fri Apr 9 12:50:32 2010 From: bross at pobox.com (Brandon Ross) Date: Fri, 9 Apr 2010 13:50:32 -0400 (EDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <20100407194030.A3660@egps.egps.com> <4BBE1341.2000706@sprunk.org> <4BBF3A07.4010005@earthlink.net> <2BB98A16-3FC3-4DBE-B197-4614D8B3D2CE@delong.com> Message-ID: On Fri, 9 Apr 2010, William Herrin wrote: > Last I heard, the FCC has access to people with law degrees not guns. > Much like ARIN, really. Oh really? So if I start using a frequency that requires a license and I don't have one, won't they tell me to stop? And if I say no, I won't stop, what happens then? Will they never call the cops and have them show up and forcibly shut down my equipment? And if I try to defend my equipment, will the cops not shoot me? Sorry, all government policies are enforced by guns. ARIN is not government, if I don't pay ARIN for my address space and keep using it anyway, no cops will show up at my door. Sure my upstreams may decide to shut off my announcements, but a gun never gets involved. -- Brandon Ross AIM: BrandonNRoss From jcurran at istaff.org Fri Apr 9 12:55:17 2010 From: jcurran at istaff.org (John Curran) Date: Fri, 9 Apr 2010 13:55:17 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <3C21D416-1009-4F93-A6BF-D8995E91DD25@virtualized.org> References: <201004081536.o38FaMKQ025021@aurora.sol.net> <4BBE21CF.2040504@steadfast.net> <4BBE25C3.3010909@steadfast.net> <3C21D416-1009-4F93-A6BF-D8995E91DD25@virtualized.org> Message-ID: <9CDB72CD-13E3-42B7-AE22-E54D3ED1D49E@istaff.org> On Apr 9, 2010, at 1:26 PM, David Conrad wrote: > Doesn't end user PI assignment already do this? Note I'm not arguing against end user PI assignment policy, rather just making the observation that given IPv6 did not address routing scalability, the path we're heading down is obvious, the only question is how fast. David, The ISPs participating in ARIN get to disusss the impact of various allocation thresholds on their routing during the policy development process. If you have a magic vendor machine issuing prefixes to all comers regardless of need, then the routing scalability problem becomes much, much poignant, and the ability of the community to course correct is zero. /John From stephen at sprunk.org Fri Apr 9 12:55:24 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 09 Apr 2010 12:55:24 -0500 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <20100407194030.A3660@egps.egps.com> <4BBE1341.2000706@sprunk.org> <4BBF3A07.4010005@earthlink.net> <2BB98A16-3FC3-4DBE-B197-4614D8B3D2CE@delong.com> Message-ID: <4BBF6A0C.4050002@sprunk.org> On 09 Apr 2010 12:34, David Conrad wrote: > On Apr 9, 2010, at 7:07 AM, Owen DeLong wrote: > >> No, ARIN is not a regulator. Regulators have guns or access to people with guns to enforce the regulations that they enact. ARIN has no such power. >> > I'm a little confused on the distinction you're making. Today, ARIN can remove whois data/reverse delegations as a way of enforcing 'regulations'. In the future, assuming RPKI is deployed, ARIN could, in theory, revoke the certification of a resource. While not a gun, these are means of coercion. Are you being literal when you say "gun" or figurative? > As Mao famously said, power grows from the barrel of a gun. Regulators have (either directly or indirectly) lots of guns at their disposal to enforce their will on those they regulate, i.e. their regulations have the force of law. In contrast, ARIN's policies do not have the force of law. If operators choose not to look in ARIN's WHOIS database to verify addresses are registered to some org, or they choose to use another RDNS provider, or they choose to use a RPKI certificate scheme not rooted at ARIN/ICANN, that is their choice and ARIN couldn't do a damn thing to stop them. ARIN has no guns. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From braaen at zcorum.com Fri Apr 9 12:56:33 2010 From: braaen at zcorum.com (Brian Raaen) Date: Fri, 9 Apr 2010 13:56:33 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> Message-ID: <201004091356.35322.braaen@zcorum.com> Unless the ip you takes belongs to the rbn, mafia, or a three letter government org. -- ---------------------- Brian Raaen Network Engineer braaen at zcorum.com On Friday 09 April 2010, Brandon Ross wrote: > On Fri, 9 Apr 2010, William Herrin wrote: > > > Last I heard, the FCC has access to people with law degrees not guns. > > Much like ARIN, really. > > Oh really? So if I start using a frequency that requires a license and I > don't have one, won't they tell me to stop? And if I say no, I won't > stop, what happens then? Will they never call the cops and have them show > up and forcibly shut down my equipment? And if I try to defend my > equipment, will the cops not shoot me? > > Sorry, all government policies are enforced by guns. > > ARIN is not government, if I don't pay ARIN for my address space and keep > using it anyway, no cops will show up at my door. Sure my upstreams may > decide to shut off my announcements, but a gun never gets involved. > > -- > Brandon Ross AIM: BrandonNRoss > > From bill at herrin.us Fri Apr 9 13:01:30 2010 From: bill at herrin.us (William Herrin) Date: Fri, 9 Apr 2010 14:01:30 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <20100407194030.A3660@egps.egps.com> <4BBE1341.2000706@sprunk.org> <4BBF3A07.4010005@earthlink.net> <2BB98A16-3FC3-4DBE-B197-4614D8B3D2CE@delong.com> Message-ID: On Fri, Apr 9, 2010 at 1:50 PM, Brandon Ross wrote: > On Fri, 9 Apr 2010, William Herrin wrote: >> Last I heard, the FCC has access to people with law degrees not guns. >> Much like ARIN, really. > > Oh really? ?So if I start using a frequency that requires a license and I > don't have one, won't they tell me to stop? ?And if I say no, I won't stop, > what happens then? Brandon, Fun movies notwithstanding, they generally issue a fine and work it through the civil courts. If you were doing something extraordinary, like jamming emergency communications, I expect they might well call the police for assistance. But those are police, not FCC agents, and they're acting as much on behalf of the folks whose signals you're jamming as they are on behalf of the FCC. You'll find that any of us (including ARIN) can summon police for assistance with assaults upon us. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From stephen at sprunk.org Fri Apr 9 13:05:07 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 09 Apr 2010 13:05:07 -0500 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <20100407194030.A3660@egps.egps.com> <4BBE1341.2000706@sprunk.org> <4BBF3A07.4010005@earthlink.net> <2BB98A16-3FC3-4DBE-B197-4614D8B3D2CE@delong.com> Message-ID: <4BBF6C53.6020209@sprunk.org> On 09 Apr 2010 12:43, William Herrin wrote: > On Fri, Apr 9, 2010 at 1:07 PM, Owen DeLong wrote: > >> On Apr 9, 2010, at 7:30 AM, todd glassey wrote: >> >>> BULL SH*T, ARIN makes determinations as to how many IP addresses it will issue and in that sense it is exactly a regulator. >>> >> No, ARIN is not a regulator. Regulators have guns or access to people with guns to enforce the regulations that they enact. ARIN has no such power. >> >> The FCC is a regulator. The California PUC is a regulator. ARIN is not a regulator. >> > Last I heard, the FCC has access to people with law degrees not guns. > Much like ARIN, really. > If you violate FCC regulations, their first step is to take you to court for violating their regulations, but if you ignore the court's ruling against you, people with guns (the FBI, IIRC) _will_ come stop your violations, whether that means putting you in jail or putting you in the ground. That is what "the force of law" means. ARIN's authority ends at the contract you signed with them, and their only remedy (not providing any further services) is specified in that contract. If you did not sign a contract with them, they have no authority at all--and no obligation to provide any services to you. ARIN policy therefore does _not_ have the force of law. You are free to ignore them if you wish, unlike a regulator. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From nanog at qualitymail.com Fri Apr 9 13:09:09 2010 From: nanog at qualitymail.com (William Duck) Date: Fri, 9 Apr 2010 11:09:09 -0700 Subject: capirca : Google Network Filtering Management Message-ID: <20100409110909.D5AF7078@resin14.mta.everyone.net> http://code.google.com/p/capirca/ Developed internally at Google, this system is designed to utilize common definitions of networks and services and high-level policy files to facilitate the development and manipulation of network access control filters (ACLs) for various platforms. __________________________________________________________________ Get your own *free* email address like this one from www.OwnEmail.com From jcurran at arin.net Fri Apr 9 13:09:54 2010 From: jcurran at arin.net (John Curran) Date: Fri, 9 Apr 2010 14:09:54 -0400 Subject: Behold - the Address-Yenta! In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <4BBE118C.6070602@sprunk.org> <20100408183757.GA9681@vacation.karoshi.com> <20100408193932.GA10217@vacation.karoshi.com> <98D4754C-9F6F-4C12-8849-F0747C5E9136@arin.net> <30233E8E-2CC5-4347-93AD-8A3A8CF5C808@virtualized.org> <88FE8260-668C-435F-BBF0-45AA9EF929FD@arin.net> Message-ID: <0F1FD061-0B19-4410-B851-F12E8C74EF2D@arin.net> On Apr 9, 2010, at 12:20 PM, David Conrad wrote: > >> The question discussed is the practice of performing resource review as a >> result of fraudulent applications. > > Actually, no. The question was whether the practice of creating a company to hold IP addresses then selling that company to another organization was considered by ARIN to be fraudulent. In the particular (historical) cases I'm aware of, the address space in question was legacy /24s and the transfers were done (as I understand it) according to ARIN policies of the time. David - I didn't say that "the practice of creating a company to hold IP addresses then selling that company to another organization" was considered fraudulent by ARIN. I asked that you please report such cases, as depending on the specific circumstances they are *potentially* fraudulent. > Speaking personally (of course), I'll admit a certain lack of comfort with the idea of ARIN (or any RIR) acting as lawmaker, police, judge, jury, and (assuming RPKI gets deployed) executioner. As a member of the community, you are free to propose changes to or elimination of the policies in the NRPM which you are not comfortable with; I expect that you will find them in sections 8 and 12. The policy development role is open to the community, but specifically not the ARIN Board and Staff, so there is perhaps a little more separation present than your email suggests. /John John Curran President and CEO ARIN From cscora at apnic.net Fri Apr 9 13:10:08 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 10 Apr 2010 04:10:08 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201004091810.o39IA8Fj025099@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. 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 10 Apr, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 317715 Prefixes after maximum aggregation: 146886 Deaggregation factor: 2.16 Unique aggregates announced to Internet: 154431 Total ASes present in the Internet Routing Table: 33740 Prefixes per ASN: 9.42 Origin-only ASes present in the Internet Routing Table: 29288 Origin ASes announcing only one prefix: 14309 Transit ASes present in the Internet Routing Table: 4452 Transit-only ASes present in the Internet Routing Table: 102 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (32374) 19 Prefixes from unregistered ASNs in the Routing Table: 555 Unregistered ASNs in the Routing Table: 134 Number of 32-bit ASNs allocated by the RIRs: 513 Prefixes from 32-bit ASNs in the Routing Table: 548 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 231 Number of addresses announced to Internet: 2194938368 Equivalent to 130 /8s, 212 /16s and 26 /24s Percentage of available address space announced: 59.2 Percentage of allocated address space announced: 65.8 Percentage of available address space allocated: 90.0 Percentage of address space in use by end-sites: 82.1 Total number of prefixes smaller than registry allocations: 152258 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 76202 Total APNIC prefixes after maximum aggregation: 26387 APNIC Deaggregation factor: 2.89 Prefixes being announced from the APNIC address blocks: 73052 Unique aggregates announced from the APNIC address blocks: 31963 APNIC Region origin ASes present in the Internet Routing Table: 3990 APNIC Prefixes per ASN: 18.31 APNIC Region origin ASes announcing only one prefix: 1096 APNIC Region transit ASes present in the Internet Routing Table: 625 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 507394112 Equivalent to 30 /8s, 62 /16s and 56 /24s Percentage of available APNIC address space announced: 79.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, 27/8, 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 132971 Total ARIN prefixes after maximum aggregation: 68737 ARIN Deaggregation factor: 1.93 Prefixes being announced from the ARIN address blocks: 105911 Unique aggregates announced from the ARIN address blocks: 40478 ARIN Region origin ASes present in the Internet Routing Table: 13621 ARIN Prefixes per ASN: 7.78 ARIN Region origin ASes announcing only one prefix: 5272 ARIN Region transit ASes present in the Internet Routing Table: 1347 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 724849952 Equivalent to 43 /8s, 52 /16s and 85 /24s Percentage of available ARIN address space announced: 61.7 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: 72807 Total RIPE prefixes after maximum aggregation: 42457 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 65774 Unique aggregates announced from the RIPE address blocks: 43269 RIPE Region origin ASes present in the Internet Routing Table: 14329 RIPE Prefixes per ASN: 4.59 RIPE Region origin ASes announcing only one prefix: 7421 RIPE Region transit ASes present in the Internet Routing Table: 2143 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 420904608 Equivalent to 25 /8s, 22 /16s and 126 /24s Percentage of available RIPE address space announced: 78.4 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, 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, 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: 28079 Total LACNIC prefixes after maximum aggregation: 6725 LACNIC Deaggregation factor: 4.18 Prefixes being announced from the LACNIC address blocks: 26436 Unique aggregates announced from the LACNIC address blocks: 13768 LACNIC Region origin ASes present in the Internet Routing Table: 1266 LACNIC Prefixes per ASN: 20.88 LACNIC Region origin ASes announcing only one prefix: 419 LACNIC Region transit ASes present in the Internet Routing Table: 216 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 24 Number of LACNIC addresses announced to Internet: 72079872 Equivalent to 4 /8s, 75 /16s and 218 /24s Percentage of available LACNIC address space announced: 71.6 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6671 Total AfriNIC prefixes after maximum aggregation: 1791 AfriNIC Deaggregation factor: 3.72 Prefixes being announced from the AfriNIC address blocks: 5006 Unique aggregates announced from the AfriNIC address blocks: 1510 AfriNIC Region origin ASes present in the Internet Routing Table: 354 AfriNIC Prefixes per ASN: 14.14 AfriNIC Region origin ASes announcing only one prefix: 101 AfriNIC Region transit ASes present in the Internet Routing Table: 79 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 15066112 Equivalent to 0 /8s, 229 /16s and 228 /24s Percentage of available AfriNIC address space announced: 44.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 1840 8405 478 Korea Telecom (KIX) 17488 1309 136 131 Hathway IP Over Cable Interne 4755 1301 289 146 TATA Communications formerly 7545 1099 201 105 TPG Internet Pty Ltd 4134 1027 20377 397 CHINANET-BACKBONE 17974 998 281 18 PT TELEKOMUNIKASI INDONESIA 9583 985 72 485 Sify Limited 24560 875 303 168 Bharti Airtel Ltd., Telemedia 4808 845 1586 214 CNCGROUP IP network: China169 9829 829 686 26 BSNL National Internet Backbo 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 4014 3838 296 bellsouth.net, inc. 4323 3836 1099 398 Time Warner Telecom 1785 1754 699 132 PaeTec Communications, Inc. 7018 1576 5760 1004 AT&T WorldNet Services 20115 1528 1502 657 Charter Communications 2386 1325 618 935 AT&T Data Communications Serv 3356 1232 10956 427 Level 3 Communications, LLC 6478 1187 247 182 AT&T Worldnet Services 11492 1150 222 14 Cable One 22773 1139 2605 71 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 35805 613 56 6 United Telecom of Georgia 3292 448 1899 390 TDC Tele Danmark 30890 440 100 204 Evolva Telecom 702 422 1870 333 UUNET - Commercial IP service 8551 401 356 37 Bezeq International 8866 397 117 18 Bulgarian Telecommunication C 3320 365 7072 319 Deutsche Telekom AG 3301 355 1413 316 TeliaNet Sweden 3215 348 3238 104 France Telecom Transpac 12479 331 576 5 Uni2 Autonomous System 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 1537 2956 240 UniNet S.A. de C.V. 10620 1020 229 169 TVCABLE BOGOTA 28573 898 732 85 NET Servicos de Comunicao S.A 7303 698 361 100 Telecom Argentina Stet-France 6503 542 171 212 AVANTEL, S.A. 22047 540 310 15 VTR PUNTO NET S.A. 18881 530 268 11 Global Village Telecom 7738 477 922 30 Telecomunicacoes da Bahia S.A 3816 457 195 70 Empresa Nacional de Telecomun 14117 455 30 13 Telefonica del Sur S.A. 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 936 445 10 TEDATA 24863 707 144 41 LINKdotNET AS number 36992 552 120 162 Etisalat MISR 3741 274 853 233 The Internet Solution 33776 262 14 11 Starcomms Nigeria Limited 2018 215 230 111 Tertiary Education Network 6713 176 167 12 Itissalat Al-MAGHRIB 29571 172 19 9 Ci Telecom Autonomous system 24835 138 78 11 RAYA Telecom - Egypt 29975 133 506 14 Vodacom 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 4014 3838 296 bellsouth.net, inc. 4323 3836 1099 398 Time Warner Telecom 4766 1840 8405 478 Korea Telecom (KIX) 1785 1754 699 132 PaeTec Communications, Inc. 7018 1576 5760 1004 AT&T WorldNet Services 8151 1537 2956 240 UniNet S.A. de C.V. 20115 1528 1502 657 Charter Communications 2386 1325 618 935 AT&T Data Communications Serv 17488 1309 136 131 Hathway IP Over Cable Interne 4755 1301 289 146 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3836 3438 Time Warner Telecom 1785 1754 1622 PaeTec Communications, Inc. 4766 1840 1362 Korea Telecom (KIX) 8151 1537 1297 UniNet S.A. de C.V. 17488 1309 1178 Hathway IP Over Cable Interne 4755 1301 1155 TATA Communications formerly 11492 1150 1136 Cable One 22773 1139 1068 Cox Communications, Inc. 18566 1059 1049 Covad Communications 6478 1187 1005 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 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 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 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.190.64.0/22 28683 Office des Postes et telecomm 41.202.96.0/19 29571 Ci Telecom Autonomous system 41.220.144.0/20 36918 ORASCOM TELECOM ALGERIE VSAT 41.220.159.0/24 36918 ORASCOM TELECOM ALGERIE VSAT 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 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:26 /11:66 /12:192 /13:391 /14:679 /15:1245 /16:11039 /17:5209 /18:8878 /19:18275 /20:22332 /21:22373 /22:29149 /23:28845 /24:166014 /25:973 /26:1208 /27:631 /28:137 /29:9 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2581 4014 bellsouth.net, inc. 4323 2346 3836 Time Warner Telecom 4766 1476 1840 Korea Telecom (KIX) 1785 1216 1754 PaeTec Communications, Inc. 11492 1061 1150 Cable One 17488 1061 1309 Hathway IP Over Cable Interne 18566 1040 1059 Covad Communications 7018 945 1576 AT&T WorldNet Services 10620 926 1020 TVCABLE BOGOTA 3356 840 1232 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:13 8:257 12:2002 13:10 15:23 16:3 17:8 20:26 24:1414 27:32 32:48 33:12 38:655 40:100 41:2020 44:3 46:1 47:26 52:6 55:5 56:2 57:24 58:711 59:580 60:433 61:1155 62:1037 63:1971 64:3819 65:2358 66:4167 67:1788 68:1052 69:2778 70:707 71:238 72:1842 73:2 74:2161 75:246 76:311 77:843 78:603 79:397 80:988 81:774 82:458 83:454 84:693 85:1031 86:382 87:686 88:327 89:1525 90:85 91:2713 92:438 93:1118 94:1389 95:577 96:233 97:297 98:541 99:26 109:447 110:294 111:481 112:244 113:261 114:385 115:612 116:1022 117:629 118:413 119:921 120:148 121:859 122:1401 123:873 124:1104 125:1291 128:208 129:205 130:160 131:560 132:246 133:17 134:196 135:44 136:223 137:168 138:254 139:94 140:479 141:137 142:375 143:379 144:468 145:52 146:428 147:168 148:583 149:283 150:151 151:171 152:274 153:170 154:2 155:327 156:199 157:324 158:107 159:364 160:315 161:177 162:269 163:169 164:401 165:521 166:509 167:404 168:801 169:157 170:735 171:48 172:2 173:627 174:651 175:73 178:28 180:373 181:4 182:34 183:241 184:28 186:347 187:290 188:1224 189:731 190:3605 192:5732 193:4642 194:3346 195:2794 196:1170 198:3557 199:3392 200:5259 201:1496 202:7955 203:8315 204:4060 205:2297 206:2523 207:3014 208:3893 209:3449 210:2516 211:1241 212:1707 213:1679 214:595 215:72 216:4471 217:1521 218:486 219:425 220:1112 221:389 222:316 End of report From cmaurand at xyonet.com Fri Apr 9 13:14:43 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Fri, 09 Apr 2010 14:14:43 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <20100407194030.A3660@egps.egps.com> <4BBE1341.2000706@sprunk.org> <4BBF3A07.4010005@earthlink.net> <2BB98A16-3FC3-4DBE-B197-4614D8B3D2CE@delong.com> Message-ID: <4BBF6E93.4080602@xyonet.com> On 4/9/2010 1:43 PM, William Herrin wrote: >> No, ARIN is not a regulator. Regulators have guns or access to >> people with >> guns to enforce the regulations that they enact. ARIN has no such power. >> >> The FCC is a regulator. The California PUC is a regulator. ARIN is not >> a regulator. >> > Last I heard, the FCC has access to people with law degrees not guns. > Much like ARIN, really. > ARIN can act by de-allocating your network and revoking your ASN's. They can't fine you, but if you violate the RSA, they can revoke your stuff. That seems regulatory to me. --Curtis From wbailey at gci.com Fri Apr 9 13:42:50 2010 From: wbailey at gci.com (Warren Bailey) Date: Fri, 9 Apr 2010 10:42:50 -0800 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4BBF6E93.4080602@xyonet.com> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <20100407194030.A3660@egps.egps.com> <4BBE1341.2000706@sprunk.org> <4BBF3A07.4010005@earthlink.net> <2BB98A16-3FC3-4DBE-B197-4614D8B3D2CE@delong.com> <4BBF6E93.4080602@xyonet.com> Message-ID: <09F712D9B8F7AF40BE523224B2487BA10D8E8147@dtn1mbx01.gci.com> Regulatory bodies can fine you. Not all regulation comes with guns, hippies. ;) And .. The FCC does have access to people with guns, as does any US Federal Agency. Try transmitting illegally on an FM band for a while and see who shows up. I'd be shocked if people with guns didn't arrive in record time. -----Original Message----- From: Curtis Maurand [mailto:cmaurand at xyonet.com] Sent: Friday, April 09, 2010 10:15 AM To: nanog at nanog.org Subject: Re: ARIN IP6 policy for those with legacy IP4 Space On 4/9/2010 1:43 PM, William Herrin wrote: >> No, ARIN is not a regulator. Regulators have guns or access to >> people with >> guns to enforce the regulations that they enact. ARIN has no such power. >> >> The FCC is a regulator. The California PUC is a regulator. ARIN is not >> a regulator. >> > Last I heard, the FCC has access to people with law degrees not guns. > Much like ARIN, really. > ARIN can act by de-allocating your network and revoking your ASN's. They can't fine you, but if you violate the RSA, they can revoke your stuff. That seems regulatory to me. --Curtis From heather.schiller at verizonbusiness.com Fri Apr 9 14:06:58 2010 From: heather.schiller at verizonbusiness.com (Schiller, Heather A (HeatherSkanks)) Date: Fri, 09 Apr 2010 19:06:58 +0000 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004082014.o38KE3WM051378@aurora.sol.net> References: <201004082014.o38KE3WM051378@aurora.sol.net> Message-ID: -----Original Message----- From: Joe Greco [mailto:jgreco at ns.sol.net] Sent: Thursday, April 08, 2010 4:14 PM To: John Payne Cc: NANOG list Subject: Re: ARIN IP6 policy for those with legacy IP4 Space > On Apr 8, 2010, at 11:36 AM, Joe Greco wrote: > > > IPv6-only content won't be meaningful for years yet, and IPv6-only > > eyeballs will necessarily be given ways to reach v4 for many years > > to come. > > So again, why do WE have to encourage YOU to adopt IPv6? > Why should WE care what you do to the point of creating new rules so YOU don't have to pay like everyone else? Flip it around: Why should WE care about IPv6? WE would have to sign an onerous RSA with ARIN, giving up some of our rights in the process. WE have sufficient IP space to sit it out awhile; by doing that, WE save cash in a tight economy. WE are not so large that we spend four figures without batting an eyelash, so that's attractive. You don't. No one is going to make you set up IPv6. If you don't ever want or need to reach v6 enabled hosts, that's fine... Depending on your business, you may never need to change. But maybe someday you will want to, and you can set up v6 then. For a lot of folks, especially ISP's and content providers, there is much to be gained by deploying early: operational experience, and competitive advantage. It may not all go smoothly, so the sooner folks who know they will need IPv6, get started, the more time they have to work out any kinks. I think that is one of the interesting things about this problem. Unlike y2k, the deadline is different for everyone - and depends a lot on what your business is. Seriously? "an onerous RSA" What, specifically, do you consider so onerous? Are there no other situations where you willingly give up certain rights in order to obtain a service, or for the betterment or stability of your community/society? When you purchase internet transit, you surely sign a contract that has some terms of service, including an Acceptable Use Policy. You likely give up the right to spam, host copyrighted works, the right to intentionally disrupt networks, etc. It's likely that your provider can terminate services for violations. Do you consider this onerous? Even if you did, it didn't stop you from purchasing service. Further, anyone who is providing IPv6-only content has cut off most of the Internet, so basically no significant content is available on IPv6- only. That means there is no motivation for US to jump on the IPv6 bandwagon. Even more, anyone who is on an IPv6-only eyeball network is cut off from most of the content of the Internet; this means that ISP's will be having to provide IPv6-to-v4 services. Either they'll be good, or if customers complain, WE will be telling them how badly their ISP sucks. *I* am personally convinced that IPv6 is great, but on the other hand, I do not see so much value in v6 that I am prepared to compel the budgeting for ARIN v6 fees, especially since someone from ARIN just described all the ways in which they fritter away money. You can get IPv6 addresses from your upstream provider, often times free of charge, you don't ever have to deal with ARIN if you don't want to. You won't ever have to sign and agreement with ARIN if you don't want to. But, if you want to get a direct allocation, you got to pay to play - and also, agree to play by the same rules that everyone else is - it's a social contract of sorts- give up some rights in order to gain some benefits. As a result, the state of affairs simply retards the uptake and adoption of v6 among networks that would otherwise be agreeable to the idea; so, tell me, do you see that as being beneficial to the Internet community at large, or not? Note that I'm taking a strongly opposing stance for the sake of debate, the reality is a bit softer. Given a moderately good offer, we'd almost certainly adopt IPv6. "Moderately good offer" Like getting a prefix from your provider? Probably for free, without signing anything from ARIN. Have you talked to your provider? Or a certain well known tunnel broker will give you a /48 along w/ a free tunnel. http://nlayer.net/ipv6 route-views6.routeviews.org> sh bgp ipv6 2001:0590:0000:0000:0000:0000:0000:0000/32 BGP routing table entry for 2001:590::/32 Paths: (15 available, best #6, table Default-IP-Routing-Table) Not advertised to any peer 33437 6939 4436 2001:4810::1 from 2001:4810::1 (66.117.34.140) Origin IGP, localpref 100, valid, external Last update: Thu Apr 8 20:43:30 2010 ... 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 jeroen at mompl.net Fri Apr 9 14:13:58 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 09 Apr 2010 12:13:58 -0700 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <20100409113453.GA11452@gsp.org> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <20100409113453.GA11452@gsp.org> Message-ID: <4BBF7C76.7030706@mompl.net> Rich Kulawiec wrote: > See ipdeny.com for allocations covering about 225 countries. Alternatively, > please see http://www.okean.com/asianspamblocks.html for lists that cover > China and Korea only. The former is furnished in CIDR; the latter in CIDR, > Apache htaccess, Cisco ACL, and Linux iptables. Thanks, the iptables list comes in quite handy. People may wish to block port 22 as well as port 25. Although something like fail2ban takes care of that nicely. Greetings, Jeroen From wbailey at gci.com Fri Apr 9 14:31:18 2010 From: wbailey at gci.com (Warren Bailey) Date: Fri, 9 Apr 2010 11:31:18 -0800 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <4BBF7C76.7030706@mompl.net> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <20100409113453.GA11452@gsp.org> <4BBF7C76.7030706@mompl.net> Message-ID: <09F712D9B8F7AF40BE523224B2487BA10D8E8194@dtn1mbx01.gci.com> Are we to believe that filtering .cn will filter all Chinese attacks? I know that if I was up to no good in China, I'd buy a cheap VSAT connection, tld's are probably not a good way to identify bad guys. My two cents.. //warren -----Original Message----- From: Jeroen van Aart [mailto:jeroen at mompl.net] Sent: Friday, April 09, 2010 11:14 AM To: nanog at nanog.org Subject: Re: BGP hijack from 23724 -> 4134 China? Rich Kulawiec wrote: > See ipdeny.com for allocations covering about 225 countries. Alternatively, > please see http://www.okean.com/asianspamblocks.html for lists that cover > China and Korea only. The former is furnished in CIDR; the latter in CIDR, > Apache htaccess, Cisco ACL, and Linux iptables. Thanks, the iptables list comes in quite handy. People may wish to block port 22 as well as port 25. Although something like fail2ban takes care of that nicely. Greetings, Jeroen From wavetossed at googlemail.com Fri Apr 9 14:40:02 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Fri, 9 Apr 2010 20:40:02 +0100 Subject: Behold - the Address-Yenta! In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <20100408193932.GA10217@vacation.karoshi.com> <98D4754C-9F6F-4C12-8849-F0747C5E9136@arin.net> <30233E8E-2CC5-4347-93AD-8A3A8CF5C808@virtualized.org> <88FE8260-668C-435F-BBF0-45AA9EF929FD@arin.net> Message-ID: >> The question discussed is the practice of performing resource review >> as a result of fraudulent applications. > > no. ?what was being discussed was transfers. ?you turned left, asserted > that they were fraudulent, and told people to turn in their neighbors. If a company can justify a /?? with ARIN, they are free to turn around and pay someone else for a /?? or less. They can even buy a corporate shell that has a registered address range and it is not fraudulent. Where fraud enters the picture is where the buyer is doing an end run around ARIN policy and buys a /?? which they cannot justify under ARIN rules. Or, when they buy a corporate shell that has the same name as the registrant of a legacy address range, but that corporate shell is not actually the successor of the company who originally registered the addresses. The group of neighbors who depend on IP addresses for their organization's networks and internetworks, have gathered together in the IETF and later in ARIN, to set up some ground rules for how IP addresses are managed. The process is open, and transparent and based on the necessities of limited supply and technical details of IP routing. Yes, if someone is cheating the rest of their neighbors then you should turn them in. --Michael Dillon From jeroen at mompl.net Fri Apr 9 14:56:49 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 09 Apr 2010 12:56:49 -0700 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <4BBF4513.3070909@splio.fr> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <031b01cad787$0fdf9c30$2f9ed490$@net> <4BBF3958.2020600@csuohio.edu> <4BBF4513.3070909@splio.fr> Message-ID: <4BBF8681.20306@mompl.net> Benjamin BILLON wrote: > So basically, the idea is to disconnect China's Internet even more than > what it inflicts to itself? And that is wrong why exactly? ;-) > How fun. What was the FCC/Comcast case about again? It's only port 25, at least here: http://www.okean.com/antispam/iptables/iptables.html From wavetossed at googlemail.com Fri Apr 9 15:31:43 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Fri, 9 Apr 2010 21:31:43 +0100 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <8BD18449-053C-47EE-8935-31C607086F70@virtualized.org> References: <201004081536.o38FaMKQ025021@aurora.sol.net> <8BD18449-053C-47EE-8935-31C607086F70@virtualized.org> Message-ID: On 9 April 2010 18:36, David Conrad wrote: > On Apr 8, 2010, at 11:32 AM, Michael Dillon wrote: >> All ARIN fees are set by the ARIN members. > > No they are not. According to : The Fee Schedule, is continually reviewed by ARIN's membership, and its Advisory Council, and Board of Trustees to identify ways in which ARIN can improve service to the community and to ensure that ARIN's operational needs are met Since the AC and Board of Trustees are elected by the Members, ultimately the members have control of fees. -- Michael Dillon From jimtempl at att.net Fri Apr 9 15:38:33 2010 From: jimtempl at att.net (Jim Templin) Date: Fri, 9 Apr 2010 13:38:33 -0700 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <09F712D9B8F7AF40BE523224B2487BA10D8E8194@dtn1mbx01.gci.com> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <20100409113453.GA11452@gsp.org> <4BBF7C76.7030706@mompl.net> <09F712D9B8F7AF40BE523224B2487BA10D8E8194@dtn1mbx01.gci.com> Message-ID: <000b01cad824$a2ddd630$e8998290$@net> -----Original Message----- From: Warren Bailey [mailto:wbailey at gci.com] Sent: Friday, April 09, 2010 12:31 PM To: Jeroen van Aart; nanog at nanog.org Subject: RE: BGP hijack from 23724 -> 4134 China? Are we to believe that filtering .cn will filter all Chinese attacks? I know that if I was up to no good in China, I'd buy a cheap VSAT connection, tld's are probably not a good way to identify bad guys. My two cents.. //warren -------------------------- As was pointed out that might have been the point of hijacking IP space from outside cn.net. -Jim From bbillon-ml at splio.fr Fri Apr 9 15:49:56 2010 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Fri, 09 Apr 2010 22:49:56 +0200 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <4BBF8681.20306@mompl.net> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <031b01cad787$0fdf9c30$2f9ed490$@net> <4BBF3958.2020600@csuohio.edu> <4BBF4513.3070909@splio.fr> <4BBF8681.20306@mompl.net> Message-ID: <4BBF92F4.1030700@splio.fr> >> So basically, the idea is to disconnect China's Internet even more >> than what it inflicts to itself? > And that is wrong why exactly? ;-) Nah, I'm not answering that =D Nice try, though. >> How fun. What was the FCC/Comcast case about again? > It's only port 25, at least here: > http://www.okean.com/antispam/iptables/iptables.html This is also blocking Sina, Netease, Yahoo.cn and other major Chinese ISP/ESP. Am I the only to think this is not very smart? If you think Chinese DUL would be interesting, please tell me. From joe at via.net Fri Apr 9 16:22:38 2010 From: joe at via.net (joe mcguckin) Date: Fri, 9 Apr 2010 14:22:38 -0700 Subject: FCC dealt major blow in net neutrality ruling favoring Comcast In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB03957DBA@bert.HiberniaAtlantic.local> References: <42DF9B4B-8614-43F9-802D-9586AA7AD0FB@ianai.net> <4BBB8009.1060408@csuohio.edu> <1E8B940C5E21014AB8BE70B975D40EDB03957DBA@bert.HiberniaAtlantic.local> Message-ID: Let me see if I understand this correctly. People are defending the FCC? The same FCC that ruled that any data service over 200Kbits was broadband, not "Information Service" and thus came under the purview of the FBI and CALEA - directly contravening the language and intent of the CALEA act? Sometimes the enemy of your enemy is just your enemy. Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax On Apr 9, 2010, at 6:59 AM, Rod Beck wrote: > In Europe you rarely encounter courts circumscribing regulatory power. > > And it is well known that the District Court is dominated by anti-regulatory judges. > > > -----Original Message----- > From: Michael Holstein [mailto:michael.holstein at csuohio.edu] > Sent: Tue 4/6/2010 7:40 PM > To: Patrick W. Gilmore > Cc: NANOG list > Subject: Re: FCC dealt major blow in net neutrality ruling favoring Comcast > > >> >> >> Seems on-topic, even though policy related. >> From fred at cisco.com Fri Apr 9 16:33:14 2010 From: fred at cisco.com (Fred Baker) Date: Fri, 9 Apr 2010 14:33:14 -0700 Subject: FCC dealt major blow in net neutrality ruling favoring Comcast In-Reply-To: <20100407235116.7773cab2@opy.nosense.org> References: <42DF9B4B-8614-43F9-802D-9586AA7AD0FB@ianai.net> <20100407235116.7773cab2@opy.nosense.org> Message-ID: <74414BAD-CD34-4039-BFC7-8C493190EBB9@cisco.com> On Apr 7, 2010, at 7:21 AM, Mark Smith wrote: > One thing which would significantly help this argument for or against Network Neutrality is defining exactly what it is. The FCC has a definition of sorts, in terms of its six principles. Page three of http://www.fcc.gov/Daily_Releases/Daily_Business/2009/db1022/DOC-294152A1.pdf gives you those. From morrowc.lists at gmail.com Fri Apr 9 16:57:00 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 9 Apr 2010 17:57:00 -0400 Subject: capirca : Google Network Filtering Management In-Reply-To: <20100409110909.D5AF7078@resin14.mta.everyone.net> References: <20100409110909.D5AF7078@resin14.mta.everyone.net> Message-ID: On Fri, Apr 9, 2010 at 2:09 PM, William Duck wrote: > ? http://code.google.com/p/capirca/ > ? Developed internally at Google, this system is designed to utilize > ? common definitions of networks and services and high-level policy > ? files to facilitate the development and manipulation > ? of network access control filters (ACLs) for various platforms. would be interesting (to the community to get the authors to present some material about this at a meeting? (a nanog meeting) -Chris From cidr-report at potaroo.net Fri Apr 9 17:00:03 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 Apr 2010 22:00:03 GMT Subject: BGP Update Report Message-ID: <201004092200.o39M038Q044616@wattle.apnic.net> BGP Update Report Interval: 01-Apr-10 -to- 08-Apr-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6298 40434 4.5% 15.5 -- ASN-CXA-PH-6298-CBS - Cox Communications Inc. 2 - AS23724 34670 3.8% 2.7 -- CHINANET-IDC-BJ-AP IDC, China Telecommunications Corporation 3 - AS20115 13023 1.4% 9.3 -- CHARTER-NET-HKY-NC - Charter Communications 4 - AS28477 11412 1.2% 1268.0 -- Universidad Autonoma del Esstado de Morelos 5 - AS25620 10855 1.2% 81.6 -- COTAS LTDA. 6 - AS6713 10746 1.2% 64.3 -- IAM-AS 7 - AS7643 10563 1.2% 97.8 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 8 - AS9829 10191 1.1% 15.8 -- BSNL-NIB National Internet Backbone 9 - AS12479 8848 1.0% 384.7 -- UNI2-AS Uni2 - Lince telecomunicaciones 10 - AS33475 8524 0.9% 36.3 -- RSN-1 - RockSolid Network, Inc. 11 - AS26025 8251 0.9% 8251.0 -- COC - City of Calgary 12 - AS16569 7967 0.9% 7967.0 -- ASN-CITY-OF-CALGARY - City of Calgary 13 - AS4847 7556 0.8% 23.1 -- CNIX-AP China Networks Inter-Exchange 14 - AS9116 6267 0.7% 12.4 -- GOLDENLINES-ASN 012 Smile Communications Main Autonomous System 15 - AS24560 6070 0.7% 15.6 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 16 - AS17964 5382 0.6% 36.6 -- DXTNET Beijing Dian-Xin-Tong Network Technologies Co., Ltd. 17 - AS41900 5345 0.6% 205.6 -- ORACLE-AS Oracle Investments Group 18 - AS33776 5296 0.6% 26.2 -- STARCOMMS-ASN 19 - AS14420 5285 0.6% 13.2 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 20 - AS17974 5206 0.6% 6.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS26025 8251 0.9% 8251.0 -- COC - City of Calgary 2 - AS16569 7967 0.9% 7967.0 -- ASN-CITY-OF-CALGARY - City of Calgary 3 - AS5691 2624 0.3% 2624.0 -- MITRE-AS-5 - The MITRE Corporation 4 - AS34919 2266 0.2% 2266.0 -- MONTAN-NET IP upstream provider network of Montan Telecom AG, Vaduz, Liechtenstein 5 - AS28477 11412 1.2% 1268.0 -- Universidad Autonoma del Esstado de Morelos 6 - AS50181 619 0.1% 619.0 -- GAX-KABELSZAT KabelszatNet-2002. Musoreloszto es Kereskedelmi Kft. 7 - AS42214 605 0.1% 605.0 -- IWC-AS SC International Work Company SRL 8 - AS5963 551 0.1% 551.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 9 - AS28052 495 0.1% 495.0 -- Arte Radiotelevisivo Argentino 10 - AS11613 453 0.1% 453.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 11 - AS45960 421 0.1% 421.0 -- YTLCOMMS-AS-AP YTL COMMUNICATIONS SDN BHD 12 - AS35291 822 0.1% 411.0 -- ICOMM-AS SC Internet Communication Systems SRL 13 - AS22395 410 0.1% 410.0 -- GHCO-INTERNAP - Goldenberg Hehmeyer 14 - AS32794 789 0.1% 394.5 -- ICFG - International Church of the Foursquare Gospel 15 - AS12479 8848 1.0% 384.7 -- UNI2-AS Uni2 - Lince telecomunicaciones 16 - AS30332 370 0.0% 370.0 -- EBUS-GENET - Partylite Gifts, Inc. 17 - AS10445 2180 0.2% 363.3 -- HTG - Huntleigh Telcom 18 - AS36892 348 0.0% 348.0 -- AFSAT_TZ 19 - AS19647 4031 0.4% 268.7 -- HPOD20001 - Hewlett-Packard Operation Division 20 - AS16868 537 0.1% 268.5 -- PRAXAIR-INC - Praxair Inc TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 200.13.36.0/24 11292 1.1% AS28477 -- Universidad Autonoma del Esstado de Morelos 2 - 208.98.231.0/24 8251 0.8% AS26025 -- COC - City of Calgary 3 - 208.98.230.0/24 7967 0.8% AS16569 -- ASN-CITY-OF-CALGARY - City of Calgary 4 - 85.60.194.0/23 2817 0.3% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 5 - 206.184.16.0/24 2792 0.3% AS174 -- COGENT Cogent/PSI 6 - 192.12.120.0/24 2624 0.3% AS5691 -- MITRE-AS-5 - The MITRE Corporation 7 - 203.162.118.128/ 2517 0.2% AS7643 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 8 - 222.255.186.0/25 2516 0.2% AS7643 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 9 - 196.44.176.0/20 2441 0.2% AS31856 -- CABSAS 12 - 85.204.64.0/23 2349 0.2% AS6746 -- ASTRAL UPC Romania Srl, Romania 13 - 193.238.204.0/22 2266 0.2% AS34919 -- MONTAN-NET IP upstream provider network of Montan Telecom AG, Vaduz, Liechtenstein 14 - 85.60.192.0/23 2213 0.2% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 15 - 124.14.224.0/19 1687 0.2% AS4847 -- CNIX-AP China Networks Inter-Exchange 16 - 124.254.32.0/19 1686 0.2% AS4847 -- CNIX-AP China Networks Inter-Exchange 17 - 124.14.64.0/18 1686 0.2% AS4847 -- CNIX-AP China Networks Inter-Exchange 18 - 143.138.107.0/24 1594 0.2% AS747 -- TAEGU-AS - Headquarters, USAISC 19 - 180.233.225.0/24 1514 0.1% AS38680 -- CMBHK-AS-KR CMB 20 - 85.60.208.0/21 1490 0.1% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 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 Apr 9 17:00:01 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 Apr 2010 22:00:01 GMT Subject: The Cidr Report Message-ID: <201004092200.o39M0162044601@wattle.apnic.net> This report has been generated at Fri Apr 9 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 02-04-10 319323 196232 03-04-10 319154 196271 04-04-10 319087 196340 05-04-10 319110 196496 06-04-10 319260 196788 07-04-10 319667 196864 08-04-10 320046 197056 09-04-10 319885 197303 AS Summary 34115 Number of ASes in routing system 14558 Number of ASes announcing only one prefix 4419 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 97058304 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'). --- 09Apr10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 320231 197232 122999 38.4% All ASes AS6389 4015 302 3713 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4419 1331 3088 69.9% TWTC - tw telecom holdings, inc. AS4766 1840 492 1348 73.3% KIXS-AS-KR Korea Telecom AS4755 1301 207 1094 84.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1139 76 1063 93.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS1785 1754 717 1037 59.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS18566 1059 33 1026 96.9% COVAD - Covad Communications Co. AS17488 1309 338 971 74.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1538 622 916 59.6% Uninet S.A. de C.V. AS7545 1119 250 869 77.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS19262 1089 247 842 77.3% VZGNI-TRANSIT - Verizon Internet Services Inc. AS10620 1027 197 830 80.8% Telmex Colombia S.A. AS6478 1187 447 740 62.3% ATT-INTERNET3 - AT&T WorldNet Services AS5668 807 199 608 75.3% AS-5668 - CenturyTel Internet Holdings, Inc. AS24560 874 274 600 68.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4808 845 250 595 70.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 678 84 594 87.6% MPX-AS Microplex PTY LTD AS7303 699 109 590 84.4% Telecom Argentina S.A. AS18101 686 97 589 85.9% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS8452 939 356 583 62.1% TEDATA TEDATA AS7018 1568 998 570 36.4% ATT-INTERNET4 - AT&T WorldNet Services AS17908 772 242 530 68.7% TCISL Tata Communications AS3356 1232 706 526 42.7% LEVEL3 Level 3 Communications AS35805 613 96 517 84.3% UTG-AS United Telecom AS AS4780 670 169 501 74.8% SEEDNET Digital United Inc. AS22047 540 47 493 91.3% VTR BANDA ANCHA S.A. AS17676 572 84 488 85.3% GIGAINFRA Softbank BB Corp. AS9443 555 74 481 86.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7011 1111 664 447 40.2% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS7738 477 30 447 93.7% Telecomunicacoes da Bahia S.A. Total 36434 9738 26696 73.3% Top 30 total Possible Bogus Routes 2.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.190.64.0/22 AS28683 BENINTELECOM 41.202.96.0/19 AS29571 CITelecom-AS 41.220.144.0/20 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 41.220.159.0/24 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 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 AS26452 BRING-AS - BringCom, Inc. 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.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales Telesat S.A. 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 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 78.41.80.0/24 AS29158 DE-IP69 Tux-Service 78.41.81.0/24 AS29158 DE-IP69 Tux-Service 78.41.82.0/24 AS29158 DE-IP69 Tux-Service 78.41.83.0/24 AS29158 DE-IP69 Tux-Service 78.41.84.0/24 AS29158 DE-IP69 Tux-Service 78.41.86.0/24 AS29158 DE-IP69 Tux-Service 78.41.87.0/24 AS29158 DE-IP69 Tux-Service 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 80.250.32.0/22 AS21452 SKANNET-IBADAN SKANNET IP Network 80.250.32.0/23 AS21452 SKANNET-IBADAN SKANNET IP Network 80.250.34.0/23 AS21452 SKANNET-IBADAN SKANNET IP Network 91.142.134.0/24 AS174 COGENT Cogent/PSI 110.34.40.0/22 AS24399 ABN-PEERING-AS-AP Asia Broadcast Networks Peering 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. 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 119.42.144.0/21 AS45753 NETSEC-HK Unit 1205-1207 119.42.144.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.145.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.146.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.147.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.148.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.149.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.150.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.151.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.160.200.0/23 AS45122 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 181.82.15.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.45.0/24 AS38414 GOESH-AS-KR Gyeonggi siheung office of education 181.82.46.0/24 AS38414 GOESH-AS-KR Gyeonggi siheung office of education 181.82.47.0/24 AS38414 GOESH-AS-KR Gyeonggi siheung office of education 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 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.45.0/24 AS2905 TICSA-ASN 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.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS 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.29.40.0/22 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 196.32.96.0/20 AS33787 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.254.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 AS33052 VZUNET - Verizon Data Services 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.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 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 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.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - 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.52.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company 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.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.77.138.0/23 AS24487 202.79.224.0/21 AS9519 VERTELNET Vertical Telecoms Pty Ltd 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.89.8.0/22 AS6648 BAYAN-TELECOMMUNICATIONS Bayan Telecommunications, Inc. 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.146.184.0/23 AS24487 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.166.166.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 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.179.154.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.124.96.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.124.100.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.124.104.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.160.130.0/23 AS24487 203.215.52.0/22 AS18101 RIL-IDC Reliance Infocom Ltd Internet Data Centre, 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.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 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.66.152.0/24 AS18499 208.66.153.0/24 AS18499 208.66.154.0/24 AS18499 208.66.155.0/24 AS18499 208.66.156.0/24 AS18499 208.66.157.0/24 AS18499 208.66.158.0/24 AS18499 208.66.159.0/24 AS18499 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.87.208.0/24 AS31997 209.87.209.0/24 AS31997 209.87.210.0/24 AS31997 209.87.211.0/24 AS31997 209.87.212.0/22 AS31997 209.87.216.0/24 AS31997 209.87.217.0/24 AS31997 209.87.218.0/24 AS31997 209.87.219.0/24 AS31997 209.87.220.0/24 AS31997 209.87.221.0/24 AS31997 209.87.222.0/24 AS31997 209.87.223.0/24 AS31997 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.177.160.0/24 AS18499 209.177.161.0/24 AS18499 209.177.162.0/24 AS18499 209.177.163.0/24 AS18499 209.177.164.0/24 AS18499 209.177.165.0/24 AS18499 209.177.166.0/24 AS18499 209.177.167.0/24 AS18499 209.177.168.0/24 AS18499 209.177.169.0/24 AS18499 209.177.170.0/24 AS18499 209.177.171.0/24 AS18499 209.177.172.0/24 AS18499 209.177.173.0/24 AS18499 209.177.174.0/24 AS18499 209.177.175.0/24 AS18499 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.144.240.0/23 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.243.0/24 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.244.0/22 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, 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 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 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 j at arpa.com Fri Apr 9 17:01:58 2010 From: j at arpa.com (jamie rishaw) Date: Fri, 9 Apr 2010 17:01:58 -0500 Subject: [ot/bronog] !summon ..!clue!charter/HSI Message-ID: Looking for clue within Charter HSI realm (or people that can give contact / forward issues) .. HSI seems to be taboo even within Charter (even $work's Charter biz/fiber acct mgrs are without clue as to who to call) . . Off list help is appreciated .. Thanks in advance -jamie From j at arpa.com Fri Apr 9 17:20:45 2010 From: j at arpa.com (jamie rishaw) Date: Fri, 9 Apr 2010 17:20:45 -0500 Subject: [ot/bronog] !summon ..!clue!charter/HSI In-Reply-To: References: Message-ID: I was told : > Charter is very decentralized. This is for endpoints (currently) GMT-5 - Chicago IL and Madison WI. Thanks again -jamie From awacs at ziskind.us Fri Apr 9 17:31:02 2010 From: awacs at ziskind.us (N. Yaakov Ziskind) Date: Fri, 9 Apr 2010 18:31:02 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004081536.o38FaMKQ025021@aurora.sol.net> <8BD18449-053C-47EE-8935-31C607086F70@virtualized.org> Message-ID: <20100409183102.A2372@egps.egps.com> Michael Dillon wrote (on Fri, Apr 09, 2010 at 09:31:43PM +0100): > On 9 April 2010 18:36, David Conrad wrote: > > On Apr 8, 2010, at 11:32 AM, Michael Dillon wrote: > >> All ARIN fees are set by the ARIN members. > > > > No they are not. > > According to : > > The Fee Schedule, is continually reviewed by ARIN's membership, > and its Advisory Council, and Board of Trustees to identify ways in > which ARIN can improve service to the community and to ensure > that ARIN's operational needs are met > > Since the AC and Board of Trustees are elected by the Members, > ultimately the members have control of fees. > > -- Michael Dillon Uh, that's NOT the same thing. Or, do you believe you have control of the taxes you pay? *I* sure don't. -- _________________________________________ 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 jeroen at mompl.net Fri Apr 9 17:33:47 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 09 Apr 2010 15:33:47 -0700 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <4BBF92F4.1030700@splio.fr> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <031b01cad787$0fdf9c30$2f9ed490$@net> <4BBF3958.2020600@csuohio.edu> <4BBF4513.3070909@splio.fr> <4BBF8681.20306@mompl.net> <4BBF92F4.1030700@splio.fr> Message-ID: <4BBFAB4B.7090003@mompl.net> Benjamin Billon wrote: >> And that is wrong why exactly? ;-) > Nah, I'm not answering that =D > Nice try, though. Hah ;-) > This is also blocking Sina, Netease, Yahoo.cn and other major Chinese > ISP/ESP. Am I the only to think this is not very smart? It depends. I'am not a fan of country blocking. But in my case it can work for a home server. You could adapt the list and block port 22 only for production servers where you can't expect to never have email from China, but can safely block brute force ssh attacks. Regards, Jeroen From bbillon-ml at splio.fr Fri Apr 9 17:42:11 2010 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Sat, 10 Apr 2010 00:42:11 +0200 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <4BBFAB4B.7090003@mompl.net> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <031b01cad787$0fdf9c30$2f9ed490$@net> <4BBF3958.2020600@csuohio.edu> <4BBF4513.3070909@splio.fr> <4BBF8681.20306@mompl.net> <4BBF92F4.1030700@splio.fr> <4BBFAB4B.7090003@mompl.net> Message-ID: <4BBFAD43.8000605@splio.fr> >> This is also blocking Sina, Netease, Yahoo.cn and other major Chinese >> ISP/ESP. Am I the only to think this is not very smart? > > It depends. I'am not a fan of country blocking. But in my case it can > work for a home server. You could adapt the list and block port 22 > only for production servers where you can't expect to never have email > from China, but can safely block brute force ssh attacks. > Yep, home server, your server. That's not the same when you have customers who rely on your server. IMHO, port 22 and other critical ports should always be blocked except from known places. From patrick at ianai.net Fri Apr 9 17:51:25 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 9 Apr 2010 18:51:25 -0400 Subject: FCC dealt major blow in net neutrality ruling favoring Comcast In-Reply-To: References: <42DF9B4B-8614-43F9-802D-9586AA7AD0FB@ianai.net> <4BBB8009.1060408@csuohio.edu> <1E8B940C5E21014AB8BE70B975D40EDB03957DBA@bert.HiberniaAtlantic.local> Message-ID: <201B1FB2-3784-4BC2-8C57-10797F6BE989@ianai.net> On Apr 9, 2010, at 5:22 PM, joe mcguckin wrote: > Let me see if I understand this correctly. > > People are defending the FCC? > > The same FCC that ruled that any data service over 200Kbits was broadband, not "Information Service" and thus came under the purview of > the FBI and CALEA - directly contravening the language and intent of the CALEA act? Very specifically NOT the same FCC. The FCC may retain the name, but the management, political bent, philosophies, and attitude are very different from the one that made that ruling. That said, it is entirely possible this FCC would make the same ruling. Doesn't change what I said above. > Sometimes the enemy of your enemy is just your enemy. Sometimes. And sometimes he is neither, so it might be advantageous to work with him on the occasional project where your interest and his correlate well. -- TTFN, patrick > On Apr 9, 2010, at 6:59 AM, Rod Beck wrote: > >> In Europe you rarely encounter courts circumscribing regulatory power. >> >> And it is well known that the District Court is dominated by anti-regulatory judges. >> >> >> -----Original Message----- >> From: Michael Holstein [mailto:michael.holstein at csuohio.edu] >> Sent: Tue 4/6/2010 7:40 PM >> To: Patrick W. Gilmore >> Cc: NANOG list >> Subject: Re: FCC dealt major blow in net neutrality ruling favoring Comcast >> >> >>> >>> >>> Seems on-topic, even though policy related. >>> > From jared at puck.nether.net Fri Apr 9 18:04:02 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 9 Apr 2010 19:04:02 -0400 Subject: FCC dealt major blow in net neutrality ruling favoring Comcast In-Reply-To: <201B1FB2-3784-4BC2-8C57-10797F6BE989@ianai.net> References: <42DF9B4B-8614-43F9-802D-9586AA7AD0FB@ianai.net> <4BBB8009.1060408@csuohio.edu> <1E8B940C5E21014AB8BE70B975D40EDB03957DBA@bert.HiberniaAtlantic.local> <201B1FB2-3784-4BC2-8C57-10797F6BE989@ianai.net> Message-ID: On Apr 9, 2010, at 6:51 PM, Patrick W. Gilmore wrote: > On Apr 9, 2010, at 5:22 PM, joe mcguckin wrote: > >> Let me see if I understand this correctly. >> >> People are defending the FCC? >> >> The same FCC that ruled that any data service over 200Kbits was broadband, not "Information Service" and thus came under the purview of >> the FBI and CALEA - directly contravening the language and intent of the CALEA act? > > Very specifically NOT the same FCC. The FCC may retain the name, but the management, political bent, philosophies, and attitude are very different from the one that made that ruling. > > That said, it is entirely possible this FCC would make the same ruling. Doesn't change what I said above. > > >> Sometimes the enemy of your enemy is just your enemy. > > Sometimes. And sometimes he is neither, so it might be advantageous to work with him on the occasional project where your interest and his correlate well. I believe you are doing a disservice to the FCC by making these inflammatory statements. There are plenty of GOOD people at the FCC, I'm guessing you may not have spent much time talking to them. (I met with the FCC about CALEA due to concerns about there being no mature 10G intercept platforms. There are vendors that are shipping devices that are not CALEA compliant, but may be compliant under other lawful intercept methods/statutes). You have to understand that there are political appointees (that must be confirmed) and the regular staffers that operate in this space. The federal register and comment process is abundant, allowing people to file comments on nearly anything the government is discussing. If you've not engaged in getting the daily notices from the Federal Register, and did not file form 445, you may want to take a look at it. Phone the FCC. Phone the DoJ and ask for the "CALEA Implementation Unit", the folks there are behind the http://askcalea.net website. As with many things, there is a lot of (mis-)information out there. (Gotta run kids are bleeding!). From gbonser at seven.com Fri Apr 9 18:19:06 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 9 Apr 2010 16:19:06 -0700 Subject: BGP hijack from 23724 -> 4134 China? References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <031b01cad787$0fdf9c30$2f9ed490$@net> <4BBE8B74.7040508@2mbit.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6E2F@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Brielle Bruns [mailto:bruns at 2mbit.com] > Sent: Thursday, April 08, 2010 7:06 PM > To: nanog at nanog.org > Subject: Re: BGP hijack from 23724 -> 4134 China? > > On 4/8/10 7:50 PM, Aaron Wendel wrote: > > Please. > > > > Since there's been alot of requests for the ACLs, i've gone ahead and > put the info on our wiki for easy access. > > http://wiki.sosdg.org/sosdg:internal:chinafilter > I suppose it is easier and takes less of your resources to get the world to block you than it is to block the world. >From China's point of view, it might just make their firewalling a whole lot easier. From LarrySheldon at cox.net Fri Apr 9 18:34:20 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 09 Apr 2010 18:34:20 -0500 Subject: FCC dealt major blow in net neutrality ruling favoring Comcast In-Reply-To: References: <42DF9B4B-8614-43F9-802D-9586AA7AD0FB@ianai.net> <4BBB8009.1060408@csuohio.edu> <1E8B940C5E21014AB8BE70B975D40EDB03957DBA@bert.HiberniaAtlantic.local> Message-ID: <4BBFB97C.1050400@cox.net> On 4/9/2010 16:22, joe mcguckin wrote: > Let me see if I understand this correctly. > > People are defending the FCC? After looking at who they elect, why does that surprise? > > The same FCC that ruled that any data service over 200Kbits was broadband, not "Information Service" and thus came under the purview of > the FBI and CALEA - directly contravening the language and intent of the CALEA act? > > Sometimes the enemy of your enemy is just your enemy. The calculus is really simpler. Somebody famous should have said (or maybe Ronald Reagan _did_ say: "Government is not the solution to the problem. Government IS the problem." -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From meekjt at gmail.com Fri Apr 9 18:55:01 2010 From: meekjt at gmail.com (Jon Meek) Date: Fri, 9 Apr 2010 19:55:01 -0400 Subject: capirca : Google Network Filtering Management In-Reply-To: References: <20100409110909.D5AF7078@resin14.mta.everyone.net> Message-ID: On Fri, Apr 9, 2010 at 5:57 PM, Christopher Morrow wrote: > On Fri, Apr 9, 2010 at 2:09 PM, William Duck wrote: >> ? http://code.google.com/p/capirca/ >> ? Developed internally at Google, this system is designed to utilize >> ? common definitions of networks and services and high-level policy >> ? files to facilitate the development and manipulation >> ? of network access control filters (ACLs) for various platforms. > > would be interesting (to the community to get the authors to present > some material about this at a meeting? (a nanog meeting) > > -Chris The authors gave an excellent tag-team presentation at USENIX LISA '09. Video might be available. It would be good at a NANOG meeting. Jon From patrick at zill.net Fri Apr 9 19:29:02 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Fri, 09 Apr 2010 20:29:02 -0400 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <4BBF92F4.1030700@splio.fr> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <031b01cad787$0fdf9c30$2f9ed490$@net> <4BBF3958.2020600@csuohio.edu> <4BBF4513.3070909@splio.fr> <4BBF8681.20306@mompl.net> <4BBF92F4.1030700@splio.fr> Message-ID: <4BBFC64E.7050107@zill.net> Benjamin Billon wrote: > >>> So basically, the idea is to disconnect China's Internet even more >>> than what it inflicts to itself? >> And that is wrong why exactly? ;-) > Nah, I'm not answering that =D > Nice try, though. >>> How fun. What was the FCC/Comcast case about again? >> It's only port 25, at least here: >> http://www.okean.com/antispam/iptables/iptables.html > This is also blocking Sina, Netease, Yahoo.cn and other major Chinese > ISP/ESP. Am I the only to think this is not very smart? > > If you think Chinese DUL would be interesting, please tell me. > > This DID actually bite my company about 3 years ago. A customer went to China (usually in NYC) and could not send email through the mail server because they were using POP-before-SMTP instead of the mail submission port . Upon return, the customer switched mail service away from us. --Patrick From joelja at bogus.com Fri Apr 9 19:32:34 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 09 Apr 2010 17:32:34 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4BBF5C45.3070406@otd.com> References: <201004091121.o39BLkLL025885@aurora.sol.net> <9815F8F0-9337-4BCB-9941-9465437A2B1C@delong.com> <4BBF5C45.3070406@otd.com> Message-ID: <4BBFC722.5010906@bogus.com> On 04/09/2010 09:56 AM, Dave Israel wrote: > +Bonus Uncertainty: There is a lack of consensus on how IPv6 is to be > deployed. For example, look at the ongoing debates on point to point > network sizes and the /64 network boundary in general. There's also no > tangible benefit to deploying IPv6 right now, and the tangible danger > that your v6 deployment will just have to be redone because there's some > flaw in the current v6 protocol or best practices that will be uncovered. This lack of consensus seems to most be associated with people who haven't deployed. those of us who have in some cases a decade ago, don't wonder very much... You can deploy point-to-points as /112s or /64s. if you do anything that isn't aligned on a byte boundary the brains will leak out of the ears of your engineers. If you don't believe me go ahead and try it. any subnet that has more than 2 devices on it is a /64 do anything else and you'll shoot yourself or someone else in the foot and probably sooner rather than later. > +Bonus Doubt: Because we've been told that "IPv4 will be dead in 2 > years" for the last 20 years, and that "IPv6 will be deployed and a way > of life in 2 years" for the past 10, nobody really believes it anymore. > There's been an ongoing chant of "wolf" for so long, many people won't > believe it until things are much, much worse. I bet you're really good at predicting the stock market as well. you can be right and still go bankrupt. It is posisble to mistake postive but nearly random outcomes for skill or insight. I don't have to be right about needing an ipv6 deployment plan or even believe that ipv6 is deployable in it's present form (I happen to believe that, buts it's beside the point), because I need a business continuity plan for what happens around ipv4 exhaustion, I may have more than one, but I have a fiduciary duty to my company to not fly this particular plane into avoidable terrain. > -Dave > From joelja at bogus.com Fri Apr 9 19:40:20 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 09 Apr 2010 17:40:20 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <20100407194030.A3660@egps.egps.com> <4BBE1341.2000706@sprunk.org> <4BBF3A07.4010005@earthlink.net> <2BB98A16-3FC3-4DBE-B197-4614D8B3D2CE@delong.com> Message-ID: <4BBFC8F4.9030104@bogus.com> On 04/09/2010 11:01 AM, William Herrin wrote: > Fun movies notwithstanding, they generally issue a fine and work it > through the civil courts. > > If you were doing something extraordinary, like jamming emergency > communications, I expect they might well call the police for > assistance. But those are police, not FCC agents, and they're acting > as much on behalf of the folks whose signals you're jamming as they > are on behalf of the FCC. You'll find that any of us (including ARIN) > can summon police for assistance with assaults upon us. No, the FCC uses the US Marshalls service and the unites states attorney for this sort of activity, and it has statutory authority to do so... google up "FCC raid" if you want some background. > Regards, > Bill Herrin > > From jeroen at mompl.net Fri Apr 9 20:01:43 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 09 Apr 2010 18:01:43 -0700 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <4BBFC64E.7050107@zill.net> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <031b01cad787$0fdf9c30$2f9ed490$@net> <4BBF3958.2020600@csuohio.edu> <4BBF4513.3070909@splio.fr> <4BBF8681.20306@mompl.net> <4BBF92F4.1030700@splio.fr> <4BBFC64E.7050107@zill.net> Message-ID: <4BBFCDF7.7020103@mompl.net> Patrick Giagnocavo wrote: > This DID actually bite my company about 3 years ago. > > A customer went to China (usually in NYC) and could not send email > through the mail server because they were using POP-before-SMTP instead > of the mail submission port . The problem did not lie with blocking IPs. But with offering a flawed service such as pop before smtp to begin with. I know many ISPs/ESPs still do, much to my chagrin. The only way to submit email should be port 587 with TLS encryption, 3 years ago one could be forgiven for offering deprecated (*) port 465 with SSL, but not anymore (msoft clients have been fixed). Regards, Jeroen http://www.iana.org/assignments/port-numbers * urd 465/tcp URL Rendesvous Directory for SSM From ravi at cow.org Fri Apr 9 20:11:00 2010 From: ravi at cow.org (Ravi Pina) Date: Fri, 9 Apr 2010 21:11:00 -0400 Subject: capirca : Google Network Filtering Management In-Reply-To: <20100409110909.D5AF7078@resin14.mta.everyone.net> References: <20100409110909.D5AF7078@resin14.mta.everyone.net> Message-ID: <20100410011100.GX54295@neu.cow.org> On Fri, Apr 09, 2010 at 11:09:09AM -0700, William Duck wrote: > http://code.google.com/p/capirca/ > Developed internally at Google, this system is designed to utilize > common definitions of networks and services and high-level policy > files to facilitate the development and manipulation > of network access control filters (ACLs) for various platforms. > __________________________________________________________________ > > Get your own *free* email address like this one from www.OwnEmail.com There is a lot of potential here, however it almost seems like abandonware. I've been tinkering with it in house, but ran into the obstacle of not knowing Python (yet) to fix and improve it myself. Thankfully a colleague has been able to write up some important patches which are available on the issue tracker [1]. -r [1] http://code.google.com/p/capirca/issues/list From morrowc.lists at gmail.com Fri Apr 9 20:49:54 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 9 Apr 2010 21:49:54 -0400 Subject: capirca : Google Network Filtering Management In-Reply-To: References: <20100409110909.D5AF7078@resin14.mta.everyone.net> Message-ID: On Fri, Apr 9, 2010 at 7:55 PM, Jon Meek wrote: > On Fri, Apr 9, 2010 at 5:57 PM, Christopher Morrow > wrote: >> On Fri, Apr 9, 2010 at 2:09 PM, William Duck wrote: >>> ? http://code.google.com/p/capirca/ >>> ? Developed internally at Google, this system is designed to utilize >>> ? common definitions of networks and services and high-level policy >>> ? files to facilitate the development and manipulation >>> ? of network access control filters (ACLs) for various platforms. >> >> would be interesting (to the community to get the authors to present >> some material about this at a meeting? (a nanog meeting) >> >> -Chris > > The authors gave an excellent tag-team presentation at USENIX LISA > '09. Video might be available. It would be good at a NANOG meeting. they did, so I hear, since the next nanog is in their home-court it'd be easy to ask them to swing by and re-present :) (as a user of this system it's really quite nice) -Chris From steve at ibctech.ca Fri Apr 9 21:10:15 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 09 Apr 2010 22:10:15 -0400 Subject: Fwd: [c-nsp] capirca : Google Network Filtering Management Message-ID: <4BBFDE07.107@ibctech.ca> Would someone from Google kindly confirm/deny this claim? I'm as patient as any other, but I'm beginning to feel for those who have yet (but are ready to) to trigger the filters... Thankfully, my 'reasonable' regex knowledge has me ready to list a heaping pile of filth into the ether, if the community consensus is that the person contained in the 'From:' below has never contributed anything worth value to our community. ...give the word. -------- Original Message -------- Date: Fri, 09 Apr 2010 20:11:48 +0200 From: Guillaume FORTAINE To: cisco-nsp at puck.nether.net Subject: [c-nsp] capirca : Google Network Filtering Management http://code.google.com/p/capirca/ Developed internally at Google, this system is designed to utilize common definitions of networks and services and high-level policy files to facilitate the development and manipulation of network access control filters (ACLs) for various platforms. _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From goemon at anime.net Fri Apr 9 21:25:38 2010 From: goemon at anime.net (goemon at anime.net) Date: Fri, 9 Apr 2010 19:25:38 -0700 (PDT) Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6E2F@RWC-EX1.corp.seven.com> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <031b01cad787$0fdf9c30$2f9ed490$@net> <4BBE8B74.7040508@2mbit.com> <5A6D953473350C4B9995546AFE9939EE08FE6E2F@RWC-EX1.corp.seven.com> Message-ID: On Fri, 9 Apr 2010, George Bonser wrote: > I suppose it is easier and takes less of your resources to get the world > to block you than it is to block the world. operating a bullet proof spam network, ignoring complaints, is certainly one way to achieve that. anyone remember chinanet's lying autoresponder: In your SPAM eMail,I can't find the IP or the IP is not by my control.Please give me the correct IP.Thank you. ? -Dan From jimb at jsbc.cc Fri Apr 9 21:27:46 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Fri, 09 Apr 2010 19:27:46 -0700 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <4BBFAD43.8000605@splio.fr> References: <4BBE3B2A.7070901@west.net> <4BBE3E43.2050407@2mbit.com> <031b01cad787$0fdf9c30$2f9ed490$@net> <4BBF3958.2020600@csuohio.edu> <4BBF4513.3070909@splio.fr> <4BBF8681.20306@mompl.net> <4BBF92F4.1030700@splio.fr> <4BBFAB4B.7090003@mompl.net> <4BBFAD43.8000605@splio.fr> Message-ID: <4BBFE222.6070707@jsbc.cc> On 4/9/2010 15:42, Benjamin Billon wrote: > >>> This is also blocking Sina, Netease, Yahoo.cn and other major >>> Chinese ISP/ESP. Am I the only to think this is not very smart? >> >> It depends. I'am not a fan of country blocking. But in my case it can >> work for a home server. You could adapt the list and block port 22 >> only for production servers where you can't expect to never have >> email from China, but can safely block brute force ssh attacks. >> > Yep, home server, your server. That's not the same when you have > customers who rely on your server. > IMHO, port 22 and other critical ports should always be blocked except > from known places. > I personally use a port knocking setup and it pretty much eliminates SSH brute force account/password hacks. Actually, on one box that didn't have the ability to do that, I simply moved the SSH port. This was surprisingly effective, although a bit inconvenient. I'll have to say that a very large number of the brute attempts were from Chinese IPs. Hopefully they're not reading this. ;-) From randy at psg.com Fri Apr 9 21:49:41 2010 From: randy at psg.com (Randy Bush) Date: Sat, 10 Apr 2010 11:49:41 +0900 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <20100407194030.A3660@egps.egps.com> <4BBE1341.2000706@sprunk.org> <4BBF3A07.4010005@earthlink.net> <2BB98A16-3FC3-4DBE-B197-4614D8B3D2CE@delong.com> Message-ID: some nut i procmail wrote >> No, ARIN is not a regulator. Regulators have guns or access to >> people with guns to enforce the regulations that they enact. ARIN has >> no such power. > I'm a little confused on the distinction you're making. confusion between the army and the fcc, who, even under cheney, did not use guns. randy From joelja at bogus.com Fri Apr 9 21:59:04 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 09 Apr 2010 19:59:04 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <20100407194030.A3660@egps.egps.com> <4BBE1341.2000706@sprunk.org> <4BBF3A07.4010005@earthlink.net> <2BB98A16-3FC3-4DBE-B197-4614D8B3D2CE@delong.com> Message-ID: <4BBFE978.3000908@bogus.com> On 04/09/2010 07:49 PM, Randy Bush wrote: > some nut i procmail wrote >>> No, ARIN is not a regulator. Regulators have guns or access to >>> people with guns to enforce the regulations that they enact. ARIN has >>> no such power. >> I'm a little confused on the distinction you're making. > > confusion between the army and the fcc, who, even under cheney, did not > use guns. Gewaltmonopol des Staates... Failure to restrain the use of coercive violence is one (modern) definition of a failed state. > randy > From nenolod at systeminplace.net Fri Apr 9 22:02:45 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 09 Apr 2010 22:02:45 -0500 Subject: Fwd: [c-nsp] capirca : Google Network Filtering Management In-Reply-To: <4BBFDE07.107@ibctech.ca> References: <4BBFDE07.107@ibctech.ca> Message-ID: <1270868565.13545.3.camel@petrie> On Fri, 2010-04-09 at 22:10 -0400, Steve Bertrand wrote: > Would someone from Google kindly confirm/deny this claim? I'm as patient > as any other, but I'm beginning to feel for those who have yet (but are > ready to) to trigger the filters... > > Thankfully, my 'reasonable' regex knowledge has me ready to list a > heaping pile of filth into the ether, if the community consensus is > that the person contained in the 'From:' below has never contributed > anything worth value to our community. > > ...give the word. It is a legitimate Google product, but I don't work at Google. William From owen at delong.com Fri Apr 9 22:57:52 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Apr 2010 20:57:52 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <20100407194030.A3660@egps.egps.com> <4BBE1341.2000706@sprunk.org> <4BBF3A07.4010005@earthlink.net> <2BB98A16-3FC3-4DBE-B197-4614D8B3D2CE@delong.com> Message-ID: <8A57FEDE-52CC-4729-A171-4AF79CA2441C@delong.com> On Apr 9, 2010, at 10:43 AM, William Herrin wrote: > On Fri, Apr 9, 2010 at 1:07 PM, Owen DeLong wrote: >> On Apr 9, 2010, at 7:30 AM, todd glassey wrote: >>> BULL SH*T, ARIN makes determinations as to how many IP addresses it will >>> issue and in that sense it is exactly a regulator. >>> >> No, ARIN is not a regulator. Regulators have guns or access to people with >> guns to enforce the regulations that they enact. ARIN has no such power. >> >> The FCC is a regulator. The California PUC is a regulator. ARIN is not >> a regulator. > > Last I heard, the FCC has access to people with law degrees not guns. > Much like ARIN, really. > If the FCC finds that you have violated an FCC regulation, they are well and truly capable of bringing in the FBI and State or Local law enforcement to enforce their regulation. All three of those entities have guns. To do so, the FCC does not need a court order. ARIN cannot get the FBI, State, or Local law enforcement to enforce ARIN policy unless that policy is further backed by a court order. (Of course, at that point, they are acting under the force of a regulator in the form of the court more than under ARIN). Owen From owen at delong.com Fri Apr 9 23:00:32 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Apr 2010 21:00:32 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <20100407194030.A3660@egps.egps.com> <4BBE1341.2000706@sprunk.org> <4BBF3A07.4010005@earthlink.net> <2BB98A16-3FC3-4DBE-B197-4614D8B3D2CE@delong.com> Message-ID: <42DD49E7-84F9-479A-A762-81C2791D9895@delong.com> On Apr 9, 2010, at 10:34 AM, David Conrad wrote: > Owen, > > On Apr 9, 2010, at 7:07 AM, Owen DeLong wrote: >> No, ARIN is not a regulator. Regulators have guns or access to people with >> guns to enforce the regulations that they enact. ARIN has no such power. > > I'm a little confused on the distinction you're making. Today, ARIN can remove whois data/reverse delegations as a way of enforcing 'regulations'. In the future, assuming RPKI is deployed, ARIN could, in theory, revoke the certification of a resource. While not a gun, these are means of coercion. Are you being literal when you say "gun" or figurative? > > Regards, > -drc Nothing forces anyone who wants to route a prefix to follow the IANA or ARIN RPKI. It is followed by agreement of the community, if it gets followed at all. There is no regulation that would prevent someone from setting up an alternate RPKI certificate authority and issuing certificates for resources alternative to the RIR system. Try doing that with Callsigns and using them on the air. The FCC will either fine you or have you locked up in relatively short order. ARIN cannot. It cannot become a criminal offense subject to incarceration for you to violate ARIN policy. It is a purely civil matter. Actual regulators have the force of law. ARIN does not. Owen From franck at genius.com Fri Apr 9 23:23:02 2010 From: franck at genius.com (Franck Martin) Date: Sat, 10 Apr 2010 16:23:02 +1200 (MAGST) Subject: OECD Reports on State of IPv6 Deployment for Policy Makers Message-ID: <3801097.338.1270873377626.JavaMail.franck@franck-martins-macbook-pro.local> http://www.circleid.com/posts/20100409_oecd_reports_on_state_of_ipv6_deployment_for_policy_makers/ From randy at psg.com Fri Apr 9 23:31:53 2010 From: randy at psg.com (Randy Bush) Date: Sat, 10 Apr 2010 13:31:53 +0900 Subject: OECD Reports on State of IPv6 Deployment for Policy Makers In-Reply-To: <3801097.338.1270873377626.JavaMail.franck@franck-martins-macbook-pro.local> References: <3801097.338.1270873377626.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: > http://www.circleid.com/posts/20100409_oecd_reports_on_state_of_ipv6_deployment_for_policy_makers/ karine perset's work is, as usual, good enough that it should be seen in it's original, not some circle-je^h^hid hack of a small part of it. http://www.oecd.org/dataoecd/48/8/44961688.pdf randy From jmamodio at gmail.com Fri Apr 9 23:49:18 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 9 Apr 2010 23:49:18 -0500 Subject: OECD Reports on State of IPv6 Deployment for Policy Makers In-Reply-To: References: <3801097.338.1270873377626.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: > karine perset's work is, as usual, good enough that it should be seen in > it's original, not some circle-je^h^hid hack of a small part of it. On of the best parts of her presentation: "Government?s role *is not about regulation*, but about working with technical experts and business to: ?Role 1: Build awareness of issue & help to ease bottlenecks through multi-stakeholder co-operation. ?Role 2: Being early adopters. ?Role 3: International co-operation and helping to monitor progress of deployment." Will they get it any day ? Regards Jorge From nonobvious at gmail.com Sat Apr 10 00:25:07 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Fri, 9 Apr 2010 22:25:07 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <42DD49E7-84F9-479A-A762-81C2791D9895@delong.com> References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <20100407194030.A3660@egps.egps.com> <4BBE1341.2000706@sprunk.org> <4BBF3A07.4010005@earthlink.net> <2BB98A16-3FC3-4DBE-B197-4614D8B3D2CE@delong.com> <42DD49E7-84F9-479A-A762-81C2791D9895@delong.com> Message-ID: One really good thing about spam was that, before it became a big problem, all Usenet / Internet discussions had a risk of devolving into "libertarians vs. socialists" flamewars, but that got replaced by "*%^&%*& spammers", and eventually we got that nice little checklist as a way to quiet even those discussions. Let's put the "regulators with guns" discussion back into the pre-spam bin, and take this back to the "making IPv6 actually work" topics, of which there are plenty. (Because after all, the IPv6ian People's Front side is wrong, wrong, wrong! :-) -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From franck at genius.com Sat Apr 10 00:31:43 2010 From: franck at genius.com (Franck Martin) Date: Sat, 10 Apr 2010 17:31:43 +1200 (MAGST) Subject: OECD Reports on State of IPv6 Deployment for Policy Makers In-Reply-To: Message-ID: <13299750.345.1270877501496.JavaMail.franck@franck-martins-macbook-pro.local> You should have seen the CNN experiment on cyber attack... It took 3/4 of the time for the "government" to realize they need to ask the private sector to help them. The first 3/4 were spent to discuss what the president can do or not do so they can take over the infrastructure and tell the operators what to do... ----- Original Message ----- From: "Jorge Amodio" To: "Randy Bush" Cc: "Franck Martin" , nanog at nanog.org Sent: Saturday, 10 April, 2010 4:49:18 PM Subject: Re: OECD Reports on State of IPv6 Deployment for Policy Makers > karine perset's work is, as usual, good enough that it should be seen > in it's original, not some circle-je^h^hid hack of a small part of it. On of the best parts of her presentation: "Government?s role *is not about regulation*, but about working with technical experts and business to: ?Role 1: Build awareness of issue & help to ease bottlenecks through multi-stakeholder co-operation. ?Role 2: Being early adopters. ?Role 3: International co-operation and helping to monitor progress of deployment." Will they get it any day ? Regards Jorge From randy at psg.com Sat Apr 10 00:42:30 2010 From: randy at psg.com (Randy Bush) Date: Sat, 10 Apr 2010 14:42:30 +0900 Subject: OECD Reports on State of IPv6 Deployment for Policy Makers In-Reply-To: <13299750.345.1270877501496.JavaMail.franck@franck-martins-macbook-pro.local> References: <13299750.345.1270877501496.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: > You should have seen the CNN experiment on cyber attack... you mean the failed chertoff/cheney wanna make the news clueless crap? puhleeze! the fcc has more guns than that mob had clue. randy From LarrySheldon at cox.net Sat Apr 10 08:31:09 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 10 Apr 2010 08:31:09 -0500 Subject: OECD Reports on State of IPv6 Deployment for Policy Makers In-Reply-To: <3801097.338.1270873377626.JavaMail.franck@franck-martins-macbook-pro.local> References: <3801097.338.1270873377626.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4BC07D9D.8020808@cox.net> On 4/9/2010 23:23, Franck Martin wrote: > http://www.circleid.com/posts/20100409_oecd_reports_on_state_of_ipv6_deployment_for_policy_makers/ > Nasty, degenerate, foot-dragging U.S. of A. does it again. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Sat Apr 10 08:42:16 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 10 Apr 2010 08:42:16 -0500 Subject: FCC dealt major blow in net neutrality ruling favoring Comcast In-Reply-To: References: <42DF9B4B-8614-43F9-802D-9586AA7AD0FB@ianai.net> <4BBB8009.1060408@csuohio.edu> <1E8B940C5E21014AB8BE70B975D40EDB03957DBA@bert.HiberniaAtlantic.local> <4BBFB97C.1050400@cox.net> Message-ID: <4BC08038.40908@cox.net> On 4/10/2010 06:36, Roderick Beck wrote: > I would characterize the US as a first rate military and economic > power, but a third rate place to live. What are the net emigration rates by country? What are the net "medical tourism" rates by country? What are the net disaster charity rates by country? -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From patrick at zill.net Sat Apr 10 09:19:41 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Sat, 10 Apr 2010 10:19:41 -0400 Subject: FCC dealt major blow in net neutrality ruling favoring Comcast In-Reply-To: <4BC08038.40908@cox.net> References: <42DF9B4B-8614-43F9-802D-9586AA7AD0FB@ianai.net> <4BBB8009.1060408@csuohio.edu> <1E8B940C5E21014AB8BE70B975D40EDB03957DBA@bert.HiberniaAtlantic.local> <4BBFB97C.1050400@cox.net> <4BC08038.40908@cox.net> Message-ID: <4BC088FD.6020301@zill.net> Larry Sheldon wrote: > On 4/10/2010 06:36, Roderick Beck wrote: > >> I would characterize the US as a first rate military and economic >> power, but a third rate place to live. > > What are the net emigration rates by country? > > What are the net "medical tourism" rates by country? > > What are the net disaster charity rates by country? > > Please, let's keep this off the NANOG list! I am already on a politically oriented forum. --Patrick From LarrySheldon at cox.net Sat Apr 10 09:22:50 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 10 Apr 2010 09:22:50 -0500 Subject: FCC dealt major blow in net neutrality ruling favoring Comcast In-Reply-To: <4BC088FD.6020301@zill.net> References: <42DF9B4B-8614-43F9-802D-9586AA7AD0FB@ianai.net> <4BBB8009.1060408@csuohio.edu> <1E8B940C5E21014AB8BE70B975D40EDB03957DBA@bert.HiberniaAtlantic.local> <4BBFB97C.1050400@cox.net> <4BC08038.40908@cox.net> <4BC088FD.6020301@zill.net> Message-ID: <4BC089BA.4010908@cox.net> On 4/10/2010 09:19, Patrick Giagnocavo wrote: > Larry Sheldon wrote: >> On 4/10/2010 06:36, Roderick Beck wrote: > Please, let's keep this off the NANOG list! I am already on a > politically oriented forum. Got it. It is OK to make accusations, but not OK to challenge them. My apologies. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From brunner at nic-naa.net Sat Apr 10 09:33:23 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sat, 10 Apr 2010 10:33:23 -0400 Subject: OECD Reports on State of IPv6 Deployment for Policy Makers In-Reply-To: References: <13299750.345.1270877501496.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4BC08C33.10306@nic-naa.net> On 4/10/10 1:42 AM, Randy Bush wrote: >> You should have seen the CNN experiment on cyber attack... > > you mean the failed chertoff/cheney wanna make the news clueless crap? > puhleeze! the fcc has more guns than that mob had clue. unfortunately, the failed chertoff/cheney celebrants of the "cybersecurity" cult have managed one significant outplacement. eric From jmplank at gmail.com Sat Apr 10 09:42:10 2010 From: jmplank at gmail.com (Jason Plank) Date: Sat, 10 Apr 2010 10:42:10 -0400 Subject: FCC dealt major blow in net neutrality ruling favoring Comcast In-Reply-To: <4BC089BA.4010908@cox.net> References: <42DF9B4B-8614-43F9-802D-9586AA7AD0FB@ianai.net> <4BBB8009.1060408@csuohio.edu> <1E8B940C5E21014AB8BE70B975D40EDB03957DBA@bert.HiberniaAtlantic.local> <4BBFB97C.1050400@cox.net> <4BC08038.40908@cox.net> <4BC088FD.6020301@zill.net> <4BC089BA.4010908@cox.net> Message-ID: <1F08D5BC-E360-4A08-AA60-D83BA7B4FC6A@gmail.com> Yawn. Sent from my iPhone On Apr 10, 2010, at 10:22 AM, Larry Sheldon wrote: > On 4/10/2010 09:19, Patrick Giagnocavo wrote: >> Larry Sheldon wrote: >>> On 4/10/2010 06:36, Roderick Beck wrote: > >> Please, let's keep this off the NANOG list! I am already on a >> politically oriented forum. > > Got it. It is OK to make accusations, but not OK to challenge them. > > My apologies. > -- > Somebody should have said: > A democracy is two wolves and a lamb voting on what to have for > dinner. > > Freedom under a constitutional republic is a well armed lamb > contesting > the vote. > > Requiescas in pace o email > Ex turpi causa non oritur actio > Eppure si rinfresca > > ICBM Targeting Information: http://tinyurl.com/4sqczs > http://tinyurl.com/7tp8ml > > > From bill at herrin.us Sat Apr 10 11:40:20 2010 From: bill at herrin.us (William Herrin) Date: Sat, 10 Apr 2010 12:40:20 -0400 Subject: OECD Reports on State of IPv6 Deployment for Policy Makers In-Reply-To: References: <3801097.338.1270873377626.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Sat, Apr 10, 2010 at 12:31 AM, Randy Bush wrote: > karine perset's work is, as usual, good enough that it should be seen in > it's original, not some circle-je^h^hid hack of a small part of it. > > http://www.oecd.org/dataoecd/48/8/44961688.pdf John, I'd like to call your attention to slide 8, the chart showing growth in fully working IPv6 deployments. Should that growth trend be allowed to continue, IPv4-only deployments can be expected to fall into the minority after another few hundred years. The upcoming conversion of IPv4 addressing into a zero-sum game (as a result of free pool depletion) is likely to increase this growth trend, but it's anybody's guess whether the new growth trend improves to something with a faster-than-linear feedback loop. And of course once free pool depletion hits, the cost to deploy additional IPv4 systems starts to grow immediately, independent of pre-majority IPv6 growth. We might want to consider additional public policy incentives to kick the IPv6 growth rate into a higher gear. 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 Sat Apr 10 12:44:14 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 10 Apr 2010 10:44:14 -0700 Subject: OECD Reports on State of IPv6 Deployment for Policy Makers In-Reply-To: References: <3801097.338.1270873377626.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Apr 10, 2010, at 9:40 AM, William Herrin wrote: > On Sat, Apr 10, 2010 at 12:31 AM, Randy Bush wrote: >> karine perset's work is, as usual, good enough that it should be seen in >> it's original, not some circle-je^h^hid hack of a small part of it. >> >> http://www.oecd.org/dataoecd/48/8/44961688.pdf > > John, > > I'd like to call your attention to slide 8, the chart showing growth > in fully working IPv6 deployments. Should that growth trend be allowed > to continue, IPv4-only deployments can be expected to fall into the > minority after another few hundred years. > > The upcoming conversion of IPv4 addressing into a zero-sum game (as a > result of free pool depletion) is likely to increase this growth > trend, but it's anybody's guess whether the new growth trend improves > to something with a faster-than-linear feedback loop. And of course > once free pool depletion hits, the cost to deploy additional IPv4 > systems starts to grow immediately, independent of pre-majority IPv6 > growth. > In fact, IPv6 is already showing greater than linear acceleration in deployment, so, even though IPv4 hasn't run out yet, people are beginning to catch on. > We might want to consider additional public policy incentives to kick > the IPv6 growth rate into a higher gear. > Such as? Owen From bross at pobox.com Sat Apr 10 14:12:16 2010 From: bross at pobox.com (Brandon Ross) Date: Sat, 10 Apr 2010 15:12:16 -0400 (EDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004072031.o37KV8jp043643@aurora.sol.net> <68107E737FF84E2FB5409B1D516C022F@TAKA> <20100407194030.A3660@egps.egps.com> <4BBE1341.2000706@sprunk.org> <4BBF3A07.4010005@earthlink.net> <2BB98A16-3FC3-4DBE-B197-4614D8B3D2CE@delong.com> Message-ID: On Fri, 9 Apr 2010, William Herrin wrote: > Fun movies notwithstanding, they generally issue a fine and work it > through the civil courts. And please educate me then, when I don't pay the fine, then what happens? -- Brandon Ross AIM: BrandonNRoss From patrick at ianai.net Sat Apr 10 15:29:50 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 10 Apr 2010 16:29:50 -0400 Subject: FCC dealt major blow in net neutrality ruling favoring Comcast In-Reply-To: References: <42DF9B4B-8614-43F9-802D-9586AA7AD0FB@ianai.net> <4BBB8009.1060408@csuohio.edu> <1E8B940C5E21014AB8BE70B975D40EDB03957DBA@bert.HiberniaAtlantic.local> <201B1FB2-3784-4BC2-8C57-10797F6BE989@ianai.net> Message-ID: <340BBCF3-C288-406F-B925-7430D5070145@ianai.net> On Apr 9, 2010, at 7:04 PM, Jared Mauch wrote: > I believe you are doing a disservice to the FCC by making these inflammatory statements. And here I thought I was defending them for being different & better than the last group. The point is, joe asked about the FCC that made a ruling. The staffers who work hard (and deserve lots of credit for working hard) do not make those rulings. The political appointees and their handlers in the administration make those rulings. Those appointees are very different than the last group. And I think this is a very good thing. For instance, could you in your wildest dreams have imagined the last group sending their top people to NANOG, and those people standing around asking people to talk to them? That was AWESOME, and very different than the "last FCC". And I don't think there is anything wrong with thinking of it that way. -- TTFN, patrick > There are plenty of GOOD people at the FCC, I'm guessing you may not have spent much time talking to them. (I met with the FCC about CALEA due to concerns about there being no mature 10G intercept platforms. There are vendors that are shipping devices that are not CALEA compliant, but may be compliant under other lawful intercept methods/statutes). > > You have to understand that there are political appointees (that must be confirmed) and the regular staffers that operate in this space. The federal register and comment process is abundant, allowing people to file comments on nearly anything the government is discussing. > > If you've not engaged in getting the daily notices from the Federal Register, and did not file form 445, you may want to take a look at it. Phone the FCC. Phone the DoJ and ask for the "CALEA Implementation Unit", the folks there are behind the http://askcalea.net website. > > As with many things, there is a lot of (mis-)information out there. > > (Gotta run kids are bleeding!). > From tdurack at gmail.com Sat Apr 10 15:36:25 2010 From: tdurack at gmail.com (Tim Durack) Date: Sat, 10 Apr 2010 16:36:25 -0400 Subject: OECD Reports on State of IPv6 Deployment for Policy Makers In-Reply-To: References: <3801097.338.1270873377626.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Sat, Apr 10, 2010 at 1:44 PM, Owen DeLong wrote: > > On Apr 10, 2010, at 9:40 AM, William Herrin wrote: > >> On Sat, Apr 10, 2010 at 12:31 AM, Randy Bush wrote: >>> karine perset's work is, as usual, good enough that it should be seen in >>> it's original, not some circle-je^h^hid hack of a small part of it. >>> >>> http://www.oecd.org/dataoecd/48/8/44961688.pdf >> >> John, >> >> I'd like to call your attention to slide 8, the chart showing growth >> in fully working IPv6 deployments. Should that growth trend be allowed >> to continue, IPv4-only deployments can be expected to fall into the >> minority after another few hundred years. >> > >> The upcoming conversion of IPv4 addressing into a zero-sum game (as a >> result of free pool depletion) is likely to increase this growth >> trend, but it's anybody's guess whether the new growth trend improves >> to something with a faster-than-linear feedback loop. And of course >> once free pool depletion hits, the cost to deploy additional IPv4 >> systems starts to grow immediately, independent of pre-majority IPv6 >> growth. >> > In fact, IPv6 is already showing greater than linear acceleration in > deployment, so, even though IPv4 hasn't run out yet, people are > beginning to catch on. > >> We might want to consider additional public policy incentives to kick >> the IPv6 growth rate into a higher gear. >> > Such as? > > Owen > > > Notify all holders of a currently active AS they have been allocated/assigned a /32. No fees. No questions. To accept the allocation/assignment, it must be advertised within a 24 month period. There is no shortage of available /32s in 2000::/3. There is a serious shortage of meaningful deployment. -- Tim:> From nick at foobar.org Sat Apr 10 16:11:14 2010 From: nick at foobar.org (Nick Hilliard) Date: Sat, 10 Apr 2010 22:11:14 +0100 Subject: OECD Reports on State of IPv6 Deployment for Policy Makers In-Reply-To: References: <3801097.338.1270873377626.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4BC0E972.7@foobar.org> On 10/04/2010 21:36, Tim Durack wrote: > Notify all holders of a currently active AS they have been > allocated/assigned a /32. No fees. No questions. > > To accept the allocation/assignment, it must be advertised within a 24 > month period. > > There is no shortage of available /32s in 2000::/3. There is a serious > shortage of meaningful deployment. I'm puzzled as to why you might think that this would incentivise meaningful deployment of ipv6. Nick From tdurack at gmail.com Sat Apr 10 16:35:21 2010 From: tdurack at gmail.com (Tim Durack) Date: Sat, 10 Apr 2010 17:35:21 -0400 Subject: OECD Reports on State of IPv6 Deployment for Policy Makers In-Reply-To: <4BC0E972.7@foobar.org> References: <3801097.338.1270873377626.JavaMail.franck@franck-martins-macbook-pro.local> <4BC0E972.7@foobar.org> Message-ID: On Sat, Apr 10, 2010 at 5:11 PM, Nick Hilliard wrote: > > I'm puzzled as to why you might think that this would incentivise > meaningful deployment of ipv6. > > Nick > > It removes the hurdle of working with the RIR and/or getting management buy-in to go negotiate for number resources. (Our personal experience as a community/end-user network is that ARIN wants justification for the minimum address space one can live with. At this early stage of deployment, that raises concerns over whether we have a workable address plan in place. We worked with ARIN to eventually get a /41 assigned. With the prospect of assigning /56s to every customer port we have on an edge switch, that's not going to last long. You can probably argue we got the initial request wrong, but it still means we have to go back and negotiate again, which we haven't found to be much fun. That's holding us back.) -- Tim:> From richard at bennett.com Sat Apr 10 16:43:53 2010 From: richard at bennett.com (Richard Bennett) Date: Sat, 10 Apr 2010 14:43:53 -0700 Subject: FCC dealt major blow in net neutrality ruling favoring, Comcast In-Reply-To: References: Message-ID: <4BC0F119.2030802@bennett.com> The FCC is structured in such a way that the chairman calls all the shots on policy matters. In this instance, the former chairman, Kevin Martin, was responsible for the Comcast order but the current chairman, Julius Genachowski, had to defend it in court. Some wags insist that the defense was a bit lackluster because Genachowski didn't much care for the legal basis of the Comcast order, which relied on a lot of smoke and mirrors to regulate aspects of edge network behavior that Congress never told the FCC to regulate. The defense relied on some legal theories that weren't used in the order itself, and that's a no-no in an appeal. The court took the rather extraordinary step of suggesting arguments that the FCC could have used in the appeal that it didn't use. The murky status of Internet regulation is actually quite enjoyable to network operators and to policy wonks alike because it allows maximum freedom of action. This will continue, of course, until Congress tells the FCC to go regulate the Internet according to some yet-to-be-defined framework. RB On 4/10/2010 1:36 PM, Patrick W. Gilmore wrote: > On Apr 9, 2010, at 7:04 PM, Jared Mauch wrote: > > >> > I believe you are doing a disservice to the FCC by making these inflammatory statements. >> > And here I thought I was defending them for being different& better than the last group. > > The point is, joe asked about the FCC that made a ruling. The staffers who work hard (and deserve lots of credit for working hard) do not make those rulings. The political appointees and their handlers in the administration make those rulings. Those appointees are very different than the last group. And I think this is a very good thing. > > For instance, could you in your wildest dreams have imagined the last group sending their top people to NANOG, and those people standing around asking people to talk to them? That was AWESOME, and very different than the "last FCC". > > And I don't think there is anything wrong with thinking of it that way. > > -- TTFN, patrick >> > There are plenty of GOOD people at the FCC, I'm guessing you may not have spent much time talking to them. (I met with the FCC about CALEA due to concerns about there being no mature 10G intercept platforms. There are vendors that are shipping devices that are not CALEA compliant, but may be compliant under other lawful intercept methods/statutes). >> > >> > You have to understand that there are political appointees (that must be confirmed) and the regular staffers that operate in this space. The federal register and comment process is abundant, allowing people to file comments on nearly anything the government is discussing. >> > >> > If you've not engaged in getting the daily notices from the Federal Register, and did not file form 445, you may want to take a look at it. Phone the FCC. Phone the DoJ and ask for the "CALEA Implementation Unit", the folks there are behind thehttp://askcalea.net website. >> > >> > As with many things, there is a lot of (mis-)information out there. >> > >> > (Gotta run kids are bleeding!). >> > >> > > > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From jcdill.lists at gmail.com Sat Apr 10 23:21:04 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Sat, 10 Apr 2010 21:21:04 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4BBF5C45.3070406@otd.com> References: <201004091121.o39BLkLL025885@aurora.sol.net> <9815F8F0-9337-4BCB-9941-9465437A2B1C@delong.com> <4BBF5C45.3070406@otd.com> Message-ID: <4BC14E30.1080302@gmail.com> Dave Israel wrote: > On 4/9/2010 12:30 PM, Owen DeLong wrote: > >>> Put differently, you work in this arena too... you've presumably >>> talked to stakeholders. Can you list some of the reasons people have >>> provided for not adopting v6, and are any of them related to the v6 >>> policies regarding address space? >>> >>> >> Reasons: >> >> > > (many excellent reasons removed) > > Let me just add on: (more excellent reasons removed) I'm surprised no one has yet mentioned cost. Even if all the network equipment (hardware and software) in a given network were already v6 compatible, there's a substantial cost to train, test, document, deploy, support. Most companies will put this cost off for as long as possible, unless there are clear cost savings to be had by deploying sooner. Add in the problems getting vendors to produce v6 compatible networking equipment. Add in the cost to upgrade legacy systems to v6 compatible equipment (when available). Most companies are trying to determine the optimum time to upgrade, and at this point they believe that this time is still in the future, not now. Some of them will be up against a Y2K type of deadline when the v4 space runs out, scrambling to move to v6 when they need more IPs and can't get anymore usable v4 addresses. jc From franck at genius.com Sun Apr 11 00:33:37 2010 From: franck at genius.com (Franck Martin) Date: Sun, 11 Apr 2010 17:33:37 +1200 (MAGST) Subject: 32 bits ASN on Cisco In-Reply-To: <16919411.9.1270963736494.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <25855213.12.1270964016384.JavaMail.franck@franck-martins-macbook-pro.local> Sorry if it is not the right forum, but I'm trying to get a grip on 32Bits ASN on Cisco I see that feature is available on 12.4(24)T http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/data_sheet_C78-521821.html Which is available only for "new gear". I don't know how new is the 1800,2800,3800 series, but I know networks still running on 2500 and 2600. So does it mean that to get 32bit ASN you need to get new gear? Seems to me 12.4(24)T is relatively new, and that this feature is not available on the mainline IOS 12.4? So in one hand RIR allocates 32bit ASN, but on the other hand, it is hard to implement it on current equipment? Is that a (un)fair assessment? From giesen at snickers.org Sun Apr 11 01:36:01 2010 From: giesen at snickers.org (Gary T. Giesen) Date: Sun, 11 Apr 2010 02:36:01 -0400 Subject: 32 bits ASN on Cisco In-Reply-To: <25855213.12.1270964016384.JavaMail.franck@franck-martins-macbook-pro.local> References: <16919411.9.1270963736494.JavaMail.franck@franck-martins-macbook-pro.local> <25855213.12.1270964016384.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: You can still request a 16 bit ASN from the registries, so if this is a concern for a new deployment you're not out of luck (yet). There is a compatibility mechanism, so you can still receive routes sourced from (or passing through) 32 bit ASNs, they will simply appear as AS 23456. Even if you have 32-bit ASN-compatible gear, all your direct peers need to support it as well (more or less), and many providers still don't have support for this yet (for example, the 7600 platform only just got support with 12.2(33) SRE0, and no one in their right mind is running it in production yet). A great resource for information on 32-bit ASN's is http://www.nanog.org/meetings/nanog45/presentations/Tuesday/Hankins_4byteASN_N45.pdf GG On Sun, Apr 11, 2010 at 1:33 AM, Franck Martin wrote: > Sorry if it is not the right forum, but I'm trying to get a grip on 32Bits ASN on Cisco > > I see that feature is available on 12.4(24)T > http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/data_sheet_C78-521821.html > > Which is available only for "new gear". I don't know how new is the 1800,2800,3800 series, but I know networks still running on 2500 and 2600. > > So does it mean that to get 32bit ASN you need to get new gear? > > Seems to me 12.4(24)T is relatively new, and that this feature is not available on the mainline IOS 12.4? > > So in one hand RIR allocates 32bit ASN, but on the other hand, it is hard to implement it on current equipment? Is that a (un)fair assessment? > > From franck at genius.com Sun Apr 11 05:15:28 2010 From: franck at genius.com (Franck Martin) Date: Sun, 11 Apr 2010 22:15:28 +1200 (MAGST) Subject: 32 bits ASN on Cisco In-Reply-To: Message-ID: <9561177.18.1270980924743.JavaMail.franck@franck-martins-macbook-pro.local> Yes Gary, I understood how to run 16bit ASN with 32bit ASN, I'm just trying to confirm/understand how it is supported today on Cisco hardware. I have seen for instance policy change in APNIC, as since this year they assign 32bits ASN (which could fall in the 16bit part if you are lucky) but if you want a 16bit, then you need to justify. I feel this policy is a bit premature as hardware does not support it. I guess this exhaustion is not as critical as for IPv4, but still... To come back, to your statement that says it is just supported on 7200, means you cannot use a 32bit ASN in production today on any hardware? ----- Original Message ----- From: "Gary T. Giesen" To: "Franck Martin" Cc: nanog at nanog.org Sent: Sunday, 11 April, 2010 6:36:01 PM Subject: Re: 32 bits ASN on Cisco You can still request a 16 bit ASN from the registries, so if this is a concern for a new deployment you're not out of luck (yet). There is a compatibility mechanism, so you can still receive routes sourced from (or passing through) 32 bit ASNs, they will simply appear as AS 23456. Even if you have 32-bit ASN-compatible gear, all your direct peers need to support it as well (more or less), and many providers still don't have support for this yet (for example, the 7600 platform only just got support with 12.2(33) SRE0, and no one in their right mind is running it in production yet). A great resource for information on 32-bit ASN's is http://www.nanog.org/meetings/nanog45/presentations/Tuesday/Hankins_4byteASN_N45.pdf GG From jeroen at mompl.net Sun Apr 11 05:18:28 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Sun, 11 Apr 2010 03:18:28 -0700 Subject: Commodore PET, was: Re: legacy /8 In-Reply-To: References: <201004041249.o34CnUUt078737@aurora.sol.net> Message-ID: <4BC1A1F4.9010801@mompl.net> Roland Perry wrote: > There are at least two sources which date the PET to "Winter CES" and > "Jan 1977", but I agree that June CES is where production items would be > first shown; however by then schools were out and my project was > finished (I was studying to be maths teacher). I thought people might like to know: According to the book "On the edge" by Brian Bagnall the first showing was in March 1977. In January of 1977 it was announced at the CES. The machine was there but had a tiny but hard to find bug that prevented it from working until the last day, then when it worked the image was upside down. It was shown to John Roach, then an operations guy of Rat Shack. He was interested to have it distributed in their stores but because Jack Tramiel also demanded they'd order a lot of Commodore's calculators John Roach didn't go through with the deal and decided they could make their own... missed opportunities. quoting page56, "The birth of an Industry" "Leonard Tramiel unveiled the PET 2001 to the world. "The first showing of the PET was at the Hanover Faire in Germany in March 1977," recalls Leonard. "It was shown first at the Hanover Faire in that hand-carved wooden case." (..) A month later they would unveil the PET in the United States" (end quote) That was at the West Coast Computer Faire in mid-April of 1977, organised by Jim Warren of Dr. Dobbs Journal. The first major gather of hobbyists and microcomputer companies. Apparently an important moment in the microcomputer history. Greetings, Jeroen From lukasz at bromirski.net Sun Apr 11 05:31:05 2010 From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=) Date: Sun, 11 Apr 2010 12:31:05 +0200 Subject: 32 bits ASN on Cisco In-Reply-To: <9561177.18.1270980924743.JavaMail.franck@franck-martins-macbook-pro.local> References: <9561177.18.1270980924743.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4BC1A4E9.6080306@bromirski.net> On 2010-04-11 12:15, Franck Martin wrote: > To come back, to your statement that says it is just supported on 7200, > means you cannot use a 32bit ASN in production today on any hardware? It doesn't mean anything like that. As the software is available for some time already, you can run 32bit ASN in production today, and actually people do that. Nothing fancy. For the list of software versions supporting 32 bit ASN please referer to this document: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/data_sheet_C78-521821.html But yes, you can't run it on 2500 and 2600 as they're for long time End of Life/Engineering/Support/Everything. -- "Everything will be okay in the end. | ?ukasz Bromirski If it's not okay, it's not the end." | http://lukasz.bromirski.net From franck at genius.com Sun Apr 11 06:15:57 2010 From: franck at genius.com (Franck Martin) Date: Sun, 11 Apr 2010 23:15:57 +1200 (MAGST) Subject: 32 bits ASN on Cisco In-Reply-To: <5680978.32.1270984335072.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <31080675.34.1270984555582.JavaMail.franck@franck-martins-macbook-pro.local> This is the document I quoted in my first email. ok for 2500, 2600 they are EOL, but still out there.. but Gary says the software is too new to be used on prod, and you say there is no problem. So who is right? I see that 12.4(24)T has been released in Feb last year. Do people follow the router upgrades closely? What is the common sense? ----- Original Message ----- From: "?ukasz Bromirski" To: nanog at nanog.org Sent: Sunday, 11 April, 2010 10:31:05 PM Subject: Re: 32 bits ASN on Cisco On 2010-04-11 12:15, Franck Martin wrote: > To come back, to your statement that says it is just supported on > 7200, means you cannot use a 32bit ASN in production today on any > hardware? It doesn't mean anything like that. As the software is available for some time already, you can run 32bit ASN in production today, and actually people do that. Nothing fancy. For the list of software versions supporting 32 bit ASN please referer to this document: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/data_sheet_C78-521821.html But yes, you can't run it on 2500 and 2600 as they're for long time End of Life/Engineering/Support/Everything. -- "Everything will be okay in the end. | ?ukasz Bromirski If it's not okay, it's not the end." | http://lukasz.bromirski.net From lukasz at bromirski.net Sun Apr 11 08:40:42 2010 From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=) Date: Sun, 11 Apr 2010 15:40:42 +0200 Subject: 32 bits ASN on Cisco In-Reply-To: <31080675.34.1270984555582.JavaMail.franck@franck-martins-macbook-pro.local> References: <31080675.34.1270984555582.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4BC1D15A.7010506@bromirski.net> On 2010-04-11 13:15, Franck Martin wrote: > This is the document I quoted in my first email. > ok for 2500, 2600 they are EOL, but still out there.. A lot of boxes is still out there, sure. Some of them can't be upgraded, and it is not a problem unique only for Cisco. > but Gary says the software is too new to be used on > prod, and you say there is no problem. I didn't say there's no problem with the software - depending on your network size, features, load and millions other characteristics, some of the software may be unusable, where others will say "it works for me". 7600 guys should follow 12.2SR track, so the 12.2(33)SRE and rebuils are natural way of going forward. ISR guys (access) are usually implementing a multiservice boxes, so need new features - and they appear in 15.0(1)M, as entire 12.4T line is going EoS/EoL soon. For the legacy platforms, like 1600, 1700, 2600, 3600, 3700 the last software that runs is 12.4(15)T and rebuilds - and while it's unfortunate they don't support 32 bit ASNs, they reached EoS status before the feature was implemented, so according to Cisco rules, no new features can appear in EoSed software, only fixes. In reality, you either test yourself if the software is OK for your network, or pay for such tests/audit. While the line 'trust your vendor' looks nice, people usually do test before deployment. So you may get thousands of different opinions what's working and what is not, but for such discussions it would be better to move to cisco-nsp at . -- "Everything will be okay in the end. | ?ukasz Bromirski If it's not okay, it's not the end." | http://lukasz.bromirski.net From rs at seastrom.com Sun Apr 11 09:07:15 2010 From: rs at seastrom.com (Robert E. Seastrom) Date: Sun, 11 Apr 2010 10:07:15 -0400 Subject: Solar Flux (was: Re: China prefix hijack) In-Reply-To: (Paul Vixie's message of "Fri, 09 Apr 2010 17:17:23 +0000") References: <20100408171935.GD30450@staff.dca.net> <001f01cad740$ccf0c390$4401a8c0@jgbpc> <20100408174405.GD4808@dan.olp.net> Message-ID: <867hoet758.fsf_-_@seastrom.com> Paul Vixie writes: > i'm more inclined to blame the heavy solar wind this month and to assume > that chinanet's routers don't use ECC on the RAM containing their RIBs and > that chinanet's router jockeys are in quite a sweat about this bad publicity. > -- > Paul Vixie > KI6YSY That is likely to be an increasing problem in upcoming months/years. Solar cycle 24 started in August '09; we're ramping up on the way out of a more serious than usual sunspot minimum. We've seen great increases in CPU and memory speeds as well as disk densities since the last maximum (March 2000). Speccing ECC memory is a reasonable start, but this sort of thing has been a problem in the past (anyone remember the Sun UltraSPARC CPUs that had problems last time around?) and will no doubt bite us again. Rob Seastrom, AI4UC From erik_list at caneris.com Sun Apr 11 09:38:27 2010 From: erik_list at caneris.com (Erik L) Date: Sun, 11 Apr 2010 10:38:27 -0400 Subject: Seeking Amazon EC2 abuse contact Message-ID: Could someone from Amazon EC2 please contact me off-list regarding an abuse issue from one of their IPs? Alternatively, could someone please send me the contact details of someone there? E-mailing the abuse e-mail listed in WHOIS per their instructions, including all pertinent data, results in an auto-reply indicating to use a form on their site. Submitting the form results in "There has been an error while submitting your data. Please try again later." Calling their supposed NOC (as per WHOIS) results in "You have reached the legal department at Amazon...please leave a message". Thanks -- Erik Caneris Inc. Tel: 647-723-6365 Fax: 647-723-5365 Toll-free: 1-888-444-8843 www.caneris.com From wavetossed at googlemail.com Sun Apr 11 10:58:40 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Sun, 11 Apr 2010 16:58:40 +0100 Subject: Solar Flux (was: Re: China prefix hijack) In-Reply-To: <867hoet758.fsf_-_@seastrom.com> References: <20100408171935.GD30450@staff.dca.net> <001f01cad740$ccf0c390$4401a8c0@jgbpc> <20100408174405.GD4808@dan.olp.net> <867hoet758.fsf_-_@seastrom.com> Message-ID: > That is likely to be an increasing problem in upcoming months/years. > Solar cycle 24 started in August '09; we're ramping up on the way out > of a more serious than usual sunspot minimum. I wonder what kind of buildings are less susceptible to these kinds of problems. And is there a good way to test your data centre to come up with some kind of vulnerability rating? Would a Faraday cage be sufficient to protect against cosmic ray bit-flipping and how could you retrofit a Faraday cage onto a rack or two of gear? --Michael Dillon From vixie at isc.org Sun Apr 11 11:03:54 2010 From: vixie at isc.org (Paul Vixie) Date: Sun, 11 Apr 2010 16:03:54 +0000 Subject: Commodore PET, was: Re: legacy /8 In-Reply-To: <4BC1A1F4.9010801@mompl.net> (Jeroen van Aart's message of "Sun\, 11 Apr 2010 03\:18\:28 -0700") References: <201004041249.o34CnUUt078737@aurora.sol.net> <4BC1A1F4.9010801@mompl.net> Message-ID: Jeroen van Aart writes: > ... > > That was at the West Coast Computer Faire in mid-April of 1977, organised > by Jim Warren of Dr. Dobbs Journal. The first major gather of hobbyists > and microcomputer companies. Apparently an important moment in the > microcomputer history. seems like i saw an Apple I at that show, and also a SOL, which i remember thinking very highly of since it had an S-100 bus. the PET was there but with the itty bitty keyboard the machine was a bit of a head-scratcher for the crowd. -- Paul Vixie KI6YSY From pl+list at pmacct.net Sun Apr 11 11:04:03 2010 From: pl+list at pmacct.net (Paolo Lucente) Date: Sun, 11 Apr 2010 16:04:03 +0000 Subject: 32 bits ASN on Cisco In-Reply-To: <31080675.34.1270984555582.JavaMail.franck@franck-martins-macbook-pro.local> References: <5680978.32.1270984335072.JavaMail.franck@franck-martins-macbook-pro.local> <31080675.34.1270984555582.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <20100411160403.GA18420@moussaka.pmacct.net> The reference to a IOS supporting 32-bit ASNs being too fresh was specific to the 7600 platform and the SRE software train. As of SRE1, for example, NetFlow v9 template still advertizes source and destination ASNs fields as 2 bytes long. Cheers, Paolo On Sun, Apr 11, 2010 at 11:15:57PM +1200, Franck Martin wrote: > This is the document I quoted in my first email. > > ok for 2500, 2600 they are EOL, but still out there.. > > but Gary says the software is too new to be used on prod, and you say there is no problem. So who is right? I see that 12.4(24)T has been released in Feb last year. Do people follow the router upgrades closely? What is the common sense? > > ----- Original Message ----- > From: "??ukasz Bromirski" > To: nanog at nanog.org > Sent: Sunday, 11 April, 2010 10:31:05 PM > Subject: Re: 32 bits ASN on Cisco > > On 2010-04-11 12:15, Franck Martin wrote: > > > To come back, to your statement that says it is just supported on > > 7200, means you cannot use a 32bit ASN in production today on any > > hardware? > > It doesn't mean anything like that. > > As the software is available for some time already, you can > run 32bit ASN in production today, and actually people do that. > Nothing fancy. > > For the list of software versions supporting 32 bit ASN please > referer to this document: > http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/data_sheet_C78-521821.html > > But yes, you can't run it on 2500 and 2600 as they're for long time > End of Life/Engineering/Support/Everything. > > -- "Everything will be okay in the end. | ??ukasz Bromirski > If it's not okay, it's not the end." | http://lukasz.bromirski.net > From jgreco at ns.sol.net Sun Apr 11 11:17:17 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 11 Apr 2010 11:17:17 -0500 (CDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: from "Owen DeLong" at Apr 09, 2010 09:59:17 AM Message-ID: <201004111617.o3BGHHn3024246@aurora.sol.net> > > Put less tersely: > > > > We were assigned space, under a policy whose purpose was primarily to > > guarantee uniqueness in IPv4 numbering. As with other legacy holders, > > we obtained portable space to avoid the technical problems associated > > with renumbering, problems with in-addr.arpa subdelegation, etc. > > So far, correct. > > > Part of that was an understanding that the space was ours (let's not > > get distracted by any "ownership" debate, but just agree for the sake > > of this point that it was definitely understood that we'd possess it). > > This served the good of the Internet by promoting stability within an > > AS and allowed us to spend engineering time on finer points (such as > > maintaining PTR's) rather than renumbering gear every time we changed > > upstreams. > > > This is fictitious unless you are claiming that your allocation predates: > > RFC2050 November, 1996 > RFC1466 May, 1993 > RFC1174 August, 1990 > > Prior to that, it was less clear, but, the concept was still generally > justified need so long as that need persisted. Which ours does. > > Eventually InterNIC was disbanded, and components went in various > > directions. ARIN landed the numbering assignment portion of InterNIC. > > Along with that, maintenance of the legacy resources drifted along to > > ARIN. > > Actually, ARIN was spun off from InterNIC (containing most of the same > staff that had been doing the job at InterNIC) well before InterNIC was > disbanded. Is there an effective difference or are you just quibbling? For the purposes of this discussion, I submit my description was suitable to describe what happened. > > ARIN might not have a contract with us, or with other legacy holders. > > It wasn't our choice for ARIN to be tasked with holding up InterNIC's > > end of things. However, it's likely that they've concluded that they > > better do so, because if they don't, it'll probably turn into a costly > > legal battle on many fronts, and I doubt ARIN has the budget for that. > > This is going to be one of those situations that could become a > legal battle on many fronts either way. On the one hand you have > legacy holders who have no contractual right to services from > anyone (If you want to pursue InterNIC for failing to live up to > whatever agreement you have/had with them, I wish you the > very best of luck in that endeavor, especially since you don't > have a written contract from them, either). > > On the other hand, in a relatively short timeframe, you are likely > to have litigants asking why ARIN has failed to reclaim/reuse > the underutilized IPv4 space sitting in so many legacy registrations. > > Which of those two bodies of litigants is larger or better funded > is left as an exercise for the reader. Nonetheless, ARIN is > going to be in an interesting position between those two > groups (which one is rock and which is hard place is also > left as an exercise for the reader) going forward regardless > of what action is taken by ARIN in this area. > > That is why the legacy RSA is important. It represents ARIN > trying very hard to codify and defend the rights of the legacy > holders. Yes, but according to the statistics provided by Mr. Curran, it looks like few legacy space holders are actually adopting the LRSA. Like many tech people, you seem to believe that the absence of a "contract" means that there's no responsibility, and that InterNIC's having been disbanded absolves ARIN from responsibility. In the real world, things are not so simple. The courts have much experience at looking at real world situations and determining what should happen. These outcomes are not always predictable and frequently don't seem to have obvious results, but they're generally expensive fights. > > As a legacy holder, we don't really care who is currently "responsible" > > for legacy maintenance/etc. However, whoever it is, if they're not > > going to take on those responsibilities, that's a problem. > > You assume that anyone is currently responsible. What documentation > do you have that there is any such responsibility? > > As a point in fact, ARIN has, for the good of the community, extended > the courtesy of maintaining those records and providing services > to legacy holders free of charge because it is perceived as being > in the best interests of the community. That's only one possible interpretation. A court might well reach a more general conclusion that ARIN is the successor to InterNIC, and has agreed to honor legacy registrations. That'd be inconvenient for ARIN, but is a very reasonable possible outcome. > > The previous poster asked, "If you don't have a contract with ARIN, > > why should ARIN provide you with anything?" > > > > Well, the flip side to that is, "ARIN doesn't have a contract with us, > > but we still have copies of the InterNIC policies under which we were > > assigned space, and ARIN undertook those duties, so ARIN is actually > > the one with significant worries if they were to try to pull anything, > > otherwise, we don't really care." > > Could you please provide those to Steve Ryan, John Curran, and, > ideally, I'd like to see them too. > > > Is that a suitable defense of that statement (which might not have > > been saying quite what you thought)? > > I don't know. I have yet to see the content of the documents which > you claim are your defense. I'd be pleased to pull them off our backups for our normal hourly rates. Otherwise, you're encouraged to do your own research. ... 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 hescominsoon at emmanuelcomputerconsulting.com Sun Apr 11 11:31:28 2010 From: hescominsoon at emmanuelcomputerconsulting.com (William Warren) Date: Sun, 11 Apr 2010 12:31:28 -0400 Subject: legacy /8 In-Reply-To: <32099.1270316348@localhost> References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> <3135E5A4-A45F-44A3-A01D-A86F71988E45@delong.com> <4BB6F65D.4000907@mompl.net> <4BB6FE6F.700@jsbc.cc> <32099.1270316348@localhost> Message-ID: <4BC1F960.3020901@emmanuelcomputerconsulting.com> On 4/3/2010 1:39 PM, Valdis.Kletnieks at vt.edu wrote: > On Sat, 03 Apr 2010 08:06:44 EDT, Jeffrey Lyon said: > > >> For small companies the cost of moving to IPv6 is far too great, >> especially when we rely on certain DDoS mitigation gear that does not >> yet have an IPv6 equivalent. >> > So? How many people are *realistically* being hit by IPv6 DDoS right now? > (I saw a number in the last 2-3 days that 2-3% of spam is now being delivered > via SMTP-over-IPv6). You may not need that gear as much as you thought... > > Did you tell your mitigation gear vendor 5 years ago that their next model > needed to have IPv6 support? > > Given that currently most stuff is dual-stack, and IPv6 isn't totally > widespread, what are the effects of doing IPv6 DDoS mitigation by simply > turning off IPv6 on your upstream link and letting traffic fall back to IPv4 > where you have mitigation gear? > > Not a valid argument. When ipv6 gets widely used then the DDOS will follow it. I have to agree with the previous poster about not wanting to move until his DDOS mitigation gear supports V6. Many of the security products i use are just now starting to go v6 capable. I would not want to move to V6 even if i could until all of my security gear/software is properly V6 tested. From Valdis.Kletnieks at vt.edu Sun Apr 11 11:36:05 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 11 Apr 2010 12:36:05 -0400 Subject: Solar Flux (was: Re: China prefix hijack) In-Reply-To: Your message of "Sun, 11 Apr 2010 16:58:40 BST." References: <20100408171935.GD30450@staff.dca.net> <001f01cad740$ccf0c390$4401a8c0@jgbpc> <20100408174405.GD4808@dan.olp.net> <867hoet758.fsf_-_@seastrom.com> Message-ID: <11626.1271003765@localhost> On Sun, 11 Apr 2010 16:58:40 BST, Michael Dillon said: > Would a Faraday cage be sufficient to protect against cosmic ray bit-flipping > and how could you retrofit a Faraday cage onto a rack or two of gear? Scientists build neutrino detectors in mines 8,000 feet underground because that much rock provides *partial* shielding against cosmic rays causing spurious detection events. Fortunately, the sun emits almost no cosmic rays. It does however spew a lot of less energetic particles that will cause single-bit upsets in electronic gear. Time to double-check that all your gear has ECC ram - the problem with the UltraSparc CPUs last time was that they had some cache chips built by IBM. IBM said "Use these chips in an ECC config", but Sun didn't. The ions hit, and the resulting bit-flips crashed the machines. Incidentally, Sun sued IBM over that, and the judge basically said "Well, IBM *told* you not to do that up front. Suit dismissed". One of the other big issues will be noise on satellite and microwave links screwing your S/N ratio. The one that scares me? Inducted currents on long runs of copper. You get a 200-300 mile 765Kva transmission line, and a solar flare hits, the Earth's magnetic field gets dented, so the field lines move relative to the stationary copper cable, and suddenly you have several thousand extra amps popping out one end of that cable. Ka-blam. The big danger there is that many substations are not designed for that - so it would basically *permanently* destroy that substation and they'd get to replace it. And of course, that's a several-weeks repair even if it's the only one - and in that sort of case, there will be *dozens* of step-down transformers blown up the same afternoon. How long can you run on diesel? ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From micheal at spmedicalgroup.com Sun Apr 11 11:38:14 2010 From: micheal at spmedicalgroup.com (Micheal Patterson) Date: Sun, 11 Apr 2010 11:38:14 -0500 Subject: Solar Flux (was: Re: China prefix hijack) References: <20100408171935.GD30450@staff.dca.net><001f01cad740$ccf0c390$4401a8c0@jgbpc><20100408174405.GD4808@dan.olp.net> <867hoet758.fsf_-_@seastrom.com> Message-ID: <2E09F371AFB34319A737ED122F6B2098@dredster> I'm more inclined to believe that it would be a solar conjunction actually. The scenerio would be that they lost track of their bird and started tracking the sun. Since we all know that old Sol is an excellant originating point of radiated noise, surely with that much noise, and a solid lock on it, the odds of its random noise being something decipherable are much more acceptable than normal. ----- Original Message ----- From: "Robert E. Seastrom" To: "Paul Vixie" Cc: Sent: Sunday, April 11, 2010 9:07 AM Subject: Solar Flux (was: Re: China prefix hijack) > > Paul Vixie writes: > >> i'm more inclined to blame the heavy solar wind this month and to assume >> that chinanet's routers don't use ECC on the RAM containing their RIBs >> and >> that chinanet's router jockeys are in quite a sweat about this bad >> publicity. >> -- >> Paul Vixie >> KI6YSY > > That is likely to be an increasing problem in upcoming months/years. > Solar cycle 24 started in August '09; we're ramping up on the way out > of a more serious than usual sunspot minimum. > > We've seen great increases in CPU and memory speeds as well as disk > densities since the last maximum (March 2000). Speccing ECC memory is > a reasonable start, but this sort of thing has been a problem in the > past (anyone remember the Sun UltraSPARC CPUs that had problems last > time around?) and will no doubt bite us again. > > Rob Seastrom, AI4UC > From hescominsoon at emmanuelcomputerconsulting.com Sun Apr 11 11:40:51 2010 From: hescominsoon at emmanuelcomputerconsulting.com (William Warren) Date: Sun, 11 Apr 2010 12:40:51 -0400 Subject: legacy /8 In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> Message-ID: <4BC1FB93.3060706@emmanuelcomputerconsulting.com> On 4/3/2010 1:31 PM, George Bonser wrote: > > >> -----Original Message----- >> From: Larry Sheldon [mailto:LarrySheldon at cox.net] >> Sent: Saturday, April 03, 2010 8:43 AM >> To: nanog at nanog.org >> Subject: Re: legacy /8 >> >> On 4/3/2010 10:34, Michael Dillon wrote: >> >>>> That adoption is so low at this point really says that it has >>>> >> failed. >> >>> In the real world, there is no success or failure, only next steps. >>> At this point, IPv4 has failed, >>> >> Failed? Really?!!?! >> >> > Failed in the sense that I am not sure there is enough time left to > really get v6 deployment going before we hit the wall. It is like > skydiving and waiting too long to open the chute. > > Any school teaching v4 at this point other than as a legacy protocol > that they teach on the second year because "they might see it in the > wild" should be closed down. All new instruction that this point should > begin and end with v6 with v4 as an "aside". But that isn't. > > > > We've been dealing with the IPV4 myth now for over 7 years that i have followed it. It's about as valid as the exaflood myth. Part fo the reason folks aren't rushing to the V6 bandwagon is it's not needed. Stop doing the chicken little dance folks. V6 is nice and gives us tons of more addresses but I can tell you V4 is more than two years form "dying" just by seeing all the arm flailing going around. From giesen at snickers.org Sun Apr 11 11:44:43 2010 From: giesen at snickers.org (Gary T. Giesen) Date: Sun, 11 Apr 2010 12:44:43 -0400 Subject: 32 bits ASN on Cisco In-Reply-To: <9561177.18.1270980924743.JavaMail.franck@franck-martins-macbook-pro.local> References: <9561177.18.1270980924743.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: There's quite a bit of hardware that does support it, including JunOS since 9.1 (I believe). But there's still a few lagging platforms (especially on the Cisco side) that does not yet support it. IOS 15 does indeed support it, so there is support for it in mainline code on the smaller routers. It's just that a few key platforms are still missing it (or the code is too new to be useful). Keep in mind, the 2500's and I believe the 2600's have been EOL'd for quite some time now, so you will never likely see support for those platforms. GG On Sun, Apr 11, 2010 at 6:15 AM, Franck Martin wrote: > Yes Gary, I understood how to run 16bit ASN with 32bit ASN, I'm just trying to confirm/understand how it is supported today on Cisco hardware. > > I have seen for instance policy change in APNIC, as since this year they assign 32bits ASN (which could fall in the 16bit part if you are lucky) but if you want a 16bit, then you need to justify. I feel this policy is a bit premature as hardware does not support it. I guess this exhaustion is not as critical as for IPv4, but still... > > To come back, to your statement that says it is just supported on 7200, means you cannot use a 32bit ASN in production today on any hardware? > > ----- Original Message ----- > From: "Gary T. Giesen" > To: "Franck Martin" > Cc: nanog at nanog.org > Sent: Sunday, 11 April, 2010 6:36:01 PM > Subject: Re: 32 bits ASN on Cisco > > You can still request a 16 bit ASN from the registries, so if this is > a concern for a new deployment you're not out of luck (yet). There is > a compatibility mechanism, so you can still receive routes sourced > from (or passing through) 32 bit ASNs, they will simply appear as AS > 23456. Even if you have 32-bit ASN-compatible gear, all your direct > peers need to support it as well (more or less), and many providers > still don't have support for this yet (for example, the 7600 platform > only just got support with 12.2(33) SRE0, and no one in their right > mind is running it in production yet). > > A great resource for information on 32-bit ASN's is > http://www.nanog.org/meetings/nanog45/presentations/Tuesday/Hankins_4byteASN_N45.pdf > > GG > > > From owen at delong.com Sun Apr 11 11:39:41 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 11 Apr 2010 09:39:41 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004111617.o3BGHHn3024246@aurora.sol.net> References: <201004111617.o3BGHHn3024246@aurora.sol.net> Message-ID: <0D478936-091E-4807-B1B3-025C86154387@delong.com> On Apr 11, 2010, at 9:17 AM, Joe Greco wrote: >>> Put less tersely: >>> >>> We were assigned space, under a policy whose purpose was primarily to >>> guarantee uniqueness in IPv4 numbering. As with other legacy holders, >>> we obtained portable space to avoid the technical problems associated >>> with renumbering, problems with in-addr.arpa subdelegation, etc. >> >> So far, correct. >> >>> Part of that was an understanding that the space was ours (let's not >>> get distracted by any "ownership" debate, but just agree for the sake >>> of this point that it was definitely understood that we'd possess it). >>> This served the good of the Internet by promoting stability within an >>> AS and allowed us to spend engineering time on finer points (such as >>> maintaining PTR's) rather than renumbering gear every time we changed >>> upstreams. >>> >> This is fictitious unless you are claiming that your allocation predates: >> >> RFC2050 November, 1996 >> RFC1466 May, 1993 >> RFC1174 August, 1990 >> >> Prior to that, it was less clear, but, the concept was still generally >> justified need so long as that need persisted. > > Which ours does. > >>> Eventually InterNIC was disbanded, and components went in various >>> directions. ARIN landed the numbering assignment portion of InterNIC. >>> Along with that, maintenance of the legacy resources drifted along to >>> ARIN. >> >> Actually, ARIN was spun off from InterNIC (containing most of the same >> staff that had been doing the job at InterNIC) well before InterNIC was >> disbanded. > > Is there an effective difference or are you just quibbling? For the > purposes of this discussion, I submit my description was suitable to > describe what happened. > Your description makes it sound like there was limited or no continuity between the former and the current registration services entity. I point out that ARIN was formed run by and including most of the IP-related staff from InterNIC. I consider that a substantive distinction. >>> ARIN might not have a contract with us, or with other legacy holders. >>> It wasn't our choice for ARIN to be tasked with holding up InterNIC's >>> end of things. However, it's likely that they've concluded that they >>> better do so, because if they don't, it'll probably turn into a costly >>> legal battle on many fronts, and I doubt ARIN has the budget for that. >> >> This is going to be one of those situations that could become a >> legal battle on many fronts either way. On the one hand you have >> legacy holders who have no contractual right to services from >> anyone (If you want to pursue InterNIC for failing to live up to >> whatever agreement you have/had with them, I wish you the >> very best of luck in that endeavor, especially since you don't >> have a written contract from them, either). >> >> On the other hand, in a relatively short timeframe, you are likely >> to have litigants asking why ARIN has failed to reclaim/reuse >> the underutilized IPv4 space sitting in so many legacy registrations. >> >> Which of those two bodies of litigants is larger or better funded >> is left as an exercise for the reader. Nonetheless, ARIN is >> going to be in an interesting position between those two >> groups (which one is rock and which is hard place is also >> left as an exercise for the reader) going forward regardless >> of what action is taken by ARIN in this area. >> >> That is why the legacy RSA is important. It represents ARIN >> trying very hard to codify and defend the rights of the legacy >> holders. > > Yes, but according to the statistics provided by Mr. Curran, it looks > like few legacy space holders are actually adopting the LRSA. > So far, yes. That's unfortunate. > Like many tech people, you seem to believe that the absence of a > "contract" means that there's no responsibility, and that InterNIC's > having been disbanded absolves ARIN from responsibility. In the real > world, things are not so simple. The courts have much experience at > looking at real world situations and determining what should happen. > These outcomes are not always predictable and frequently don't seem to > have obvious results, but they're generally expensive fights. > No, actually, quite the opposite. I believe that BOTH legacy holders and ARIN have responsibilities even though there is no contract. I believe that ARIN is, however, responsible to the community as it exists today and not in any way responsible to legacy holders who choose to ignore that community and their responsibilities to it. The reality is that the community has evolved. For the most part, the community has been willing to let legacy holders live in their little reality distortion bubble and accommodated their eccentricities. I think that is as it should be, to some extent. On the other hand, I think the history now shows that ARIN's failure to immediately institute the same renewal pricing model on legacy holders as on new registrants has created an unfortunate disparity and a number of unfortunate perceptions. Contrast this with APNIC and the domain registrars/registries shortly after the ARIN spinoff from InterNIC, where, yes, there was much grumbling from those of us who had legacy (domain, ip resources) from them, but, in the long run, we paid our fees and moved on. Had ARIN done this on day one, perhaps it would have gone the same way. Instead, we have a situation where the mere mention of requiring legacy holders to pay a token annual fee like the rest of IP end-users in the ARIN region leads to discussions like this. FWIW, I'm a legacy holder myself, but, I have signed the LRSA and I do have IPv6 resources under an RSA as well. No harm has come to me as a result and it is not costing me any more to have done so. In fact, I got my IPv6 assignment for a good discount in the process, but, that deal is no longer available. Frankly, I find it remarkably short-sighted that so many legacy holders have refused to sign the LRSA. Especially in light of the fact that if you are sitting on excess resources and want to be able to transfer them under NRPM 8.3, you will need to bring them under LRSA or RSA first and the successor who acquires them from you (under 8.2 or 8.3) will need to sign an RSA for the transfer to be valid. >>> As a legacy holder, we don't really care who is currently "responsible" >>> for legacy maintenance/etc. However, whoever it is, if they're not >>> going to take on those responsibilities, that's a problem. >> >> You assume that anyone is currently responsible. What documentation >> do you have that there is any such responsibility? >> >> As a point in fact, ARIN has, for the good of the community, extended >> the courtesy of maintaining those records and providing services >> to legacy holders free of charge because it is perceived as being >> in the best interests of the community. > > That's only one possible interpretation. A court might well reach a more > general conclusion that ARIN is the successor to InterNIC, and has agreed > to honor legacy registrations. That'd be inconvenient for ARIN, but is a > very reasonable possible outcome. > As a general rule, courts tend to rule that absent an exchange of value, there is no contract. They also tend to rule that contracts which contain significantly inequitable exchanges of value are invalid. Since ARIN is collecting nothing from legacy holders and not getting funded by NSF or other US Government agency the way InterNIC was, it's hard to see where you would find the exchange of value to support that conclusion. Additionally, it could be argued that by refusing to sign the LRSA or RSA and refusing to participate in the community on a level playing field with others, legacy holders are not meeting their obligations under your implied contract theory. IANAL, so I could be completely wrong here and this is just my personal opinion, not a statement of ARIN or the AC. >>> The previous poster asked, "If you don't have a contract with ARIN, >>> why should ARIN provide you with anything?" >>> >>> Well, the flip side to that is, "ARIN doesn't have a contract with us, >>> but we still have copies of the InterNIC policies under which we were >>> assigned space, and ARIN undertook those duties, so ARIN is actually >>> the one with significant worries if they were to try to pull anything, >>> otherwise, we don't really care." >> >> Could you please provide those to Steve Ryan, John Curran, and, >> ideally, I'd like to see them too. >> >>> Is that a suitable defense of that statement (which might not have >>> been saying quite what you thought)? >> >> I don't know. I have yet to see the content of the documents which >> you claim are your defense. > > I'd be pleased to pull them off our backups for our normal hourly rates. > Otherwise, you're encouraged to do your own research. > I've done my own research... I've come up with nothing. You're the one claiming you have documentation to support your assertions... To be blunt, put up or shut up. Owen From Joel.Snyder at Opus1.COM Sun Apr 11 12:04:38 2010 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Sun, 11 Apr 2010 10:04:38 -0700 Subject: Solar Flux In-Reply-To: References: Message-ID: <4BC20126.30808@opus1.com> >I wonder what kind of buildings are less susceptible to these kinds >of problems. And is there a good way to test your data centre >to come up with some kind of vulnerability rating? >Would a Faraday cage be sufficient to protect against cosmic ray >bit-flipping >and how could you retrofit a Faraday cage onto a rack or two of gear? Unfortunately, you're in the wrong part of the spectrum there. Shielding against EMI to protect against solar flares is like ... well, it's like writing IPv6 ACLs to protect your IPv4 network. You're looking in the wrong place. Solar flares have all sorts of effects on earth, including every piece of the EM spectrum (you get ionization, which has secondary effects like interfering with the amateur bands so ham operators can't click at each other very well, and induction of current in long wires because of the magnetic effects), but the nasty effects from our point of view are likely to be in piles of hard and soft x-rays and proton storms. So to answer your questions directly: less susceptible building would be buildings which are constructed of hundred-foot thick solid lead walls under a mile of rock in a salt mine under a mountain in Wyoming. And "no," Faraday cages don't protect against cosmic rays (or most of the other kinds of radiation that a solar flare emits directly). Of course, IANAPhysicist, but I did play one in college for a while. On the other hand, another effect of solar flares is UV radiation, so a good pair of sunglasses and some high-SPF sunblock would be good to have, plus make you look less like a nerd. Unless you use that zinc stuff on your nose, in which case you look more like a nerd. YMMV. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From vixie at isc.org Sun Apr 11 12:27:16 2010 From: vixie at isc.org (Paul Vixie) Date: Sun, 11 Apr 2010 17:27:16 +0000 Subject: legacy /8 In-Reply-To: <4BC1FB93.3060706@emmanuelcomputerconsulting.com> (William Warren's message of "Sun\, 11 Apr 2010 12\:40\:51 -0400") References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> <4BC1FB93.3060706@emmanuelcomputerconsulting.com> Message-ID: William Warren writes: > We've been dealing with the IPV4 myth now for over 7 years that i have > followed it. It's about as valid as the exaflood myth. Part fo the > reason folks aren't rushing to the V6 bandwagon is it's not needed. Stop > doing the chicken little dance folks. V6 is nice and gives us tons of > more addresses but I can tell you V4 is more than two years form "dying" > just by seeing all the arm flailing going around. anyone claiming that the then-existing ipv4 will stop working when the free pool runs out is indeed doing the "chicken little dance". however, for many networks, growth is life, and for them, free pool depletion is a problem. -- Paul Vixie Chairman, ARIN BoT From Valdis.Kletnieks at vt.edu Sun Apr 11 12:39:48 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 11 Apr 2010 13:39:48 -0400 Subject: legacy /8 In-Reply-To: Your message of "Sun, 11 Apr 2010 12:31:28 EDT." <4BC1F960.3020901@emmanuelcomputerconsulting.com> References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> <3135E5A4-A45F-44A3-A01D-A86F71988E45@delong.com> <4BB6F65D.4000907@mompl.net> <4BB6FE6F.700@jsbc.cc> <32099.1270316348@localhost> <4BC1F960.3020901@emmanuelcomputerconsulting.com> Message-ID: <13992.1271007588@localhost> On Sun, 11 Apr 2010 12:31:28 EDT, William Warren said: > On 4/3/2010 1:39 PM, Valdis.Kletnieks at vt.edu wrote: > > Given that currently most stuff is dual-stack, and IPv6 isn't totally > > widespread, what are the effects of doing IPv6 DDoS mitigation by simply > > turning off IPv6 on your upstream link and letting traffic fall back to IPv4 > > where you have mitigation gear? > Not a valid argument. When ipv6 gets widely used then the DDOS will > follow it. Totally valid. IPv6 isn't heavily used *currently*, so it may be perfectly acceptable to deal with the mythological IPv6 DDoS by saying "screw it, turn off the IPv6 prefix, deal with customers on IPv4-only for a few hours". After all, that's *EXACTLY* the way you're doing business now - IPv4 only. So that's obviously a viable way to deal with an IPv6 DDoS - do *exactly what you're doing now*. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ghankins at mindspring.com Sun Apr 11 12:44:08 2010 From: ghankins at mindspring.com (Greg Hankins) Date: Sun, 11 Apr 2010 13:44:08 -0400 Subject: 32 bits ASN on Cisco In-Reply-To: References: <9561177.18.1270980924743.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <20100411174408.GA23595@brocade.com> The AS4 Wiki has a list of software support for most vendors, as well as a bunch of other information related to 32-bit ASNs. http://as4.cluepon.net/index.php/Software_Support More information is always welcome, if you'd like to add something. Greg -- Greg Hankins From owen at delong.com Sun Apr 11 13:09:26 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 11 Apr 2010 11:09:26 -0700 Subject: legacy /8 In-Reply-To: <4BC1FB93.3060706@emmanuelcomputerconsulting.com> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> <4BC1FB93.3060706@emmanuelcomputerconsulting.com> Message-ID: <4A03EAD0-8BDC-408E-A513-41CC6B9F4F7E@delong.com> >> > We've been dealing with the IPV4 myth now for over 7 years that i have followed it. It's about as valid as the exaflood myth. Part fo the reason folks aren't rushing to the V6 bandwagon is it's not needed. Stop doing the chicken little dance folks. V6 is nice and gives us tons of more addresses but I can tell you V4 is more than two years form "dying" just by seeing all the arm flailing going around. IPv4 will not die in 2 years. Growth in IPv4 accessible hosts will stop or become significantly more expensive or both in about 2.5 years (+/- 6 months). The more content and services that are available dual-stack (v4 and v6) by the time that occurs, the less of an issue that fact will be for all concerned. Owen From drc at virtualized.org Sun Apr 11 13:21:17 2010 From: drc at virtualized.org (David Conrad) Date: Sun, 11 Apr 2010 08:21:17 -1000 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <0D478936-091E-4807-B1B3-025C86154387@delong.com> References: <201004111617.o3BGHHn3024246@aurora.sol.net> <0D478936-091E-4807-B1B3-025C86154387@delong.com> Message-ID: Owen, On Apr 11, 2010, at 6:39 AM, Owen DeLong wrote: > Instead, we have a situation where the mere mention > of requiring legacy holders to pay a token annual fee like the rest > of IP end-users in the ARIN region leads to discussions like this. I don't believe the issue is the token annual fee. My guess is that most legacy holders would be willing to pay a "reasonable" service fee to cover rDNS and registration database maintenance (they'd probably be more willing if there were multiple providers of that service, but that's a separate topic). I suspect the issue might be more related to stuff like: > Especially in light of > the fact that if you are sitting on excess resources and want > to be able to transfer them under NRPM 8.3, you will need > to bring them under LRSA or RSA first and the successor who > acquires them from you (under 8.2 or 8.3) will need to sign an > RSA for the transfer to be valid. You appear to be assuming folks are willing to accept ARIN has the right and ability to assert the above (and more). That is, that the entire policy regime under which the NRPM has been defined is one that legacy holders are implicitly bound simply because they happen to operate in ARIN's service region and received IP addresses in the past without any real terms and conditions or formal agreement. I imagine the validity of your assumption will not be established without a definitive legal ruling. I'm sure it will be an interesting court case. In any event, it seems clear that some feel that entering into agreements and paying fees in order to obtain IPv6 address space is hindering deployment of IPv6. While ARIN has in the past waived fees for IPv6, I don't believe there has ever been (nor is there likely to be) a waiver of signing the RSA. Folks who want that should probably get over it. To try to bring this back to topics relevant to NANOG (and not ARIN's PPML), the real issue is that pragmatically speaking, the only obvious alternative to IPv6 is multi-layer NAT and it seems some people are trying to tell you that regardless of how much you might hate multi-layer NAT, how much more expensive you believe it will be operationally, and how much more limiting and fragile it will be because it breaks the end-to-end paradigm, they believe it to be a workable solution. Are there _any_ case studies, analyses with actual data, etc. that shows multi-layer NAT is not workable (scalable, operationally tractable, etc.) or at least is more expensive than IPv6? Regards, -drc From drc at virtualized.org Sun Apr 11 13:34:45 2010 From: drc at virtualized.org (David Conrad) Date: Sun, 11 Apr 2010 08:34:45 -1000 Subject: legacy /8 In-Reply-To: <4A03EAD0-8BDC-408E-A513-41CC6B9F4F7E@delong.com> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> <4BC1FB93.3060706@emmanuelcomputerconsulting.com> <4A03EAD0-8BDC-408E-A513-41CC6B9F4F7E@delong.com> Message-ID: <1E42BBC9-E7EA-4A1B-B62C-335F2D367FCB@virtualized.org> On Apr 11, 2010, at 8:09 AM, Owen DeLong wrote: >> Part fo the reason folks aren't rushing to the V6 bandwagon is it's not needed. Stop doing the chicken little dance folks. V6 is nice and gives us tons of more addresses but I can tell you V4 is more than two years form "dying" just by seeing all the arm flailing going around. > IPv4 will not die in 2 years. I'd wager it won't be dead in 20 years. Of course, a lot depends on what is meant by "dying". > Growth in IPv4 accessible hosts will stop or become significantly more expensive or both in about 2.5 years (+/- 6 months). Growth stopping is extremely unlikely. Growth becoming significantly more expensive is guaranteed. Address utilization efficiency will increase as people see the value in public IPv4 addresses. ISPs interested in continuing to grow will do what it takes to obtain IPv4 addresses and folks with allocated-but-unused addresses will be happy to oblige (particularly when they accept that they only need a couple of public IP addresses for their entire network). At some point, it may be that the cost of obtaining IPv4 will outstrip the cost of migrating to IPv6. If we're lucky. Regards, -drc From rdobbins at arbor.net Sun Apr 11 13:53:55 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 11 Apr 2010 18:53:55 +0000 Subject: legacy /8 In-Reply-To: <13992.1271007588@localhost> References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> <3135E5A4-A45F-44A3-A01D-A86F71988E45@delong.com> <4BB6F65D.4000907@mompl.net> <4BB6FE6F.700@jsbc.cc> <32099.1270316348@localhost> <4BC1F960.3020901@emmanuelcomputerconsulting.com> <13992.1271007588@localhost> Message-ID: <865EA464-E7BF-4608-87F5-DE2334656698@arbor.net> On Apr 12, 2010, at 12:39 AM, wrote: > IPv6 isn't heavily used *currently*, so it may be perfectly acceptable to > deal with the mythological IPv6 DDoS The only IPv6-related DDoS attacks of which I'm aware to date is miscreants going after 6-to-4 gateways in order to disrupt one another's IPv6-tunneled botnet C&C traffic. However, as soon as there are moneymaking opportunities to be had and/or ideological vendettas to be pursued by launching pure IPv6-based DDoS attacks, we can all rest assured they won't let the side down. ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From vixie at isc.org Sun Apr 11 13:58:25 2010 From: vixie at isc.org (Paul Vixie) Date: Sun, 11 Apr 2010 18:58:25 +0000 Subject: legacy /8 In-Reply-To: <1E42BBC9-E7EA-4A1B-B62C-335F2D367FCB@virtualized.org> (David Conrad's message of "Sun\, 11 Apr 2010 08\:34\:45 -1000") References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> <4BC1FB93.3060706@emmanuelcomputerconsulting.com> <4A03EAD0-8BDC-408E-A513-41CC6B9F4F7E@delong.com> <1E42BBC9-E7EA-4A1B-B62C-335F2D367FCB@virtualized.org> Message-ID: David Conrad writes: >> Growth in IPv4 accessible hosts will stop or become significantly more >> expensive or both in about 2.5 years (+/- 6 months). > > Growth stopping is extremely unlikely. Growth becoming significantly more > expensive is guaranteed. ... more expensive for whom, though? if someone has to find existing address space and transfer it at some payment to the current holder in order to grow their own network, that's a direct expense. if this became common and resulted in significant deaggregation, then everybody else attached in some way to the "global routing table" would also have to pay some costs, which would be indirect expenses. unless a market in routing slots appears, there's no way for the direct beneficiaries of deaggregation to underwrite the indirect costs of same. at a systemic level, i'd characterize the cost of that kind of growth as instability rather merely expense. > Address utilization efficiency will increase as people see the value in > public IPv4 addresses. ISPs interested in continuing to grow will do > what it takes to obtain IPv4 addresses and folks with allocated- but- > unused addresses will be happy to oblige (particularly when they accept > that they only need a couple of public IP addresses for their entire > network). At some point, it may be that the cost of obtaining IPv4 will > outstrip the cost of migrating to IPv6. If we're lucky. the cost:benefit of using ipv6 depends on what other people have deployed. that is, when most of the people that an operator and their customers want to talk to are already running ipv6, then the cost:benefit will be compelling compared to any form of continued use of ipv4. arguments about the nature and location of that tipping point amount to reading tea leaves. nevertheless if everybody who can deploy dual-stack does so, we'll reach that tipping point sooner and it'll be less spectacular. -- Paul Vixie Chairman, ARIN BoT From owen at delong.com Sun Apr 11 14:03:05 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 11 Apr 2010 12:03:05 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004111617.o3BGHHn3024246@aurora.sol.net> <0D478936-091E-4807-B1B3-025C86154387@delong.com> Message-ID: On Apr 11, 2010, at 11:21 AM, David Conrad wrote: > Owen, > > On Apr 11, 2010, at 6:39 AM, Owen DeLong wrote: >> Instead, we have a situation where the mere mention >> of requiring legacy holders to pay a token annual fee like the rest >> of IP end-users in the ARIN region leads to discussions like this. > > I don't believe the issue is the token annual fee. My guess is that most legacy holders would be willing to pay a "reasonable" service fee to cover rDNS and registration database maintenance (they'd probably be more willing if there were multiple providers of that service, but that's a separate topic). I suspect the issue might be more related to stuff like: > >> Especially in light of >> the fact that if you are sitting on excess resources and want >> to be able to transfer them under NRPM 8.3, you will need >> to bring them under LRSA or RSA first and the successor who >> acquires them from you (under 8.2 or 8.3) will need to sign an >> RSA for the transfer to be valid. > > You appear to be assuming folks are willing to accept ARIN has the right and ability to assert the above (and more). That is, that the entire policy regime under which the NRPM has been defined is one that legacy holders are implicitly bound simply because they happen to operate in ARIN's service region and received IP addresses in the past without any real terms and conditions or formal agreement. I imagine the validity of your assumption will not be established without a definitive legal ruling. I'm sure it will be an interesting court case. > Well, if they want to operate under the previous regime, then, they should simply return any excess resources now rather than attempting to monetize them under newer policies as that was the policy in place at the time. Certainly they should operate under one of those two regimes rather than some alternate reality not related to either. Interestingly, APNIC seems to have had little trouble asserting such in their region, but, I realize the regulatory framework in the ARIN region is somewhat different. > In any event, it seems clear that some feel that entering into agreements and paying fees in order to obtain IPv6 address space is hindering deployment of IPv6. While ARIN has in the past waived fees for IPv6, I don't believe there has ever been (nor is there likely to be) a waiver of signing the RSA. Folks who want that should probably get over it. > I believe you are correct about that. > To try to bring this back to topics relevant to NANOG (and not ARIN's PPML), the real issue is that pragmatically speaking, the only obvious alternative to IPv6 is multi-layer NAT and it seems some people are trying to tell you that regardless of how much you might hate multi-layer NAT, how much more expensive you believe it will be operationally, and how much more limiting and fragile it will be because it breaks the end-to-end paradigm, they believe it to be a workable solution. Are there _any_ case studies, analyses with actual data, etc. that shows multi-layer NAT is not workable (scalable, operationally tractable, etc.) or at least is more expensive than IPv6? > Can you point to a single working deployment of multi-layer NAT? I can recall experiences with several attempts which had varying levels of dysfunction. Some actually done at NANOG meetings, for example. As such, I'm willing to say that there is at least anecdotal evidence that multi-layer NAT either is not workable or has not yet been made workable. Owen From owen at delong.com Sun Apr 11 14:06:16 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 11 Apr 2010 12:06:16 -0700 Subject: legacy /8 In-Reply-To: <1E42BBC9-E7EA-4A1B-B62C-335F2D367FCB@virtualized.org> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> <4BC1FB93.3060706@emmanuelcomputerconsulting.com> <4A03EAD0-8BDC-408E-A513-41CC6B9F4F7E@delong.com> <1E42BBC9-E7EA-4A1B-B62C-335F2D367FCB@virtualized.org> Message-ID: On Apr 11, 2010, at 11:34 AM, David Conrad wrote: > On Apr 11, 2010, at 8:09 AM, Owen DeLong wrote: >>> Part fo the reason folks aren't rushing to the V6 bandwagon is it's not needed. Stop doing the chicken little dance folks. V6 is nice and gives us tons of more addresses but I can tell you V4 is more than two years form "dying" just by seeing all the arm flailing going around. >> IPv4 will not die in 2 years. > > I'd wager it won't be dead in 20 years. Of course, a lot depends on what is meant by "dying". > Yep. Assuming IPv6 catches on in the post-runout crisis (and I think it will), I suspect that IPv4 will be largely deprecated on the wide-spread internet within about 5-10 years of IPv6 practical ubiquity. I suspect it will ALWAYS be used in some niches somewhere. >> Growth in IPv4 accessible hosts will stop or become significantly more expensive or both in about 2.5 years (+/- 6 months). > > Growth stopping is extremely unlikely. Growth becoming significantly more expensive is guaranteed. Address utilization efficiency will increase as people see the value in public IPv4 addresses. ISPs interested in continuing to grow will do what it takes to obtain IPv4 addresses and folks with allocated-but-unused addresses will be happy to oblige (particularly when they accept that they only need a couple of public IP addresses for their entire network). At some point, it may be that the cost of obtaining IPv4 will outstrip the cost of migrating to IPv6. If we're lucky. > Eventually, utilization efficiency will get close to 100% and growth will, therefore stop. Note, I was specific about IPv4 accessible hosts, as in hosts which you can send a TCP SYN packet to, not merely hosts which can originate connections. Multi-layer NAT may help increase the number of IPv4-non-accessible hosts, but, it can do little to help increase accessible host count. Owen From drc at virtualized.org Sun Apr 11 14:20:48 2010 From: drc at virtualized.org (David Conrad) Date: Sun, 11 Apr 2010 09:20:48 -1000 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004111617.o3BGHHn3024246@aurora.sol.net> <0D478936-091E-4807-B1B3-025C86154387@delong.com> Message-ID: On Apr 11, 2010, at 9:03 AM, Owen DeLong wrote: > Well, if they want to operate under the previous regime, then, they should simply return any excess resources now rather than attempting to monetize them under newer policies as that was the policy in place at the time. Why? There were no policies to restrict how address space was transferred (or anything else) when they got their space. > Certainly they should operate under one of those two regimes rather than some alternate reality not related to either. When most of the legacy space was handed out, there were no restrictions on what you could do/not do with address space simply because no one considered it necessary. Much later, a policy regime was established that explicitly limits rights and you seem surprised when the legacy holders aren't all that interested. > Interestingly, APNIC seems to have had little trouble asserting such in their region, Hah. I suspect you misunderstand. > Can you point to a single working deployment of multi-layer NAT? I suppose it depends on your definition of "working". I've been told there are entire countries that operate behind multi-later NAT (primarily because the regulatory regime required ISPs obtain addresses from the PTT and the PTT would only hand out a couple of IP addresses). I have put wireless gateways on NAT'd hotel networks and it works for client services, for some value of the variable "works". > I can recall experiences with several attempts which had varying levels of dysfunction. Some actually done at NANOG meetings, for example. As such, I'm willing to say that there is at least anecdotal evidence that multi-layer NAT either is not workable or has not yet been made workable. The problem is, anecdotal evidence isn't particularly convincing to folks who are trying to decide whether to fire folks so they'll have money to spend on upgrading their systems to support IPv6. Regards, -drc From scott at doc.net.au Sun Apr 11 14:58:44 2010 From: scott at doc.net.au (Scott Howard) Date: Sun, 11 Apr 2010 12:58:44 -0700 Subject: Solar Flux (was: Re: China prefix hijack) In-Reply-To: <867hoet758.fsf_-_@seastrom.com> References: <20100408171935.GD30450@staff.dca.net> <001f01cad740$ccf0c390$4401a8c0@jgbpc> <20100408174405.GD4808@dan.olp.net> <867hoet758.fsf_-_@seastrom.com> Message-ID: On Sun, Apr 11, 2010 at 7:07 AM, Robert E. Seastrom wrote: > We've seen great increases in CPU and memory speeds as well as disk > densities since the last maximum (March 2000). Speccing ECC memory is > a reasonable start, but this sort of thing has been a problem in the > past (anyone remember the Sun UltraSPARC CPUs that had problems last > time around?) and will no doubt bite us again. > Sun's problem had an easy solution - and it's exactly the one you've mentioned - ECC. The issue with the UltraSPARC II's was that they had enough redundancy to detect a problem (Parity), but not enough to correct the problem (ECC). They also (initially) had a very abrupt handling of such errors - they would basically panic and restart. >From the UltraSPARC III's they fixed this problem by sticking with Parity in the L1 cache (write-through, so if you get a parity error you can just dump the cache and re-read from memory or a higher cache), but using ECC on the L2 and higher (write-back) caches. The memory and all datapaths were already protected with ECC in everything but the low-end systems. It does raise a very interesting question though - how many systems are you running that don't use ECC _everywhere_? (CPU, memory and datapath) Unlike many years ago, today Parity memory is basically non-existent, which means if you're not using ECC then you're probably suffering relatively regular single-bit errors without knowing it. In network devices that's less of an issue as you can normally rely on higher-level protocols to detect/correct the errors, but if you're not using ECC in your servers then you're asking for (silent) trouble... Scott. From wbailey at gci.com Sun Apr 11 15:13:15 2010 From: wbailey at gci.com (Warren Bailey) Date: Sun, 11 Apr 2010 12:13:15 -0800 Subject: Solar Flux (was: Re: China prefix hijack) Message-ID: <09F712D9B8F7AF40BE523224B2487BA10D93DBDB@dtn1mbx01.gci.com> Are we thinking its going to get worse?? Did anyone else see the intelsat spacecraft failure last week?? Sent using my GCI BlackBerry ----- Original Message ----- From: Valdis.Kletnieks at vt.edu To: Michael Dillon Cc: Paul Vixie ; Robert E. Seastrom ; nanog at merit.edu Sent: Sun Apr 11 08:36:05 2010 Subject: Re: Solar Flux (was: Re: China prefix hijack) On Sun, 11 Apr 2010 16:58:40 BST, Michael Dillon said: > Would a Faraday cage be sufficient to protect against cosmic ray bit-flipping > and how could you retrofit a Faraday cage onto a rack or two of gear? Scientists build neutrino detectors in mines 8,000 feet underground because that much rock provides *partial* shielding against cosmic rays causing spurious detection events. Fortunately, the sun emits almost no cosmic rays. It does however spew a lot of less energetic particles that will cause single-bit upsets in electronic gear. Time to double-check that all your gear has ECC ram - the problem with the UltraSparc CPUs last time was that they had some cache chips built by IBM. IBM said "Use these chips in an ECC config", but Sun didn't. The ions hit, and the resulting bit-flips crashed the machines. Incidentally, Sun sued IBM over that, and the judge basically said "Well, IBM *told* you not to do that up front. Suit dismissed". One of the other big issues will be noise on satellite and microwave links screwing your S/N ratio. The one that scares me? Inducted currents on long runs of copper. You get a 200-300 mile 765Kva transmission line, and a solar flare hits, the Earth's magnetic field gets dented, so the field lines move relative to the stationary copper cable, and suddenly you have several thousand extra amps popping out one end of that cable. Ka-blam. The big danger there is that many substations are not designed for that - so it would basically *permanently* destroy that substation and they'd get to replace it. And of course, that's a several-weeks repair even if it's the only one - and in that sort of case, there will be *dozens* of step-down transformers blown up the same afternoon. How long can you run on diesel? ;) From drc at virtualized.org Sun Apr 11 15:30:05 2010 From: drc at virtualized.org (David Conrad) Date: Sun, 11 Apr 2010 10:30:05 -1000 Subject: legacy /8 In-Reply-To: References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> <4BC1FB93.3060706@emmanuelcomputerconsulting.com> <4A03EAD0-8BDC-408E-A513-41CC6B9F4F7E@delong.com> <1E42BBC9-E7EA-4A1B-B62C-335F2D367FCB@virtualized.org> Message-ID: Paul, On Apr 11, 2010, at 8:58 AM, Paul Vixie wrote: > David Conrad writes: >> Growth becoming significantly more expensive is guaranteed. ... > more expensive for whom, though? ISPs requiring space will have to pay more and I fully anticipate that cost will propagate down to end users. In (some version of) an ideal world, IPv6 would be at no cost to end users, thereby incentivizing them to encourage their favorite porn sites (et al) to offer their wares via IPv6. > unless a market in routing slots appears, there's no way for the direct > beneficiaries of deaggregation to underwrite the indirect costs of same. And that's different from how it's always been in what way? My tea leaf reading is that history will repeat itself. As it was in the mid-90's, as soon as routers fall over ISPs will deploy prefix length (or other) filters to protect their own infrastructure as everybody scrambles to come up with some hack that won't be a solution, but will allow folks to limp along. Over time, router vendors will improve their kit, ISPs will rotate out routers that can't deal with the size/flux of the bigger routing table (passing the cost on to their customers, of course), and commercial pressures will force the removal of filters. Until the next go around since IPv6 doesn't solve the routing scalability problem. The nice thing about history repeating itself is that you know when to go out and get the popcorn. Regards, -drc From leigh.porter at ukbroadband.com Sun Apr 11 15:39:39 2010 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Sun, 11 Apr 2010 21:39:39 +0100 Subject: Solar Flux (was: Re: China prefix hijack) Message-ID: <1c0001cad9b7$27f61362$0324a8c0@ukbroadband.com> There is a guy who walks aroung Hyde Park Corner in London with a sandwich board that says "its going to get worse". Perhaps Ill go and talk to him next weekend and see what he thinks. -- Leigh --- original message --- From: "Warren Bailey" Subject: Re: Solar Flux (was: Re: China prefix hijack) Date: 11th April 2010 Time: 9:14:50 pm Are we thinking its going to get worse?? Did anyone else see the intelsat spacecraft failure last week?? Sent using my GCI BlackBerry ----- Original Message ----- From: Valdis.Kletnieks at vt.edu To: Michael Dillon Cc: Paul Vixie ; Robert E. Seastrom ; nanog at merit.edu Sent: Sun Apr 11 08:36:05 2010 Subject: Re: Solar Flux (was: Re: China prefix hijack) On Sun, 11 Apr 2010 16:58:40 BST, Michael Dillon said: > Would a Faraday cage be sufficient to protect against cosmic ray bit-flipping > and how could you retrofit a Faraday cage onto a rack or two of gear? Scientists build neutrino detectors in mines 8,000 feet underground because that much rock provides *partial* shielding against cosmic rays causing spurious detection events. Fortunately, the sun emits almost no cosmic rays. It does however spew a lot of less energetic particles that will cause single-bit upsets in electronic gear. Time to double-check that all your gear has ECC ram - the problem with the UltraSparc CPUs last time was that they had some cache chips built by IBM. IBM said "Use these chips in an ECC config", but Sun didn't. The ions hit, and the resulting bit-flips crashed the machines. Incidentally, Sun sued IBM over that, and the judge basically said "Well, IBM *told* you not to do that up front. Suit dismissed". One of the other big issues will be noise on satellite and microwave links screwing your S/N ratio. The one that scares me? Inducted currents on long runs of copper. You get a 200-300 mile 765Kva transmission line, and a solar flare hits, the Earth's magnetic field gets dented, so the field lines move relative to the stationary copper cable, and suddenly you have several thousand extra amps popping out one end of that cable. Ka-blam. The big danger there is that many substations are not designed for that - so it would basically *permanently* destroy that substation and they'd get to replace it. And of course, that's a several-weeks repair even if it's the only one - and in that sort of case, there will be *dozens* of step-down transformers blown up the same afternoon. How long can you run on diesel? ;) From wbailey at gci.com Sun Apr 11 15:50:55 2010 From: wbailey at gci.com (Warren Bailey) Date: Sun, 11 Apr 2010 12:50:55 -0800 Subject: Solar Flux (was: Re: China prefix hijack) Message-ID: <09F712D9B8F7AF40BE523224B2487BA10D93DBDC@dtn1mbx01.gci.com> Bring cider, he'll be more talkative. Here in Alaska, the natives believed the Aurora was brought by birds - so anything is possible. Though, I will admit - I've read similar craziness on this mailing list. Not craziness, bat shit crazy is probably more appropriate. Sent using my GCI BlackBerry ----- Original Message ----- From: Leigh Porter To: Warren Bailey; Valdis.Kletnieks at vt.edu ; wavetossed at googlemail.com Cc: vixie at isc.org ; rs at seastrom.com ; nanog at merit.edu Sent: Sun Apr 11 12:39:39 2010 Subject: Re: Solar Flux (was: Re: China prefix hijack) There is a guy who walks aroung Hyde Park Corner in London with a sandwich board that says "its going to get worse". Perhaps Ill go and talk to him next weekend and see what he thinks. -- Leigh --- original message --- From: "Warren Bailey" Subject: Re: Solar Flux (was: Re: China prefix hijack) Date: 11th April 2010 Time: 9:14:50 pm Are we thinking its going to get worse?? Did anyone else see the intelsat spacecraft failure last week?? Sent using my GCI BlackBerry ----- Original Message ----- From: Valdis.Kletnieks at vt.edu To: Michael Dillon Cc: Paul Vixie ; Robert E. Seastrom ; nanog at merit.edu Sent: Sun Apr 11 08:36:05 2010 Subject: Re: Solar Flux (was: Re: China prefix hijack) On Sun, 11 Apr 2010 16:58:40 BST, Michael Dillon said: > Would a Faraday cage be sufficient to protect against cosmic ray bit-flipping > and how could you retrofit a Faraday cage onto a rack or two of gear? Scientists build neutrino detectors in mines 8,000 feet underground because that much rock provides *partial* shielding against cosmic rays causing spurious detection events. Fortunately, the sun emits almost no cosmic rays. It does however spew a lot of less energetic particles that will cause single-bit upsets in electronic gear. Time to double-check that all your gear has ECC ram - the problem with the UltraSparc CPUs last time was that they had some cache chips built by IBM. IBM said "Use these chips in an ECC config", but Sun didn't. The ions hit, and the resulting bit-flips crashed the machines. Incidentally, Sun sued IBM over that, and the judge basically said "Well, IBM *told* you not to do that up front. Suit dismissed". One of the other big issues will be noise on satellite and microwave links screwing your S/N ratio. The one that scares me? Inducted currents on long runs of copper. You get a 200-300 mile 765Kva transmission line, and a solar flare hits, the Earth's magnetic field gets dented, so the field lines move relative to the stationary copper cable, and suddenly you have several thousand extra amps popping out one end of that cable. Ka-blam. The big danger there is that many substations are not designed for that - so it would basically *permanently* destroy that substation and they'd get to replace it. And of course, that's a several-weeks repair even if it's the only one - and in that sort of case, there will be *dozens* of step-down transformers blown up the same afternoon. How long can you run on diesel? ;) From vixie at isc.org Sun Apr 11 15:57:53 2010 From: vixie at isc.org (Paul Vixie) Date: Sun, 11 Apr 2010 20:57:53 +0000 Subject: legacy /8 In-Reply-To: Your message of "Sun, 11 Apr 2010 10:30:05 -1000." References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> <4BC1FB93.3060706@emmanuelcomputerconsulting.com> <4A03EAD0-8BDC-408E-A513-41CC6B9F4F7E@delong.com> <1E42BBC9-E7EA-4A1B-B62C-335F2D367FCB@virtualized.org> Message-ID: <48563.1271019473@nsa.vix.com> > From: David Conrad > Date: Sun, 11 Apr 2010 10:30:05 -1000 > > > unless a market in routing slots appears, there's no way for the direct > > beneficiaries of deaggregation to underwrite the indirect costs of same. > > And that's different from how it's always been in what way? when 64MB was all anybody had, deaggregation was rendered ineffective by route filtering. what i've seen more recently is gradual monotonic increase in the size of the "full table". if the systemic cost of using all of ipv4 includes a 10X per year step function in routing table size then it will manifest as instability (in both the network and the market). as you have pointed out many times, ipv6 offers the same number of /32's as ipv4. however, a /32 worth of ipv6 is enough for a lifetime even for most multinationals, whereas for ipv4 it's one NAT or ALG box. so, i'm thinking that making ipv4 growth happen beyond pool exhaustion would be a piecemeal affair and that the routing system wouldn't accomodate it painlessly. the rate of expansion of "other people's routers" seems to fit the growth curve we've seen, but will it fit massive deaggregation? > My tea leaf reading is that history will repeat itself. As it was in the > mid-90's, as soon as routers fall over ISPs will deploy prefix length (or > other) filters to protect their own infrastructure as everybody scrambles > to come up with some hack that won't be a solution, but will allow folks > to limp along. Over time, router vendors will improve their kit, ISPs > will rotate out routers that can't deal with the size/flux of the bigger > routing table (passing the cost on to their customers, of course), and > commercial pressures will force the removal of filters. Until the next > go around since IPv6 doesn't solve the routing scalability problem. instability like we had in the mid-1990's would be far more costly today, given that the internet is now used by the general population and serves a global economy. if the rate of endpoint growth does not continue beyond ipv4 pool exhaustion we'll have a problem. if it does, we'll also have a problem but a different problem. i'd like to pick the easiest problem and for that reason i'm urging dual-stack ipv4/ipv6 for all networks new or old. -- Paul Vixie Chairman, ARIN BoT From jbfixurpc at gmail.com Sun Apr 11 16:06:51 2010 From: jbfixurpc at gmail.com (Joe) Date: Sun, 11 Apr 2010 17:06:51 -0400 Subject: Solar Flux (was: Re: China prefix hijack) In-Reply-To: Message-ID: <000b01cad9ba$e95581c0$4401a8c0@jgbpc> The topic of sunspots is certainly familiar from long ago. We had a 7513 that crashed unexpectedly, upon a review of the data available, it was determined that a parity error had occurred. I can't remember the exact error as it was several years ago, but upon a quick search this article seems familiar. http://www.ciscopress.info/en/US/products/hw/switches/ps700/products_tech_no te09186a00801b42bf.shtml Search on cosmic radiation and/or SEU within. -Joe From vixie at isc.org Sun Apr 11 17:02:33 2010 From: vixie at isc.org (Paul Vixie) Date: Sun, 11 Apr 2010 22:02:33 +0000 Subject: Solar Flux In-Reply-To: <09F712D9B8F7AF40BE523224B2487BA10D93DBDB@dtn1mbx01.gci.com> (Warren Bailey's message of "Sun\, 11 Apr 2010 12\:13\:15 -0800") References: <09F712D9B8F7AF40BE523224B2487BA10D93DBDB@dtn1mbx01.gci.com> Message-ID: Warren Bailey writes: > Are we thinking its going to get worse?? i am. looking at some local passive dns data (generated from ISC SIE), we find the following single bit errors by anchoring some searches at the known names and addresses of the f-root server. DNS does not have its own crc or checksum, it relies on UDP and IP for error detection (in which it is weak or nonexistant). i think it's probably time to formalize the study of bit errors in DNS, and then see if we can make a sensible mapping between what we observe and what the solar flux is. because if they're related and we're going to have a strong solar cycle then everybody's insurance rates are about to go up. re: ;; matches for IP = 192.5.5.241 (resource records) m.root-servers.net. IN A 192.5.5.241 a.root-servers.net. IN A 192.5.5.241 b.root-servers.net. IN A 192.5.5.241 c.root-servers.net. IN A 192.5.5.241 d.root-servers.net. IN A 192.5.5.241 e.root-servers.net. IN A 192.5.5.241 f.boot-servers.net. IN A 192.5.5.241 f.ro\127t-servers.net. IN A 192.5.5.241 f.rood-servers.net. IN A 192.5.5.241 f.roop-servers.net. IN A 192.5.5.241 f.root-cervers.net. IN A 192.5.5.241 f.root-sarvers.net. IN A 192.5.5.241 f.root-sebvers.net. IN A 192.5.5.241 f.root-servebs.net. IN A 192.5.5.241 f.root-serverc.net. IN A 192.5.5.241 f.root-servers.nut. IN A 192.5.5.241 f.root-servers.ned. IN A 192.5.5.241 f.root-servers.neu. IN A 192.5.5.241 f.root-servers.~et. IN A 192.5.5.241 f.root-servers. IN A 192.5.5.241 f.root-servess.net. IN A 192.5.5.241 f.root-servurs.net. IN A 192.5.5.241 f.root-serwers.net. IN A 192.5.5.241 f.root-serfers.net. IN A 192.5.5.241 f.root-survers.net. IN A 192.5.5.241 f.root=servers.net. IN A 192.5.5.241 f.rcot-servers.net. IN A 192.5.5.241 f.rgot-servers.net. IN A 192.5.5.241 f.rkot-servers.net. IN A 192.5.5.241 f.r\127ot-servers.net. IN A 192.5.5.241 g.root-servers.net. IN A 192.5.5.241 h.root-servers.net. IN A 192.5.5.241 i.root-servers.net. IN A 192.5.5.241 j.root-servers.net. IN A 192.5.5.241 k.root-servers.net. IN A 192.5.5.241 l.root-servers.net. IN A 192.5.5.241 v.root-servers.net. IN A 192.5.5.241 ;; matches for IP = 2001:500:2f::f (resource records) f.roop-servers.net. IN AAAA 2001:500:2f::f f.root-cervers.net. IN AAAA 2001:500:2f::f f.root-sarvers.net. IN AAAA 2001:500:2f::f f.root-servebs.net. IN AAAA 2001:500:2f::f f.root-servers.ned. IN AAAA 2001:500:2f::f f.root-servers.neu. IN AAAA 2001:500:2f::f f.root-servers.~et. IN AAAA 2001:500:2f::f f.root-serwers.net. IN AAAA 2001:500:2f::f f.root-serfers.net. IN AAAA 2001:500:2f::f f.root=servers.net. IN AAAA 2001:500:2f::f f.rcot-servers.net. IN AAAA 2001:500:2f::f f.rgot-servers.net. IN AAAA 2001:500:2f::f f.rkot-servers.net. IN AAAA 2001:500:2f::f ;; matches for name = f.root-servers.net (RRsets) f.root-servers.net. IN A 128.63.2.53 f.root-servers.net. IN A 128.63.2.53 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 128.63.2.53 f.root-servers.net. IN A 192.112.36.4 f.root-servers.net. IN A 128.8.10.90 f.root-servers.net. IN A 128.8.10.90 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 128.8.10.90 f.root-servers.net. IN A 202.12.27.33 f.root-servers.net. IN A 192.58.128.30 f.root-servers.net. IN A 192.58.128.30 f.root-servers.net. IN A 198.41.0.4 f.root-servers.net. IN A 192.5.5.225 f.root-servers.net. IN A 192.5.5.253 f.root-servers.net. IN A 192.5.5.255 f.root-servers.net. IN A 192.5.5.240 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 192.58.128.30 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 192.58.128.30 f.root-servers.net. IN A 192.228.79.201 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 192.58.128.30 f.root-servers.net. IN A 198.41.0.4 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 192.33.4.12 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 192.33.4.12 f.root-servers.net. IN A 192.58.128.30 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 192.33.4.12 f.root-servers.net. IN A 193.0.14.129 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 192.33.4.12 f.root-servers.net. IN A 198.32.64.12 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 192.33.4.12 f.root-servers.net. IN A 202.12.27.33 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 192.36.148.17 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 192.112.36.4 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 192.203.230.10 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 192.228.79.201 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 192.228.79.201 f.root-servers.net. IN A 193.0.14.129 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 192.228.79.201 f.root-servers.net. IN A 198.32.64.12 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 192.228.79.201 f.root-servers.net. IN A 202.12.27.33 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 193.0.14.129 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 193.0.14.129 f.root-servers.net. IN A 198.41.0.4 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 198.32.64.12 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 198.32.64.12 f.root-servers.net. IN A 198.41.0.4 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 198.41.0.4 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 198.41.0.4 f.root-servers.net. IN A 202.12.27.33 f.root-servers.net. IN A 192.5.5.241 f.root-servers.net. IN A 202.12.27.33 f.root-servers.net. IN A 192.5.5.248 f.root-servers.net. IN A 192.5.5.249 f.root-servers.net. IN A 192.5.5.250 f.root-servers.net. IN A 192.5.5.251 f.root-servers.net. IN A 192.5.5.252 f.root-servers.net. IN A 192.5.21.241 f.root-servers.net. IN A 192.21.5.241 f.root-servers.net. IN A 192.33.4.12 f.root-servers.net. IN A 192.33.4.12 f.root-servers.net. IN A 192.36.148.17 f.root-servers.net. IN A 192.36.148.17 f.root-servers.net. IN A 192.228.79.201 f.root-servers.net. IN A 192.112.36.4 f.root-servers.net. IN A 192.112.36.4 f.root-servers.net. IN A 192.203.230.10 f.root-servers.net. IN A 192.203.230.10 f.root-servers.net. IN A 192.203.230.10 f.root-servers.net. IN A 198.32.64.12 f.root-servers.net. IN A 192.228.79.201 f.root-servers.net. IN A 192.228.79.201 f.root-servers.net. IN A 193.0.14.129 f.root-servers.net. IN A 192.228.79.201 f.root-servers.net. IN A 198.32.64.12 f.root-servers.net. IN A 192.228.79.201 f.root-servers.net. IN A 202.12.27.33 f.root-servers.net. IN A 193.0.14.129 f.root-servers.net. IN A 193.0.14.129 f.root-servers.net. IN A 198.41.0.4 f.root-servers.net. IN A 198.32.64.12 f.root-servers.net. IN A 198.32.64.12 f.root-servers.net. IN A 198.41.0.4 f.root-servers.net. IN A 198.41.0.4 f.root-servers.net. IN A 198.41.0.4 f.root-servers.net. IN A 202.12.27.33 f.root-servers.net. IN A 202.12.27.33 f.root-servers.net. IN 4097 \# 4 c0 05 05 f1 f.root-servers.net. IN AAAA 2001:500:2f::3a:801e f.root-servers.net. IN AAAA 2001:500:2f:: f.root-servers.net. IN AAAA 2001:500:2f::1:0 f.root-servers.net. IN AAAA 2001:500:2f::14:0 f.root-servers.net. IN AAAA 2001:510:2f::f f.root-servers.net. IN AAAA 2101:500:2f::f f.root-servers.net. IN AAAA 2109:500:2f::f f.root-servers.net. IN LOC \# 16 20 01 05 00 00 2f 00 00 00 00 00 00 00 00 00 0f -- Paul Vixie KI6YSY From gawul00+nanog at gmail.com Sun Apr 11 17:46:01 2010 From: gawul00+nanog at gmail.com (Andy Koch) Date: Sun, 11 Apr 2010 17:46:01 -0500 Subject: Solar Flux (was: Re: China prefix hijack) In-Reply-To: <000b01cad9ba$e95581c0$4401a8c0@jgbpc> References: <000b01cad9ba$e95581c0$4401a8c0@jgbpc> Message-ID: On Sun, Apr 11, 2010 at 16:06, Joe wrote: > > > ? ? ? ?The topic of sunspots is certainly familiar from long ago. We had a > 7513 > that crashed unexpectedly, upon a review of the data available, it was > determined > that a parity error had occurred. I can't remember the exact error as it was > several > years ago, but upon a quick search this article seems familiar. > > http://www.ciscopress.info/en/US/products/hw/switches/ps700/products_tech_no > te09186a00801b42bf.shtml > > Search on cosmic radiation and/or SEU within. > > -Joe I had one RP on a 12K dump about 2 years ago, and the Cisco TAC returned that information almost verbatim regarding a soft parity error. It was a bit of a challenge trying to reword the scenario for those up the chain why on of our core routers decided to have a fit in the middle of the day and all you got from Cisco was "cosmic radiation caused it." I was almost tempted to put in a request for foil hats just to see what type of hilarity would ensue - would have been better if it happened at the beginning of April. Andy From jcurran at arin.net Sun Apr 11 18:08:30 2010 From: jcurran at arin.net (John Curran) Date: Sun, 11 Apr 2010 19:08:30 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: References: <201004111617.o3BGHHn3024246@aurora.sol.net> <0D478936-091E-4807-B1B3-025C86154387@delong.com> Message-ID: <642E8F43-C0BA-4604-B50A-2F79E4A8B55D@arin.net> On Apr 11, 2010, at 3:20 PM, David Conrad wrote: > > When most of the legacy space was handed out, there were no restrictions on what you could do/not do with address space simply because no one considered it necessary. David - I don't think I can agree with that statement, but for sake of clarity - when do you think this "no restriction" period actually occurred? /John John Curran President and CEO ARIN From drc at virtualized.org Sun Apr 11 18:52:24 2010 From: drc at virtualized.org (David Conrad) Date: Sun, 11 Apr 2010 13:52:24 -1000 Subject: legacy /8 In-Reply-To: <48563.1271019473@nsa.vix.com> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> <4BC1FB93.3060706@emmanuelcomputerconsulting.com> <4A03EAD0-8BDC-408E-A513-41CC6B9F4F7E@delong.com> <1E42BBC9-E7EA-4A1B-B62C-335F2D367FCB@virtualized.org> <48563.1271019473@nsa.vix.com> Message-ID: <54701FCF-13EA-44DA-8677-26A7C6635EF1@virtualized.org> On Apr 11, 2010, at 10:57 AM, Paul Vixie wrote: > i'd like to pick the easiest problem and > for that reason i'm urging dual-stack ipv4/ipv6 for all networks new or old. Is anyone arguing against this? The problem is what happens when there isn't sufficient IPv4 to do dual stack. Regards, -drc From oberman at es.net Sun Apr 11 19:02:41 2010 From: oberman at es.net (Kevin Oberman) Date: Sun, 11 Apr 2010 17:02:41 -0700 Subject: interop show network (was: legacy /8) In-Reply-To: Your message of "Wed, 07 Apr 2010 12:28:39 EDT." <8863.1270657719@localhost> Message-ID: <20100412000241.75FB71CC09@ptavv.es.net> > From: Valdis.Kletnieks at vt.edu > Date: Wed, 07 Apr 2010 12:28:39 -0400 > > On Wed, 07 Apr 2010 16:09:25 +0200, Eliot Lear said: > > > them). If v6 is even close to ready, wouldn't it be sad that this sort > > of testing isn't done at interop? > > Interop long ago ceased being a interop shootout and became a 8x11 color glossy > trade show. I think the last time any actual *testing* happened at Interop, the > guys hooking up the network drops were wearing t-shirts that said "Yes, the > subnet mask really *is* 255.255.252.0", and anybody who whined that their gear > only supported octet-boundary subnets was told "And next year, it will be > 255.255.250.0". > > :) > > Anybody got production gear that *still* doesn't do non-octet-boundary subnets? Sort of. We discovered that Infinera DWDM gear's boot ROM OS is entirely classful. Not only most the subnet mask be on octet boundaries, but the boundary must match the address space used. (Well, you really can't specify a subnet mask. It just sets it based on the address.) That said, this is only the boot ROM system. Once you figure out how to make that work in your configuration, you load the real, running software which does CIDR and any subnet mask. So the impact is minimal, but it did shock me when I ran into it. -- 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 drc at virtualized.org Sun Apr 11 19:15:54 2010 From: drc at virtualized.org (David Conrad) Date: Sun, 11 Apr 2010 14:15:54 -1000 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <642E8F43-C0BA-4604-B50A-2F79E4A8B55D@arin.net> References: <201004111617.o3BGHHn3024246@aurora.sol.net> <0D478936-091E-4807-B1B3-025C86154387@delong.com> <642E8F43-C0BA-4604-B50A-2F79E4A8B55D@arin.net> Message-ID: <5D1171D7-98EE-45D0-B97C-8D33F21D912C@virtualized.org> John, On Apr 11, 2010, at 1:08 PM, John Curran wrote: >> When most of the legacy space was handed out, there were no restrictions on what you could do/not do with address space simply because no one considered it necessary. > I don't think I can agree with that statement, Not surprising. > but for sake of clarity - > when do you think this "no restriction" period actually occurred? Hard for me to tell, since my interaction with Jon in terms of obtaining IP addresses was limited to getting 202/7 back in '93 or so. If I remember correctly, Jon simply said addresses from that block should be used for assignments in the AP region in keeping with RFC 1466. He did not impose any sort of restrictions on "transfers" (why bother since all you needed to do was ask for addresses) nor were there any formal agreements. I suppose the limitation of allocation to the AP region could be considered a restriction, but that's probably a bit pedantic. However, pragmatically speaking, both of our views are irrelevant. My impression is that folks who have legacy space believe that it is their asset. As I said in response to Owen, I suspect a legal decision will be needed to definitively resolve this question. Regards, -drc From marka at isc.org Sun Apr 11 19:53:53 2010 From: marka at isc.org (Mark Andrews) Date: Mon, 12 Apr 2010 10:53:53 +1000 Subject: legacy /8 In-Reply-To: Your message of "Sun, 11 Apr 2010 13:52:24 -1000." <54701FCF-13EA-44DA-8677-26A7C6635EF1@virtualized.org> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> <4BC1FB93.3060706@emmanuelcomputerconsulting.com> <4A03EAD0-8BDC-408E-A513-41CC6B9F4F7E@delong.com> <1E42BBC9-E7EA-4A1B-B62C-335F2D367FCB@virtualized.org> <48563.1271019473@nsa.vix.com> <54701FCF-13EA-44DA-8677-26A7C6635EF1@virtualized.org> Message-ID: <201004120053.o3C0rrwZ092927@drugs.dv.isc.org> In message <54701FCF-13EA-44DA-8677-26A7C6635EF1 at virtualized.org>, David Conrad writes: > On Apr 11, 2010, at 10:57 AM, Paul Vixie wrote: > > i'd like to pick the easiest problem and > > for that reason i'm urging dual-stack ipv4/ipv6 for all networks new = > or old. > > Is anyone arguing against this? The problem is what happens when there = > isn't sufficient IPv4 to do dual stack. On the client side you will still be dual stack and also be using PNAT (single, double or distributed) to more efficiently use the available IPv4 addresses. There will be service providers that provide client address pools for those that can't get IPv4 addresses themselves using technologies like ds-lite to transport the traffic. On the server side you will be able to purchase the use of a IPv4 address and the packets will be tunneled back to you socks like. Eventually most of the traffic will switch to being IPv6 and providers of theses services will disappear as they are no longer profitable to run. Mark > Regards, > -drc -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From Bruce.Morgan at aarnet.edu.au Sun Apr 11 21:36:23 2010 From: Bruce.Morgan at aarnet.edu.au (Bruce Morgan) Date: Mon, 12 Apr 2010 10:36:23 +0800 Subject: BGP hijack from 23724 -> 4134 China? In-Reply-To: <964C943783CDCE4BBA0CE327AA8E7BA5069DD0DF@vm-a-ex1.ms.aarnet.edu.au> Message-ID: Hi Bob, AARNet does have a fairly strong policy on prefix-filtering. We also peer with route-views servers so that Cyclops and other projects can actually get this type of information. Best not to shoot the messenger as the message can be useful ;-) Regards Bruce > From: peering-admin at aarnet.edu.au [mailto:peering-admin at aarnet.edu.au] > On Behalf Of Bob Poortinga > Sent: Friday, 9 April 2010 11:13 PM > To: nanog at nanog.org > Cc: peering at aarnet.edu.au; Bruce Morgan > Subject: Re: BGP hijack from 23724 -> 4134 China? > > Jay Hennigan writes: > >> We just got Cyclops alerts showing several of our prefixes sourced > from >> AS23474 propagating through AS4134. Anyone else? > > For the record, yes. Two of our blocks were announced via 7575 4134 > 23724 > yesterday. First seen by Cyclops at 2010-04-08 15:57:13 UTC and lasted > about 20 minutes. > > Does AS7575, Australian Academic and Reasearch Network, do any > filtering? > > -- > Bob Poortinga K9SQL > Technology Service Corp. > Bloomington, Indiana US -- street address: AARNet, POD 3, 20 Dick Perry Ave, Kensington, WA 6151, Australia m. 0408 882 390 t. +61 8 9289 2212 e. bruce.morgan at aarnet.edu.au w. www.aarnet.edu.au important This email and any files transmitted with it are confidential, and the rights of confidentiality in such information are not waived or lost by its mistaken delivery to you. Any dissemination, copying, use or disclosure of the email and/or such files without the permission of AARNet, or the sender, is strictly prohibited. If you have received this email in error, please contact the sender immediately and delete all copies of this transmission. From pete at altadena.net Sun Apr 11 22:40:33 2010 From: pete at altadena.net (Pete Carah) Date: Sun, 11 Apr 2010 23:40:33 -0400 Subject: Solar Flux In-Reply-To: References: <09F712D9B8F7AF40BE523224B2487BA10D93DBDB@dtn1mbx01.gci.com> Message-ID: <4BC29631.6010603@altadena.net> On 04/11/2010 06:02 PM, Paul Vixie wrote: > Warren Bailey writes: > > >> Are we thinking its going to get worse?? >> > i am. looking at some local passive dns data (generated from ISC SIE), > we find the following single bit errors by anchoring some searches at > the known names and addresses of the f-root server. DNS does not have > its own crc or checksum, it relies on UDP and IP for error detection > (in which it is weak or nonexistant). i think it's probably time to > formalize the study of bit errors in DNS, and then see if we can make > a sensible mapping between what we observe and what the solar flux is. > > because if they're related and we're going to have a strong solar cycle > then everybody's insurance rates are about to go up. > And to top it all off, how many picojoules are stored in a modern ram cell compared to the same during the last sunspot peak. There is a hidden cost to memory density growth here... -- Pete From tglassey at earthlink.net Sun Apr 11 22:57:42 2010 From: tglassey at earthlink.net (todd glassey) Date: Sun, 11 Apr 2010 20:57:42 -0700 Subject: 32 bits ASN on Cisco In-Reply-To: <4BC1A4E9.6080306@bromirski.net> References: <9561177.18.1270980924743.JavaMail.franck@franck-martins-macbook-pro.local> <4BC1A4E9.6080306@bromirski.net> Message-ID: <4BC29A36.7060908@earthlink.net> On 4/11/2010 3:31 AM, ?ukasz Bromirski wrote: > On 2010-04-11 12:15, Franck Martin wrote: > >> To come back, to your statement that says it is just supported on 7200, >> means you cannot use a 32bit ASN in production today on any hardware? > > It doesn't mean anything like that. > > As the software is available for some time already, you can > run 32bit ASN in production today, and actually people do that. > Nothing fancy. > > For the list of software versions supporting 32 bit ASN please > referer to this document: > http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/data_sheet_C78-521821.html Except that much of that early Cisco gear has forever warranty's on it making that another mess for Mr. Pinto's organization to clean up. > > But yes, you can't run it on 2500 and 2600 as they're for long time > End of Life/Engineering/Support/Everything. > -------------- next part -------------- A non-text attachment was scrubbed... Name: tglassey.vcf Type: text/x-vcard Size: 125 bytes Desc: not available URL: From gbonser at seven.com Sun Apr 11 23:21:53 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 11 Apr 2010 21:21:53 -0700 Subject: Solar Flux References: <09F712D9B8F7AF40BE523224B2487BA10D93DBDB@dtn1mbx01.gci.com> <4BC29631.6010603@altadena.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6E60@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Pete Carah [mailto:pete at altadena.net] > Sent: Sunday, April 11, 2010 8:41 PM > To: nanog at nanog.org > Subject: Re: Solar Flux > > And to top it all off, how many picojoules are stored in a modern ram > cell > compared to the same during the last sunspot peak. There is a hidden > cost to memory density growth here... > > -- Pete > This cycle is currently predicted to be quite tame by recent standards. So far NASA is predicting cycle 24 to be much weaker than 23 was: http://solarscience.msfc.nasa.gov/images/f107_predict.gif http://solarscience.msfc.nasa.gov/predict.shtml From bill at herrin.us Mon Apr 12 00:24:11 2010 From: bill at herrin.us (William Herrin) Date: Mon, 12 Apr 2010 01:24:11 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <642E8F43-C0BA-4604-B50A-2F79E4A8B55D@arin.net> References: <201004111617.o3BGHHn3024246@aurora.sol.net> <0D478936-091E-4807-B1B3-025C86154387@delong.com> <642E8F43-C0BA-4604-B50A-2F79E4A8B55D@arin.net> Message-ID: On Sun, Apr 11, 2010 at 7:08 PM, John Curran wrote: > On Apr 11, 2010, at 3:20 PM, David Conrad wrote: >> When most of the legacy space was handed out, there >>were no restrictions on what you could do/not do with >>address space simply because no one considered it necessary. > > ?I don't think I can agree with that statement, but for sake of clarity - > ?when do you think this "no restriction" period actually occurred? John, What restrictions do you believe were imposed on someone requesting a class-C between 4/93 and 9/94 who did not intend to connect to MILNET or NSFNET? For your reference, here's the form then active: http://bill.herrin.us/network/templates/199304-internet-number-template.txt Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From pauldotwall at gmail.com Mon Apr 12 01:11:38 2010 From: pauldotwall at gmail.com (Paul WALL) Date: Mon, 12 Apr 2010 02:11:38 -0400 Subject: FCC dealt major blow in net neutrality ruling favoring, Comcast In-Reply-To: <4BC0F119.2030802@bennett.com> References: <4BC0F119.2030802@bennett.com> Message-ID: On Sat, Apr 10, 2010 at 5:43 PM, Richard Bennett wrote: > The FCC is structured in such a way that the chairman calls all the shots on > policy matters. In this instance, the former chairman, Kevin Martin, was > responsible for the Comcast order but the current chairman, Julius > Genachowski, had to defend it in court. Some wags insist that the defense > was a bit lackluster because Genachowski didn't much care for the legal > basis of the Comcast order, which relied on a lot of smoke and mirrors to > regulate aspects of edge network behavior that Congress never told the FCC > to regulate. The defense relied on some legal theories that weren't used in > the order itself, and that's a no-no in an appeal. The court took the rather > extraordinary step of suggesting arguments that the FCC could have used in > the appeal that it didn't use. ... > Research Fellow > Information Technology and Innovation Foundation It should probably be noted, for purpose of establishing bias, that Richard is a Washington lobbyist, hired to represent Comcast on regulatory matters. What he views as overstepping legal bounds, others may view as protecting consumers... Drive Slow, Paul Wall From ops.lists at gmail.com Mon Apr 12 01:23:44 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 12 Apr 2010 11:53:44 +0530 Subject: FCC dealt major blow in net neutrality ruling favoring, Comcast In-Reply-To: References: <4BC0F119.2030802@bennett.com> Message-ID: On Mon, Apr 12, 2010 at 11:41 AM, Paul WALL wrote: > It should probably be noted, for purpose of establishing bias, that > Richard is a Washington lobbyist, hired to represent Comcast on > regulatory matters. ?What he views as overstepping legal bounds, > others may view as protecting consumers... Hell, funnily enough Susan Crawford warned at the time that the FCC action wouldn't stand up in court the way it was done. http://www.circleid.com/posts/comcast_vs_the_fcc_a_reply_to_susan_crawfords_article/ --srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From vixie at isc.org Mon Apr 12 02:23:48 2010 From: vixie at isc.org (Paul Vixie) Date: Mon, 12 Apr 2010 07:23:48 +0000 Subject: legacy /8 In-Reply-To: Your message of "Sun, 11 Apr 2010 13:52:24 -1000." <54701FCF-13EA-44DA-8677-26A7C6635EF1@virtualized.org> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> <4BC1FB93.3060706@emmanuelcomputerconsulting.com> <4A03EAD0-8BDC-408E-A513-41CC6B9F4F7E@delong.com> <1E42BBC9-E7EA-4A1B-B62C-335F2D367FCB@virtualized.org> <48563.1271019473@nsa.vix.com> <54701FCF-13EA-44DA-8677-26A7C6635EF1@virtualized.org> Message-ID: <77068.1271057028@nsa.vix.com> > From: David Conrad > Date: Sun, 11 Apr 2010 13:52:24 -1000 > > On Apr 11, 2010, at 10:57 AM, Paul Vixie wrote: > > ... i'd like to pick the easiest problem and for that reason i'm urging > > dual-stack ipv4/ipv6 for all networks new or old. > > Is anyone arguing against this? yes. plenty of people have accused ipv6 of being a solution in search of a problem. on this very mailing list within the last 72 hours i've seen another person assert that "ipv6 isn't needed." while i tend to agree with tony li who of ipv6 famously said it was "too little and too soon" we have been Overtaken By Events and we now have to deploy it "or else". the only way we're going to do that is with widescale dual-stack, either native dual-stack (which is generally easy since ipv6 address space is cheap and plentiful) or dual-stack-lite (which is ipv4-NAT ipv6-native with aggregated encap/decap at the POP or edge) or with any other method (or trick) that comes to mind or seems attractive. what we can't do is presume that any form of "ipv4 steady state forever" or "wait for something better than ipv6 before abandoning ipv4" is practical, or that these would be less expensive (in both direct cost, indirect cost, and network/market stability) than "dual-stack now, ipv6-mostly soon, and ipv6-only eventually". > The problem is what happens when there isn't sufficient IPv4 to do dual > stack. that problem has many low hanging solutions, some of which mark andrews gave in his response to your note. one popular address allocation policy proposal is reserving the last IPv4 /8 for use in IPv6 deployment, for example as public-facing dual-stack-lite gateways. which brings me to the subject of address allocation policies, and meetings that happen periodically to discuss same. one such address allocator is ARIN (American Registry for Internet Numbers) and one such public policy meeting is next week in toronto. details of this meeting can be found at: https://www.arin.net/participate/meetings/ARIN-XXV/ and anyone, not just from the ARIN service region and not just ARIN members, can attend. there are also remote participation options, see above web page. -- Paul Vixie Chairman, ARIN BoT From randy at psg.com Mon Apr 12 02:26:45 2010 From: randy at psg.com (Randy Bush) Date: Mon, 12 Apr 2010 16:26:45 +0900 Subject: legacy /8 In-Reply-To: <77068.1271057028@nsa.vix.com> References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> <4BC1FB93.3060706@emmanuelcomputerconsulting.com> <4A03EAD0-8BDC-408E-A513-41CC6B9F4F7E@delong.com> <1E42BBC9-E7EA-4A1B-B62C-335F2D367FCB@virtualized.org> <48563.1271019473@nsa.vix.com> <54701FCF-13EA-44DA-8677-26A7C6635EF1@virtualized.org> <77068.1271057028@nsa.vix.com> Message-ID: > plenty of people have accused ipv6 of being a solution in search of a > problem. on this very mailing list within the last 72 hours i've seen > another person assert that "ipv6 isn't needed." while i tend to agree > with tony li who of ipv6 famously said it was "too little and too > soon" we have been Overtaken By Events and we now have to deploy it > "or else". http://www.hactrn.net/sra/vorlons From leigh.porter at ukbroadband.com Mon Apr 12 03:20:29 2010 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 12 Apr 2010 09:20:29 +0100 Subject: Solar Flux In-Reply-To: <000b01cad9ba$e95581c0$4401a8c0@jgbpc> References: <000b01cad9ba$e95581c0$4401a8c0@jgbpc> Message-ID: <4BC2D7CD.30101@ukbroadband.com> Ahh so it was Cosmic Rays that caused all the VIPs to crash and CEF to route traffic up its own ass? Now I understand.. -- Leigh Porter On 11/04/10 22:06, Joe wrote: > > The topic of sunspots is certainly familiar from long ago. We had a > 7513 > that crashed unexpectedly, upon a review of the data available, it was > determined > that a parity error had occurred. I can't remember the exact error as it was > several > years ago, but upon a quick search this article seems familiar. > > http://www.ciscopress.info/en/US/products/hw/switches/ps700/products_tech_no > te09186a00801b42bf.shtml > > Search on cosmic radiation and/or SEU within. > > -Joe > > > From mike at m5computersecurity.com Mon Apr 12 04:16:03 2010 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Mon, 12 Apr 2010 02:16:03 -0700 Subject: Seeking Amazon EC2 abuse contact In-Reply-To: References: Message-ID: <1271063763.6107.3179.camel@mike-desktop> Erik, We have several customers being attacked from the same EC2 instance on their network for 2 full days now. Contacted them at ec2-abuse at amazon.com and 25 hours later received a message that basically said, "Yep, we can confirm that a customer of ours is attacking you but that's their fault. We sometimes do stuff, but not in this case. Please don't block us, because the IP might be someone else later. Have a nice day". The telephone number in the WHOIS record goes to a general voicemail box for their legal department. A few of our customers who are being attacked by this same instance at EC2 have also contacted Amazon, and were told essentially the same thing. While I appreciate that they sent a response, I do not appreciate it's uselessness. Anyone over there at AWS that can do something willing to reply to me directly? Thanks! Mike On Sun, 2010-04-11 at 10:38 -0400, Erik L wrote: > Could someone from Amazon EC2 please contact me off-list regarding an abuse issue from one of their IPs? Alternatively, could someone please send me the contact details of someone there? > > E-mailing the abuse e-mail listed in WHOIS per their instructions, including all pertinent data, results in an auto-reply indicating to use a form on their site. Submitting the form results in "There has been an error while submitting your data. Please try again later." Calling their supposed NOC (as per WHOIS) results in "You have reached the legal department at Amazon...please leave a message". > > Thanks > -- ************************************************************ 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 nderitualex at gmail.com Mon Apr 12 04:49:07 2010 From: nderitualex at gmail.com (Alex Kamiru) Date: Mon, 12 Apr 2010 12:49:07 +0300 Subject: Carrier class email security recommendation Message-ID: <1271065747.2453.26.camel@akamiru> I am in the process of sourcing for a carrier class email security solution that will replace our current edge spam gateways based on open source solutions. Some solutions that am currently considering are Ironport, Fortinet Fortimail, MailFoundry and Barracuda. I'd therefore wish to know, based on your experiences, what works for you satisfactorily. Areas that are key for me are centralized management and reporting, carrier class performance, per mailbox policy and quarantine, and favourable licensing for an MSSP. I know Ironport is rated highly in this space but I find its per user licensing is not favourable for a MSSP. Regards, Alex. From fw at deneb.enyo.de Mon Apr 12 05:07:16 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 12 Apr 2010 12:07:16 +0200 Subject: legacy /8 In-Reply-To: <48563.1271019473@nsa.vix.com> (Paul Vixie's message of "Sun, 11 Apr 2010 20:57:53 +0000") References: <4BB65B39.8010902@mompl.net> <4BB69310.7080205@jsbc.cc> <5A6D953473350C4B9995546AFE9939EE08FE6C6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE6C6E@RWC-EX1.corp.seven.com> <4BB7621B.9030607@cox.net> <5A6D953473350C4B9995546AFE9939EE08FE6C72@RWC-EX1.corp.seven.com> <4BC1FB93.3060706@emmanuelcomputerconsulting.com> <4A03EAD0-8BDC-408E-A513-41CC6B9F4F7E@delong.com> <1E42BBC9-E7EA-4A1B-B62C-335F2D367FCB@virtualized.org> <48563.1271019473@nsa.vix.com> Message-ID: <87zl199e7f.fsf@mid.deneb.enyo.de> * Paul Vixie: > as you have pointed out many times, ipv6 offers the same number of /32's > as ipv4. however, a /32 worth of ipv6 is enough for a lifetime even for > most multinationals, With 6RD on the table, this is not quite correct anymore. From ops.lists at gmail.com Mon Apr 12 05:07:46 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 12 Apr 2010 15:37:46 +0530 Subject: Carrier class email security recommendation In-Reply-To: <1271065747.2453.26.camel@akamiru> References: <1271065747.2453.26.camel@akamiru> Message-ID: You have multiple options 1. Ironport / Fortinet etc gateways. [Not barracuda - hardly carrier class, enterprise grade more like it] 2. Outsource to a provider like Messagelabs or MXLogic that only handles the spam filtering, lets you host your own mailboxes 3. Outsource to one or more vendors of hosted email services - Google Apps, Microsoft BPOS, IBM Lotuslive etc your choice based on what meets your requirements. --srs (full disclosure - head, antispam @ ibm lotuslive) 2010/4/12 Alex Kamiru : > I am in the process of sourcing for a carrier class email security > solution that will replace our current edge spam gateways based on open > source solutions. Some solutions that am currently considering are > Ironport, Fortinet Fortimail, MailFoundry and Barracuda. I'd therefore > wish to know, based on your experiences, what works for you > satisfactorily. Areas that are key for me are centralized management and > reporting, carrier class performance, per mailbox policy and quarantine, > and favourable licensing for an MSSP. I know Ironport is rated highly in > this space but I find its per user licensing is not favourable for a > MSSP. -- Suresh Ramasubramanian (ops.lists at gmail.com) From nderitualex at gmail.com Mon Apr 12 05:15:41 2010 From: nderitualex at gmail.com (Alex Kamiru) Date: Mon, 12 Apr 2010 13:15:41 +0300 Subject: Carrier class email security recommendation In-Reply-To: References: <1271065747.2453.26.camel@akamiru> Message-ID: <1271067341.2453.30.camel@akamiru> Suresh, I am more interested in option 1 and would want opinion from those with experience on that. -----Original Message----- From: Suresh Ramasubramanian To: Alex Kamiru Cc: nanog Subject: Re: Carrier class email security recommendation Date: Mon, 12 Apr 2010 15:37:46 +0530 You have multiple options 1. Ironport / Fortinet etc gateways. [Not barracuda - hardly carrier class, enterprise grade more like it] 2. Outsource to a provider like Messagelabs or MXLogic that only handles the spam filtering, lets you host your own mailboxes 3. Outsource to one or more vendors of hosted email services - Google Apps, Microsoft BPOS, IBM Lotuslive etc your choice based on what meets your requirements. --srs (full disclosure - head, antispam @ ibm lotuslive) 2010/4/12 Alex Kamiru : > I am in the process of sourcing for a carrier class email security > solution that will replace our current edge spam gateways based on open > source solutions. Some solutions that am currently considering are > Ironport, Fortinet Fortimail, MailFoundry and Barracuda. I'd therefore > wish to know, based on your experiences, what works for you > satisfactorily. Areas that are key for me are centralized management and > reporting, carrier class performance, per mailbox policy and quarantine, > and favourable licensing for an MSSP. I know Ironport is rated highly in > this space but I find its per user licensing is not favourable for a > MSSP. From ops.lists at gmail.com Mon Apr 12 05:21:58 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 12 Apr 2010 15:51:58 +0530 Subject: Carrier class email security recommendation In-Reply-To: <1271067341.2453.30.camel@akamiru> References: <1271065747.2453.26.camel@akamiru> <1271067341.2453.30.camel@akamiru> Message-ID: Right. Just to add one more choice into your mix .. Bizanga is one such vendor that I've seen deployed by carriers who want an appliance. They were recently acquired by Cloudmark. There are also "rate limiting .. kind of like netflow for email" type devices - Symantec E160, and Mailchannels (mailchannels.com). These might be worth considering for systemwide filtering after which you can apply your own policies per user. ps: About Barracuda - I am not aware, they may have a carrier grade / larger scale product too. If you see one of those, or any other vendor that meets your needs go for it. -suresh 2010/4/12 Alex Kamiru : > Suresh, > I am more interested in option 1 and would want opinion from those with > experience on that. > > -----Original Message----- > From: Suresh Ramasubramanian > To: Alex Kamiru > Cc: nanog > Subject: Re: Carrier class email security recommendation > Date: Mon, 12 Apr 2010 15:37:46 +0530 > > You have multiple options > > 1. Ironport / Fortinet etc gateways. [Not barracuda - hardly carrier > class, enterprise grade more like it] > > 2. Outsource to a provider like Messagelabs or MXLogic that only > handles the spam filtering, lets you host your own mailboxes > > 3. Outsource to one or more vendors of hosted email services - Google > Apps, Microsoft BPOS, IBM Lotuslive etc > > your choice based on what meets your requirements. > > --srs (full disclosure - head, antispam @ ibm lotuslive) > > 2010/4/12 Alex Kamiru : >> I am in the process of sourcing for a carrier class email security >> solution that will replace our current edge spam gateways based on open >> source solutions. Some solutions that am currently considering are >> Ironport, Fortinet Fortimail, MailFoundry and Barracuda. I'd therefore >> wish to know, based on your experiences, what works for you >> satisfactorily. Areas that are key for me are centralized management and >> reporting, carrier class performance, per mailbox policy and quarantine, >> and favourable licensing for an MSSP. I know Ironport is rated highly in >> this space but I find its per user licensing is not favourable for a >> MSSP. > > > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From rs at seastrom.com Mon Apr 12 06:41:02 2010 From: rs at seastrom.com (Robert E. Seastrom) Date: Mon, 12 Apr 2010 07:41:02 -0400 Subject: Solar Flux In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6E60@RWC-EX1.corp.seven.com> (George Bonser's message of "Sun, 11 Apr 2010 21:21:53 -0700") References: <09F712D9B8F7AF40BE523224B2487BA10D93DBDB@dtn1mbx01.gci.com> <4BC29631.6010603@altadena.net> <5A6D953473350C4B9995546AFE9939EE08FE6E60@RWC-EX1.corp.seven.com> Message-ID: <864ojgj3u9.fsf@seastrom.com> "George Bonser" writes: >> -----Original Message----- >> From: Pete Carah [mailto:pete at altadena.net] >> Sent: Sunday, April 11, 2010 8:41 PM >> To: nanog at nanog.org >> Subject: Re: Solar Flux >> >> And to top it all off, how many picojoules are stored in a modern ram >> cell >> compared to the same during the last sunspot peak. There is a hidden >> cost to memory density growth here... >> >> -- Pete >> > > This cycle is currently predicted to be quite tame by recent standards. > So far NASA is predicting cycle 24 to be much weaker than 23 was: > > http://solarscience.msfc.nasa.gov/images/f107_predict.gif > > http://solarscience.msfc.nasa.gov/predict.shtml That said, nobody got it right in terms of the depth or length of the current valley, and we are in the bear skins and flint knives era of predicting Sol's activity. Also, a weak cycle (integration over a period of 11 years) does not mean there won't be brief periods of utter insanity. -r From tglassey at earthlink.net Mon Apr 12 07:37:39 2010 From: tglassey at earthlink.net (todd glassey) Date: Mon, 12 Apr 2010 05:37:39 -0700 Subject: Solar Flux In-Reply-To: <4BC20126.30808@opus1.com> References: <4BC20126.30808@opus1.com> Message-ID: <4BC31413.5080307@earthlink.net> On 4/11/2010 10:04 AM, Joel M Snyder wrote: SNIP > > On the other hand, another effect of solar flares is UV radiation, so a > good pair of sunglasses and some high-SPF sunblock would be good to > have, plus make you look less like a nerd. Unless you use that zinc > stuff on your nose, in which case you look more like a nerd. YMMV. > > jms > > Joel, one of my partners kid's collects Barbie dolls and since the new Barbie is "geek girl" or "Engineer Barbie" the idea that being a geek is offensive may have finally been put to death as it should have 20 years ago. http://www.chipchick.com/2010/02/computer-engineer-barbie.html Todd Glassey -------------- next part -------------- A non-text attachment was scrubbed... Name: tglassey.vcf Type: text/x-vcard Size: 125 bytes Desc: not available URL: From jgreco at ns.sol.net Mon Apr 12 07:51:25 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 12 Apr 2010 07:51:25 -0500 (CDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <0D478936-091E-4807-B1B3-025C86154387@delong.com> from "Owen DeLong" at Apr 11, 2010 09:39:41 AM Message-ID: <201004121251.o3CCpP9P001633@aurora.sol.net> > > > On Apr 11, 2010, at 9:17 AM, Joe Greco wrote: > > >>> Put less tersely: > >>> > >>> We were assigned space, under a policy whose purpose was primarily to > >>> guarantee uniqueness in IPv4 numbering. As with other legacy holders, > >>> we obtained portable space to avoid the technical problems associated > >>> with renumbering, problems with in-addr.arpa subdelegation, etc. > >> > >> So far, correct. > >> > >>> Part of that was an understanding that the space was ours (let's not > >>> get distracted by any "ownership" debate, but just agree for the sake > >>> of this point that it was definitely understood that we'd possess it). > >>> This served the good of the Internet by promoting stability within an > >>> AS and allowed us to spend engineering time on finer points (such as > >>> maintaining PTR's) rather than renumbering gear every time we changed > >>> upstreams. > >>> > >> This is fictitious unless you are claiming that your allocation predates: > >> > >> RFC2050 November, 1996 > >> RFC1466 May, 1993 > >> RFC1174 August, 1990 > >> > >> Prior to that, it was less clear, but, the concept was still generally > >> justified need so long as that need persisted. > > > > Which ours does. > > > >>> Eventually InterNIC was disbanded, and components went in various > >>> directions. ARIN landed the numbering assignment portion of InterNIC. > >>> Along with that, maintenance of the legacy resources drifted along to > >>> ARIN. > >> > >> Actually, ARIN was spun off from InterNIC (containing most of the same > >> staff that had been doing the job at InterNIC) well before InterNIC was > >> disbanded. > > > > Is there an effective difference or are you just quibbling? For the > > purposes of this discussion, I submit my description was suitable to > > describe what happened. > > Your description makes it sound like there was limited or no continuity > between the former and the current registration services entity. > > I point out that ARIN was formed run by and including most of the > IP-related staff from InterNIC. > > I consider that a substantive distinction. > > >>> ARIN might not have a contract with us, or with other legacy holders. > >>> It wasn't our choice for ARIN to be tasked with holding up InterNIC's > >>> end of things. However, it's likely that they've concluded that they > >>> better do so, because if they don't, it'll probably turn into a costly > >>> legal battle on many fronts, and I doubt ARIN has the budget for that. > >> > >> This is going to be one of those situations that could become a > >> legal battle on many fronts either way. On the one hand you have > >> legacy holders who have no contractual right to services from > >> anyone (If you want to pursue InterNIC for failing to live up to > >> whatever agreement you have/had with them, I wish you the > >> very best of luck in that endeavor, especially since you don't > >> have a written contract from them, either). > >> > >> On the other hand, in a relatively short timeframe, you are likely > >> to have litigants asking why ARIN has failed to reclaim/reuse > >> the underutilized IPv4 space sitting in so many legacy registrations. > >> > >> Which of those two bodies of litigants is larger or better funded > >> is left as an exercise for the reader. Nonetheless, ARIN is > >> going to be in an interesting position between those two > >> groups (which one is rock and which is hard place is also > >> left as an exercise for the reader) going forward regardless > >> of what action is taken by ARIN in this area. > >> > >> That is why the legacy RSA is important. It represents ARIN > >> trying very hard to codify and defend the rights of the legacy > >> holders. > > > > Yes, but according to the statistics provided by Mr. Curran, it looks > > like few legacy space holders are actually adopting the LRSA. > > > So far, yes. That's unfortunate. > > > Like many tech people, you seem to believe that the absence of a > > "contract" means that there's no responsibility, and that InterNIC's > > having been disbanded absolves ARIN from responsibility. In the real > > world, things are not so simple. The courts have much experience at > > looking at real world situations and determining what should happen. > > These outcomes are not always predictable and frequently don't seem to > > have obvious results, but they're generally expensive fights. > > No, actually, quite the opposite. I believe that BOTH legacy holders and > ARIN have responsibilities even though there is no contract. Certainly legacy holders have some responsibilities. > I believe > that ARIN is, however, responsible to the community as it exists today > and not in any way responsible to legacy holders who choose to > ignore that community and their responsibilities to it. And what, exactly, does that mean? Aside from things that were documented at the time we received our allocation, what sort of "responsibilities" do we have? We agreed to not allow anyone port away space. We advertise our space as a single block. Etc. > The reality is that the community has evolved. For the most part, the > community has been willing to let legacy holders live in their little > reality distortion bubble and accommodated their eccentricities. > I think that is as it should be, to some extent. On the other hand, > I think the history now shows that ARIN's failure to immediately > institute the same renewal pricing model on legacy holders as on > new registrants has created an unfortunate disparity and a number > of unfortunate perceptions. Contrast this with APNIC and the > domain registrars/registries shortly after the ARIN spinoff from > InterNIC, where, yes, there was much grumbling from those of > us who had legacy (domain, ip resources) from them, but, in the > long run, we paid our fees and moved on. > > Had ARIN done this on day one, perhaps it would have gone the > same way. Instead, we have a situation where the mere mention > of requiring legacy holders to pay a token annual fee like the rest > of IP end-users in the ARIN region leads to discussions like this. There's a difference between a mere token annual fee and the actual signing away of various rights. For some of us, the token annual fee isn't an issue because we're already paying it for a different resource. > FWIW, I'm a legacy holder myself, but, I have signed the LRSA > and I do have IPv6 resources under an RSA as well. No harm > has come to me as a result and it is not costing me any more > to have done so. In fact, I got my IPv6 assignment for a good > discount in the process, but, that deal is no longer available. > > Frankly, I find it remarkably short-sighted that so many legacy > holders have refused to sign the LRSA. Especially in light of > the fact that if you are sitting on excess resources and want > to be able to transfer them under NRPM 8.3, you will need > to bring them under LRSA or RSA first and the successor who > acquires them from you (under 8.2 or 8.3) will need to sign an > RSA for the transfer to be valid. That's only your opinion, and ARIN's pet legal theory. At some point, when addresses become more valuable, some cash-strapped /8-holder is going to see that they have 65K /24's that they can sell for $5,000-$10,000 each, or better yet rent out annually, and ARIN tries to enforce this new policy, and they have a huge financial incentive to crush ARIN like a bug in the courts because the new policies ARIN is trying to enforce do not resemble the ones under which they obtained the space. > >>> As a legacy holder, we don't really care who is currently "responsible" > >>> for legacy maintenance/etc. However, whoever it is, if they're not > >>> going to take on those responsibilities, that's a problem. > >> > >> You assume that anyone is currently responsible. What documentation > >> do you have that there is any such responsibility? > >> > >> As a point in fact, ARIN has, for the good of the community, extended > >> the courtesy of maintaining those records and providing services > >> to legacy holders free of charge because it is perceived as being > >> in the best interests of the community. > > > > That's only one possible interpretation. A court might well reach a more > > general conclusion that ARIN is the successor to InterNIC, and has agreed > > to honor legacy registrations. That'd be inconvenient for ARIN, but is a > > very reasonable possible outcome. > > > As a general rule, courts tend to rule that absent an exchange of value, there > is no contract. They also tend to rule that contracts which contain significantly > inequitable exchanges of value are invalid. > > Since ARIN is collecting nothing from legacy holders and not getting > funded by NSF or other US Government agency the way InterNIC was, > it's hard to see where you would find the exchange of value to support > that conclusion. You're using the state of affairs NOW to dismantle an agreement that was made THEN? Lose your job and then tell the foreclosure court, "you should invalidate this because the state of affairs changed, I no longer have a job and no money to pay for the mortgage, so obviously I owe the bank nothing." Legally, a change in your status doesn't necessarily affect your responsibilies. Further, given the purported role that InterNIC played, "exchange of value" as a prerequisite is a rather questionable position to rely on; InterNIC had motivations other than a purely financial one to organize IP allocations. The number assignment function is critical to allowing the Internet to work smoothly. > Additionally, it could be argued that by refusing to sign the LRSA or RSA > and refusing to participate in the community on a level playing field with > others, legacy holders are not meeting their obligations under your > implied contract theory. To compel someone to do anything in order to keep something that they've already been assigned might also be viewed as onerous. > IANAL, so I could be completely wrong here and this is just my personal > opinion, not a statement of ARIN or the AC. It's all theory until someone works it out in court. > >>> The previous poster asked, "If you don't have a contract with ARIN, > >>> why should ARIN provide you with anything?" > >>> > >>> Well, the flip side to that is, "ARIN doesn't have a contract with us, > >>> but we still have copies of the InterNIC policies under which we were > >>> assigned space, and ARIN undertook those duties, so ARIN is actually > >>> the one with significant worries if they were to try to pull anything, > >>> otherwise, we don't really care." > >> > >> Could you please provide those to Steve Ryan, John Curran, and, > >> ideally, I'd like to see them too. > >> > >>> Is that a suitable defense of that statement (which might not have > >>> been saying quite what you thought)? > >> > >> I don't know. I have yet to see the content of the documents which > >> you claim are your defense. > > > > I'd be pleased to pull them off our backups for our normal hourly rates. > > Otherwise, you're encouraged to do your own research. > > I've done my own research... I've come up with nothing. You're the one > claiming you have documentation to support your assertions... > > To be blunt, put up or shut up. Send your check for $350 to cover the first few hours of work to sol.net Network Services P.O. Box 16 Milwaukee, WI 53201-0016 And I'll be happy to have someone go digging through our data storage for the documents. ... 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 erik_list at caneris.com Mon Apr 12 08:05:09 2010 From: erik_list at caneris.com (Erik L) Date: Mon, 12 Apr 2010 09:05:09 -0400 Subject: Seeking Amazon EC2 abuse contact In-Reply-To: <1271063763.6107.3179.camel@mike-desktop> References: , <1271063763.6107.3179.camel@mike-desktop> Message-ID: Michael, I've received numerous off-list responses yesterday. Most of them were asking if I've made contact with anyone there as they were being attacked as well. One gentleman who works at AWS (but not EC2 abuse) promised to forward my e-mail to them. I've also been reading the asterisk-users list where many have reported attacks from Amazon EC2 as well over the past few days. At one point we were seeing 197 SIP brute force attempts per second against a customer's box. The intensity in terms of bandwidth is low, but if you do the math, you can see that this isn't the point. This morning I received an e-mail from Amazon which was basically the same as the one you received. The attack is still on-going and I've still not made contact with a human at Amazon. Erik > -----Original Message----- > From: Michael J McCafferty [mailto:mike at m5computersecurity.com] > Sent: April 12, 2010 05:16 > To: Erik L > Cc: nanog at nanog.org > Subject: Re: Seeking Amazon EC2 abuse contact > > Erik, > We have several customers being attacked from the same > EC2 instance on > their network for 2 full days now. Contacted them at > ec2-abuse at amazon.com and 25 hours later received a message that > basically said, "Yep, we can confirm that a customer of ours is > attacking you but that's their fault. We sometimes do stuff, > but not in > this case. Please don't block us, because the IP might be someone else > later. Have a nice day". > The telephone number in the WHOIS record goes to a > general voicemail > box for their legal department. > A few of our customers who are being attacked by this > same instance at > EC2 have also contacted Amazon, and were told essentially the same > thing. > While I appreciate that they sent a response, I do not > appreciate it's > uselessness. > Anyone over there at AWS that can do something willing > to reply to me > directly? > > Thanks! > Mike > > > On Sun, 2010-04-11 at 10:38 -0400, Erik L wrote: > > Could someone from Amazon EC2 please contact me off-list > regarding an abuse issue from one of their IPs? > Alternatively, could someone please send me the contact > details of someone there? > > > > E-mailing the abuse e-mail listed in WHOIS per their > instructions, including all pertinent data, results in an > auto-reply indicating to use a form on their site. Submitting > the form results in "There has been an error while submitting > your data. Please try again later." Calling their supposed > NOC (as per WHOIS) results in "You have reached the legal > department at Amazon...please leave a message". > > > > Thanks > > > -- > ************************************************************ > 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 mark at streamservice.nl Mon Apr 12 08:39:26 2010 From: mark at streamservice.nl (Mark Scholten) Date: Mon, 12 Apr 2010 15:39:26 +0200 Subject: Seeking Amazon EC2 abuse contact In-Reply-To: References: , <1271063763.6107.3179.camel@mike-desktop> Message-ID: <02a601cada45$91aa34d0$b4fe9e70$@nl> Hello Erik, Do you care to share the IP address? So everyone could update their firewalls to block the attacks? Even only blocking known SIP ports (5060) could be a good idea. With kind regards, Mark Scholten > -----Original Message----- > From: Erik L [mailto:erik_list at caneris.com] > Sent: Monday, April 12, 2010 3:05 PM > To: Michael J McCafferty > Cc: nanog at nanog.org > Subject: RE: Seeking Amazon EC2 abuse contact > > Michael, > > I've received numerous off-list responses yesterday. Most of them were > asking if I've made contact with anyone there as they were being > attacked as well. One gentleman who works at AWS (but not EC2 abuse) > promised to forward my e-mail to them. I've also been reading the > asterisk-users list where many have reported attacks from Amazon EC2 as > well over the past few days. > > At one point we were seeing 197 SIP brute force attempts per second > against a customer's box. The intensity in terms of bandwidth is low, > but if you do the math, you can see that this isn't the point. > > This morning I received an e-mail from Amazon which was basically the > same as the one you received. The attack is still on-going and I've > still not made contact with a human at Amazon. > > Erik > > > > > -----Original Message----- > > From: Michael J McCafferty [mailto:mike at m5computersecurity.com] > > Sent: April 12, 2010 05:16 > > To: Erik L > > Cc: nanog at nanog.org > > Subject: Re: Seeking Amazon EC2 abuse contact > > > > Erik, > > We have several customers being attacked from the same > > EC2 instance on > > their network for 2 full days now. Contacted them at > > ec2-abuse at amazon.com and 25 hours later received a message that > > basically said, "Yep, we can confirm that a customer of ours is > > attacking you but that's their fault. We sometimes do stuff, > > but not in > > this case. Please don't block us, because the IP might be someone > else > > later. Have a nice day". > > The telephone number in the WHOIS record goes to a > > general voicemail > > box for their legal department. > > A few of our customers who are being attacked by this > > same instance at > > EC2 have also contacted Amazon, and were told essentially the same > > thing. > > While I appreciate that they sent a response, I do not > > appreciate it's > > uselessness. > > Anyone over there at AWS that can do something willing > > to reply to me > > directly? > > > > Thanks! > > Mike > > > > > > On Sun, 2010-04-11 at 10:38 -0400, Erik L wrote: > > > Could someone from Amazon EC2 please contact me off-list > > regarding an abuse issue from one of their IPs? > > Alternatively, could someone please send me the contact > > details of someone there? > > > > > > E-mailing the abuse e-mail listed in WHOIS per their > > instructions, including all pertinent data, results in an > > auto-reply indicating to use a form on their site. Submitting > > the form results in "There has been an error while submitting > > your data. Please try again later." Calling their supposed > > NOC (as per WHOIS) results in "You have reached the legal > > department at Amazon...please leave a message". > > > > > > Thanks > > > > > -- > > ************************************************************ > > 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 dbl at acme-ent.net Sat Apr 10 19:46:09 2010 From: dbl at acme-ent.net (David Loutrel) Date: Sat, 10 Apr 2010 16:46:09 -0800 Subject: unsubscribe Message-ID: <4BC11BD1.5000700@acme-ent.net> -- David B. Loutrel, Operations Manager ACME Hosting & Design [1]www.acme-ent.net References 1. http://www.acme-ent.net/ From tglassey at earthlink.net Mon Apr 12 08:52:36 2010 From: tglassey at earthlink.net (todd glassey) Date: Mon, 12 Apr 2010 06:52:36 -0700 Subject: Seeking Amazon EC2 abuse contact In-Reply-To: <02a601cada45$91aa34d0$b4fe9e70$@nl> References: , <1271063763.6107.3179.camel@mike-desktop> <02a601cada45$91aa34d0$b4fe9e70$@nl> Message-ID: <4BC325A4.4030401@earthlink.net> On 4/12/2010 6:39 AM, Mark Scholten wrote: > Hello Erik, > > Do you care to share the IP address? So everyone could update their > firewalls to block the attacks? Even only blocking known SIP ports (5060) > could be a good idea. The easiest thing to do is to block all of EC2 and not worry about it. > > With kind regards, > > Mark Scholten The person to formally put on notice now then is Amazon's general counsel Michelle Wilson about the damage their (her) policies and practices are causing when these types of attacks emanate out of their IP Space since they apparently have dealt in bad faith by placing bogus contact information therein. I assure you Michelle will react VERY quickly to being notified. http://people.forbes.com/profile/l-michelle-wilson/4002 Todd Glassey > >> -----Original Message----- >> From: Erik L [mailto:erik_list at caneris.com] >> Sent: Monday, April 12, 2010 3:05 PM >> To: Michael J McCafferty >> Cc: nanog at nanog.org >> Subject: RE: Seeking Amazon EC2 abuse contact >> >> Michael, >> >> I've received numerous off-list responses yesterday. Most of them were >> asking if I've made contact with anyone there as they were being >> attacked as well. One gentleman who works at AWS (but not EC2 abuse) >> promised to forward my e-mail to them. I've also been reading the >> asterisk-users list where many have reported attacks from Amazon EC2 as >> well over the past few days. >> >> At one point we were seeing 197 SIP brute force attempts per second >> against a customer's box. The intensity in terms of bandwidth is low, >> but if you do the math, you can see that this isn't the point. >> >> This morning I received an e-mail from Amazon which was basically the >> same as the one you received. The attack is still on-going and I've >> still not made contact with a human at Amazon. >> >> Erik >> >> >> >>> -----Original Message----- >>> From: Michael J McCafferty [mailto:mike at m5computersecurity.com] >>> Sent: April 12, 2010 05:16 >>> To: Erik L >>> Cc: nanog at nanog.org >>> Subject: Re: Seeking Amazon EC2 abuse contact >>> >>> Erik, >>> We have several customers being attacked from the same >>> EC2 instance on >>> their network for 2 full days now. Contacted them at >>> ec2-abuse at amazon.com and 25 hours later received a message that >>> basically said, "Yep, we can confirm that a customer of ours is >>> attacking you but that's their fault. We sometimes do stuff, >>> but not in >>> this case. Please don't block us, because the IP might be someone >> else >>> later. Have a nice day". >>> The telephone number in the WHOIS record goes to a >>> general voicemail >>> box for their legal department. >>> A few of our customers who are being attacked by this >>> same instance at >>> EC2 have also contacted Amazon, and were told essentially the same >>> thing. >>> While I appreciate that they sent a response, I do not >>> appreciate it's >>> uselessness. >>> Anyone over there at AWS that can do something willing >>> to reply to me >>> directly? >>> >>> Thanks! >>> Mike >>> >>> >>> On Sun, 2010-04-11 at 10:38 -0400, Erik L wrote: >>>> Could someone from Amazon EC2 please contact me off-list >>> regarding an abuse issue from one of their IPs? >>> Alternatively, could someone please send me the contact >>> details of someone there? >>>> >>>> E-mailing the abuse e-mail listed in WHOIS per their >>> instructions, including all pertinent data, results in an >>> auto-reply indicating to use a form on their site. Submitting >>> the form results in "There has been an error while submitting >>> your data. Please try again later." Calling their supposed >>> NOC (as per WHOIS) results in "You have reached the legal >>> department at Amazon...please leave a message". >>>> >>>> Thanks >>>> >>> -- >>> ************************************************************ >>> 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 >>> ************************************************************ >>> >>> > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: tglassey.vcf Type: text/x-vcard Size: 125 bytes Desc: not available URL: From streiner at cluebyfour.org Mon Apr 12 09:02:08 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 12 Apr 2010 10:02:08 -0400 (EDT) Subject: unsubscribe In-Reply-To: <4BC11BD1.5000700@acme-ent.net> References: <4BC11BD1.5000700@acme-ent.net> Message-ID: On Sat, 10 Apr 2010, David Loutrel wrote: > -- > David B. Loutrel, Operations Manager > ACME Hosting & Design > [1]www.acme-ent.net > > References > > 1. http://www.acme-ent.net/ If you look in the message headers, you will see list management info, including how to unsubscribe yourself from the list. jms From tglassey at earthlink.net Mon Apr 12 09:09:12 2010 From: tglassey at earthlink.net (todd glassey) Date: Mon, 12 Apr 2010 07:09:12 -0700 Subject: Carrier class email security recommendation In-Reply-To: <1271065747.2453.26.camel@akamiru> References: <1271065747.2453.26.camel@akamiru> Message-ID: <4BC32988.5080606@earthlink.net> On 4/12/2010 2:49 AM, Alex Kamiru wrote: > I am in the process of sourcing for a carrier class email security > solution that will replace our current edge spam gateways based on open > source solutions. Some solutions that am currently considering are > Ironport, Fortinet Fortimail, MailFoundry and Barracuda. I'd therefore > wish to know, based on your experiences, what works for you > satisfactorily. > Areas that are key for me are centralized management and > reporting, carrier class performance, per mailbox policy and quarantine, > and favourable licensing for an MSSP. I know Ironport is rated highly in > this space but I find its per user licensing is not favourable for a > MSSP. On the other hand installing a FreeBSD system with QMail/Procmail and/or PostFIX for the other stuff is a no-brainer especially with a Webmin Management front end. > > Regards, > Alex. > Alex there are many email systems out there - but make sure that whatever you buy can support NTPv4 and not SNTP or unauthenticated NTP since this is how the GW is going to be able to put time-marks on receipts which must have legal authority. So that means any appliance system provider must have at least NTPv4 tested with both Autokey and symmetric-key and the new interface specific ACL's in the 4.2.6 versions of NTP. Further the issues of the ECC/Parity memory become important here because time is moved over UDP and is subject to single-bit errors all over the place. Todd Glassey > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: tglassey.vcf Type: text/x-vcard Size: 125 bytes Desc: not available URL: From nenolod at systeminplace.net Mon Apr 12 09:14:34 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 12 Apr 2010 09:14:34 -0500 Subject: Carrier class email security recommendation In-Reply-To: <4BC32988.5080606@earthlink.net> References: <1271065747.2453.26.camel@akamiru> <4BC32988.5080606@earthlink.net> Message-ID: <1271081674.13545.125.camel@petrie> On Mon, 2010-04-12 at 07:09 -0700, todd glassey wrote: > On 4/12/2010 2:49 AM, Alex Kamiru wrote: > > I am in the process of sourcing for a carrier class email security > > solution that will replace our current edge spam gateways based on open > > source solutions. Some solutions that am currently considering are > > Ironport, Fortinet Fortimail, MailFoundry and Barracuda. I'd therefore > > wish to know, based on your experiences, what works for you > > satisfactorily. > > > > Areas that are key for me are centralized management and > > reporting, carrier class performance, per mailbox policy and quarantine, > > and favourable licensing for an MSSP. I know Ironport is rated highly in > > this space but I find its per user licensing is not favourable for a > > MSSP. > > On the other hand installing a FreeBSD system with QMail/Procmail and/or > PostFIX for the other stuff is a no-brainer especially with a Webmin > Management front end. Webmin? Are you serious? William From tglassey at earthlink.net Mon Apr 12 09:18:18 2010 From: tglassey at earthlink.net (todd glassey) Date: Mon, 12 Apr 2010 07:18:18 -0700 Subject: Carrier class email security recommendation In-Reply-To: <1271081674.13545.125.camel@petrie> References: <1271065747.2453.26.camel@akamiru> <4BC32988.5080606@earthlink.net> <1271081674.13545.125.camel@petrie> Message-ID: <4BC32BAA.5080601@earthlink.net> On 4/12/2010 7:14 AM, William Pitcock wrote: > On Mon, 2010-04-12 at 07:09 -0700, todd glassey wrote: >> On 4/12/2010 2:49 AM, Alex Kamiru wrote: >>> I am in the process of sourcing for a carrier class email security >>> solution that will replace our current edge spam gateways based on open >>> source solutions. Some solutions that am currently considering are >>> Ironport, Fortinet Fortimail, MailFoundry and Barracuda. I'd therefore >>> wish to know, based on your experiences, what works for you >>> satisfactorily. >> >> >>> Areas that are key for me are centralized management and >>> reporting, carrier class performance, per mailbox policy and quarantine, >>> and favourable licensing for an MSSP. I know Ironport is rated highly in >>> this space but I find its per user licensing is not favourable for a >>> MSSP. >> >> On the other hand installing a FreeBSD system with QMail/Procmail and/or >> PostFIX for the other stuff is a no-brainer especially with a Webmin >> Management front end. > > Webmin? Are you serious? Yes William, but realize that was an "easiest method" solution. There are any number of others as well. The point is that integrating an appliance type functionality is pretty easy if you bother to take the time. What I really wanted to point out is how many of the devices dont allow authenticated NTP meaning they are worthless from an evidence perspective, something that we as network engineers are constrained by as well. Todd > > William > > -------------- next part -------------- A non-text attachment was scrubbed... Name: tglassey.vcf Type: text/x-vcard Size: 133 bytes Desc: not available URL: From ops.lists at gmail.com Mon Apr 12 09:22:23 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 12 Apr 2010 19:52:23 +0530 Subject: Carrier class email security recommendation In-Reply-To: <4BC32BAA.5080601@earthlink.net> References: <1271065747.2453.26.camel@akamiru> <4BC32988.5080606@earthlink.net> <1271081674.13545.125.camel@petrie> <4BC32BAA.5080601@earthlink.net> Message-ID: The man did say "carrier class" .. not "small webhost for four families and dog". You're talking multiple mailservers + filtering gateways / appliances etc, clustered .. rather tough to do that with one pizzabox 1U running a linux that's not updated in years and configured with webmin. And have you used / deployed any of those devices to claim they don't support NTP? Or whether that's a bigger constraint than an underpowered linux box? :) On Mon, Apr 12, 2010 at 7:48 PM, todd glassey wrote: > Yes William, but realize that was an "easiest method" solution. There > are any number of others as well. > > The point is that integrating an appliance type functionality is pretty > easy if you bother to take the time. > > What I really wanted to point out is how many of the devices dont allow > authenticated NTP meaning they are worthless from an evidence > perspective, something that we as network engineers are constrained by > as well. -- Suresh Ramasubramanian (ops.lists at gmail.com) From Joel.Snyder at Opus1.COM Mon Apr 12 09:57:02 2010 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Mon, 12 Apr 2010 07:57:02 -0700 Subject: Carrier class email security recommendation In-Reply-To: References: Message-ID: <4BC334BE.4000304@opus1.com> >I am in the process of sourcing for a carrier class email security >solution that will replace our current edge spam gateways based on open >source solutions. Some solutions that am currently considering are >Ironport, Fortinet Fortimail, MailFoundry and Barracuda. A lot of the answer depends on what you think of as "carrier class." Generally, I would consider a carrier-class device to have a couple of attributes that are different from a typical enterprise-class device: Quarantine: carrier class: no (enterprise: maybe) Per-user settings: carrier class: no (enterprise: maybe) False positive rate: carrier class: very very low (enterprise: very low) False negative rate: carrier class: low (enterprise: very low) Performance: carrier class: critical (enterprise: important) In other words, I think of a carrier-class product as something that sits in the mail stream and does a good job of blocking spam, but is setup so that no one needs to talk about it. You don't want to get a stream of false-positive reports, but you are willing to let some spam through in order to avoid help desk calls. The goal of this product is mostly to keep your mail servers happy, and as a secondary goal, keeps the users happy. You could have a second level of anti-spam protection, something more Postini-esque, which is carrier-sized but has a lot more user interaction and user settings, for people who want to get premium anti-spam protection. But that's more an enterprise product that scales up, which is subtly--but importantly--different from a carrier product. We test anti-spam products for efficacy (essentially FP & FN performance), less so for performance. If you are looking at Ironport, then you want to ask them about the Cloudmark anti-spam engine. It is a "carrier-focused" engine, and you'll find that the pricing is MUCH better than their own engine once you get to large numbers of users. In fact, I believe that they added the Cloudmark engine specifically to address queries like yours--people who like the product architecture, but are turned off by the licensing. With Cloudmark inside, you get the same product flow and features, but a less expensive engine good for large ISPs. In terms of speed, the obvious feature to look for is reputation services. This gives you an enormous savings. Symantec used to offer a box based on Turntide, which was a standalone throttle for spam; I don't know if they have that as a standalone or not, but if they do, I'd recommend something like that. You may be able to roll your own as well fairly easily since there's no MTA to worry about. The win with reputation services is fantastic. For example, I did a test with a Crossbeam box and Trend a while ago (http://www.opus1.com/www/whitepapers/crossbeam-perf.pdf) and we were getting a steady-state 600 message/second without reputation filtering; with reputation filtering, about 1645 messages/second. That's using MAPS RBL+, which is a low-risk reputation service. Plug in a service like Spamhaus or Ironport's SenderBase, and you would get closer to 2500 message/second (about 200 million messages/day). Based on our testing, for a carrier-class deployment, I'd recommend looking at Ironport+Cloudmark, Trend, and Tumbleweed (now Axway). There are other good products (Proofpoint, for example, turns in great scores as does Sophos), but performance-wise they may not be able to scale up to the kind of load you're talking about when you say "Carrier Class." Feel free to contact me offline if you need more observations, etc. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From twilde at cymru.com Mon Apr 12 10:14:59 2010 From: twilde at cymru.com (Tim Wilde) Date: Mon, 12 Apr 2010 11:14:59 -0400 Subject: Major additions to Team Cymru's Bogon Feed Message-ID: <4BC338F3.9050507@cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings everyone! Team Cymru is pleased to announce a significant addition to our bogon reference project. The new portions of the project are offered at no cost to the community, and the original bogon lists and feeds are not being changed or canceled, just augmented. The new "fullbogon" feed includes prefixes allocated to RIRs, but not assigned by the RIRs to end-users, ISPs, etc, providing a more complete view of the unassigned space that should not be seen on the Internet. This new service is therefore more granular than the original feed, including a wide variety of non-routable prefixes as well as unassigned prefixes. We're also making IPv6 bogons available in these new feeds. If you're interested in receiving the new "fullbogon" feeds via BGP, simply e-mail bogonrs at cymru.com with your ASN, peering IP addresses and whether you use MD5 authentication. See an overview in the 46th episode of Team Cymru's 'The Who and Why Show' at www.youtube.com/teamcymru, as well as a more basic overview in episode 12. For a more detailed explanation of all the ways you can track the bogons, see the newly-updated bogon reference pages at: http://www.team-cymru.org/Services/Bogons/ Even more so than the original feed, there are significant changes to the fullbogons lists every day and the feed automatically recalculates the prefixes as they are allocated from the regional registries, so make sure you are able to regularly update your lists. Internet security is all about "the other guy." If one sizeable network is insecure, it WILL be used to abuse other networks. We look forward to continuing to help our community to secure the edge. Best regards, Tim Wilde, for Team Cymru - -- Tim Wilde, Senior Software Engineer, Team Cymru, Inc. twilde at cymru.com | +1-630-230-5433 | http://www.team-cymru.org/ -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkvDOPMACgkQluRbRini9tg0JACfSKs3TaNgACE9LEdbbjYY8/JS +DIAnjbFISSHMVfqe512mi70FQ6tQA+6 =0OAO -----END PGP SIGNATURE----- From tglassey at earthlink.net Mon Apr 12 10:15:19 2010 From: tglassey at earthlink.net (todd glassey) Date: Mon, 12 Apr 2010 08:15:19 -0700 Subject: Carrier class email security recommendation In-Reply-To: References: <1271065747.2453.26.camel@akamiru> <4BC32988.5080606@earthlink.net> <1271081674.13545.125.camel@petrie> <4BC32BAA.5080601@earthlink.net> Message-ID: <4BC33907.4060605@earthlink.net> On 4/12/2010 7:22 AM, Suresh Ramasubramanian wrote: > The man did say "carrier class" .. not "small webhost for four > families and dog". yes he did Suresh ... meaning that something larger and more secure than the off-the-shelf copy of Linux is needed. Funny the NSA and many others would disagree with you. > You're talking multiple mailservers + filtering > gateways / appliances etc, clustered .. or layered as stages within a new system design based on GPU's which allow for the specific assignment of threads of control to specific processes. Imaging a cloud type environment running in a single GPU with the abililty to properly map threads to GPU threads. > rather tough to do that with > one pizzabox 1U running a linux that's not updated in years and > configured with webmin. OK our server is 3U but that was because I wanted bigger fans inside it... The 1U single TESLA based email GW is exactly what you describe - a 512 thread CUDA based GPU with serious capabilities therein. FYI CUDA, and the embedded nVidia GPU's changed that. Do have any idea how fast the email filters run in a CUDA, I do... and its mindblowing. Hell the TESLA family of card's 90 to 128 parallel threads of control per GPU Core can be assigned through CUDA to specific processes and whamo - more OS horse power than you know what to do with. The high end cards generally have 2 or 4 GPU's making the total thread count from 180 to 512 based on the model. The Pentium 4 sports a whopping four (4) threads of control... 1 per core. We use 8800's for end-node systems and the larger TESLA based service modules in scaleable production systems. The cool part is running NTP in the embedded CUDA card with permanently assigned TOC's (*threads of control) so that the process never blocks. That and the 1PPS disciplining makes time available to everything in the system. As to who's appliances do and dont' - ------------------------------------- IronPORT is a FreeBSD type deployment so it does... most of the Linux Appliance systems can but many of them don't like Barracuda for instance. In fact you may want to call Barracuda and ask for Stephen Gee or Steven Pao - both of them will tell you they will not be upgrading to a secure NTP version for some time unless the customer's demand it. Their emails (Stephen and Steven's) are SPao at Barracuda.COM and SGee at Barracuda.COM so now you can ask them for yourself. Or whether that's a bigger constraint than an > underpowered linux box? :) Yeah - see a linux box with a Quad Pentium and a CUDA is a carrier class device especially if its a dual-processor and has redundant bus and power supplies. In fact these same systems are also used in submicrosecond trading (aka Algorthmic trading) so yes of course - they are weak and unscaleable systems right??? (not really Suresh). > > On Mon, Apr 12, 2010 at 7:48 PM, todd glassey wrote: >> Yes William, but realize that was an "easiest method" solution. There >> are any number of others as well. >> >> The point is that integrating an appliance type functionality is pretty >> easy if you bother to take the time. >> >> What I really wanted to point out is how many of the devices dont allow >> authenticated NTP meaning they are worthless from an evidence >> perspective, something that we as network engineers are constrained by >> as well. > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: tglassey.vcf Type: text/x-vcard Size: 133 bytes Desc: not available URL: From jcurran at arin.net Mon Apr 12 10:23:16 2010 From: jcurran at arin.net (John Curran) Date: Mon, 12 Apr 2010 11:23:16 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004121251.o3CCpP9P001633@aurora.sol.net> References: <201004121251.o3CCpP9P001633@aurora.sol.net> Message-ID: <4C3EFA25-69C2-47B9-8976-8AD329BE7C2D@arin.net> On Apr 12, 2010, at 8:51 AM, Joe Greco wrote: > > Further, given the purported role that InterNIC played, "exchange of > value" as a prerequisite is a rather questionable position to rely on; > InterNIC had motivations other than a purely financial one to organize > IP allocations. The number assignment function is critical to allowing > the Internet to work smoothly. Joe - On this matter we do agree, since allocations prior to ARIN's formation were generally made pursuant to a US Government contract or cooperative agreement. While I don't consider addresses to be property, if you take the opposite view then there's very likely a significant body of procurement law which already applies to property furnished in this manner and would be far more relevant than any documentation that an address block recipient received at the time. /John John Curran President and CEO ARIN From jtk at cymru.com Mon Apr 12 10:24:19 2010 From: jtk at cymru.com (John Kristoff) Date: Mon, 12 Apr 2010 10:24:19 -0500 Subject: Carrier class email security recommendation In-Reply-To: <4BC32988.5080606@earthlink.net> References: <1271065747.2453.26.camel@akamiru> <4BC32988.5080606@earthlink.net> Message-ID: <20100412102419.44888ebc@t61p> On Mon, 12 Apr 2010 07:09:12 -0700 todd glassey wrote: > Alex there are many email systems out there - but make sure that > whatever you buy can support NTPv4 and not SNTP or unauthenticated NTP > since this is how the GW is going to be able to put time-marks on > receipts which must have legal authority. Hi Todd, I think this is the first I've heard that only authenticated NTP (and maybe even NTPv4?) is sufficient for legal authority. Can you say a bit more about this? Perhaps, what sorts of issues you've run into or seen when this is not implemented? > So that means any appliance system provider must have at least NTPv4 > tested with both Autokey and symmetric-key and the new interface > specific ACL's in the 4.2.6 versions of NTP. Further the issues of the > ECC/Parity memory become important here because time is moved over UDP > and is subject to single-bit errors all over the place. Authentication support for SNTP does exist in the protocol and I've seen documentation where some gear supports it, though I suspect its very rarely used in practice. And 4.2.6p1 was released 3 days ago and 4.2.6 in December. Might be a tall order if you want it now. :-) I haven't work out the math, but I would have thought the UDP checksum, coupled with a rigorous implementation (e.g. validates the originate and transmit timestamps) and the various robustness mechanisms built into the protocol should limit the effect of single-bit errors significantly. I'd be interested in hearing or reading about experience that says otherwise. Nevertheless there are no doubt incorrect clocks all over the place. As a simple example, for the open NTP servers we know about, here is the top five most popular stratums by percent: stratum % 3 43 4 18 2 16 16 14 5 5 The overall accuracy of all those stratum 16 clocks is likely going to be poor. John From noc at weth.li Mon Apr 12 10:44:28 2010 From: noc at weth.li (NOC) Date: Mon, 12 Apr 2010 17:44:28 +0200 Subject: Metering power in data center In-Reply-To: <0E8773C725A1674E9F7B35EABB5EEEB108443DF5@MKA134.pcc.int> References: <0E8773C725A1674E9F7B35EABB5EEEB108443DF5@MKA134.pcc.int> Message-ID: <4BC33FDC.5080503@weth.li> Hi, For our need, we use : http://www.lem.com/ They have a lot of products to do that. We use a magnetic meter. You don't need to break the circuit to implement it. Regards, Bastien Wallace Keith a ?crit : > -----Original Message----- > From: Jay Nakamura [mailto:zeusdadog at gmail.com] > Sent: Thursday, April 08, 2010 2:10 PM > To: NANOG > Subject: Metering power in data center > > I am looking for suggestions on devices that can > monitor(A)/meter(kw/h) power usage in a data center. Getting a > metered PDU everywhere seems a little expensive and cumbersome. > > Are there devices you can wire into breaker box to meter each AC > circuit? > > Thanks in advance for any suggestions. > > -Jay > > We have a few of these running: http://www.emon.com/products_webmon.html > -Keith > > From ops.lists at gmail.com Mon Apr 12 10:47:08 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 12 Apr 2010 21:17:08 +0530 Subject: Carrier class email security recommendation In-Reply-To: <4BC33907.4060605@earthlink.net> References: <1271065747.2453.26.camel@akamiru> <4BC32988.5080606@earthlink.net> <1271081674.13545.125.camel@petrie> <4BC32BAA.5080601@earthlink.net> <4BC33907.4060605@earthlink.net> Message-ID: On Mon, Apr 12, 2010 at 8:45 PM, todd glassey wrote: > On 4/12/2010 7:22 AM, Suresh Ramasubramanian wrote: >> The man did say "carrier class" .. not "small webhost for four >> families and dog". > > yes he did Suresh ... meaning that something larger and more secure than > the off-the-shelf copy of Linux is needed. Funny the NSA and many others > would disagree with you. I know of (and have been the postmaster for) multiple million user installations that run happily on linux + postfix (and sendmail, qmail..). None that run on one server running webmin, even a 3U server. > or layered as stages within a new system design based on GPU's which > allow for the specific assignment of threads of control to specific > processes. Imaging a cloud type environment running in a single GPU with > the abililty to properly map threads to GPU threads. You don't have "single" of anything at all for large and well scaled environments. > OK our server is 3U but that was because I wanted bigger fans inside > it... The 1U single TESLA based email GW is exactly what you describe - > a 512 thread CUDA based GPU with serious capabilities therein. So how many users do you run on that one 3U box? 100K? 300K? A couple of million? :) The man said carrier class. And when you talk that you dont just talk features, you talk operations on a rather larger scale than what you're describing. --srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From zaid at zaidali.com Mon Apr 12 10:59:53 2010 From: zaid at zaidali.com (Zaid Ali) Date: Mon, 12 Apr 2010 08:59:53 -0700 Subject: Carrier class email security recommendation In-Reply-To: Message-ID: I haven't seen the man ask support for messages/hour, 3M..10M..1B ? Or maybe I missed this question? Zaid On 4/12/10 8:47 AM, "Suresh Ramasubramanian" wrote: > On Mon, Apr 12, 2010 at 8:45 PM, todd glassey wrote: >> On 4/12/2010 7:22 AM, Suresh Ramasubramanian wrote: >>> The man did say "carrier class" .. not "small webhost for four >>> families and dog". >> >> yes he did Suresh ... meaning that something larger and more secure than >> the off-the-shelf copy of Linux is needed. Funny the NSA and many others >> would disagree with you. > > I know of (and have been the postmaster for) multiple million user > installations that run happily on linux + postfix (and sendmail, > qmail..). > > None that run on one server running webmin, even a 3U server. > >> or layered as stages within a new system design based on GPU's which >> allow for the specific assignment of threads of control to specific >> processes. Imaging a cloud type environment running in a single GPU with >> the abililty to properly map threads to GPU threads. > > You don't have "single" of anything at all for large and well scaled > environments. > >> OK our server is 3U but that was because I wanted bigger fans inside >> it... The 1U single TESLA based email GW is exactly what you describe - >> a 512 thread CUDA based GPU with serious capabilities therein. > > So how many users do you run on that one 3U box? 100K? 300K? A > couple of million? :) > > The man said carrier class. And when you talk that you dont just talk > features, you talk operations on a rather larger scale than what > you're describing. > > --srs From ops.lists at gmail.com Mon Apr 12 11:06:28 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 12 Apr 2010 21:36:28 +0530 Subject: Carrier class email security recommendation In-Reply-To: References: Message-ID: Its nanog and not an RFQ process or I'd have asked him that too :) On Mon, Apr 12, 2010 at 9:29 PM, Zaid Ali wrote: > I haven't seen the man ask support for messages/hour, 3M..10M..1B ? Or maybe > I missed this question? -- Suresh Ramasubramanian (ops.lists at gmail.com) From jgreco at ns.sol.net Mon Apr 12 11:07:09 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 12 Apr 2010 11:07:09 -0500 (CDT) Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4C3EFA25-69C2-47B9-8976-8AD329BE7C2D@arin.net> from "John Curran" at Apr 12, 2010 11:23:16 AM Message-ID: <201004121607.o3CG79xA009846@aurora.sol.net> > On Apr 12, 2010, at 8:51 AM, Joe Greco wrote: > > Further, given the purported role that InterNIC played, "exchange of > > value" as a prerequisite is a rather questionable position to rely on; > > InterNIC had motivations other than a purely financial one to organize > > IP allocations. The number assignment function is critical to allowing > > the Internet to work smoothly. > > Joe - > > On this matter we do agree, since allocations prior to ARIN's formation were > generally made pursuant to a US Government contract or cooperative agreement. > While I don't consider addresses to be property, if you take the opposite view > then there's very likely a significant body of procurement law which already > applies to property furnished in this manner and would be far more relevant > than any documentation that an address block recipient received at the time.. There are all manner of theories. Some have compared it to physical land (possibly apt due to the limited nature of both), or to the way land was granted to the railroads to spur development, etc. Spinning the issue in any of several different ways could land you at wildly differing results. I'll bet that significant bodies of relevant law for each are contradictory and confusing at best. :-) Anyways, my original intent was simply to point out that there are some impediments to IPv6 adoption, somehow this morphed into a larger topic than intended. ... 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 bill at herrin.us Mon Apr 12 11:10:17 2010 From: bill at herrin.us (William Herrin) Date: Mon, 12 Apr 2010 12:10:17 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4C3EFA25-69C2-47B9-8976-8AD329BE7C2D@arin.net> References: <201004121251.o3CCpP9P001633@aurora.sol.net> <4C3EFA25-69C2-47B9-8976-8AD329BE7C2D@arin.net> Message-ID: On Mon, Apr 12, 2010 at 11:23 AM, John Curran wrote: > On Apr 12, 2010, at 8:51 AM, Joe Greco wrote: >> Further, given the purported role that InterNIC played, "exchange of >> value" as a prerequisite is a rather questionable position to rely on; >> InterNIC had motivations other than a purely financial one to organize >> IP allocations. ?The number assignment function is critical to allowing >> the Internet to work smoothly. > > On this matter we do agree, since allocations prior to ARIN's formation were > generally made pursuant to a US Government contract or cooperative agreement. > While I don't consider addresses to be property, if you take the opposite view > then there's very likely a significant body of procurement law which already > applies to property furnished in this manner and would be far more relevant > than any documentation that an address block recipient received at the time. John, Joe: If you want to understand the general thinking circa 1993, find a copy of the first edition, third printing of the crab book (TCP/IP Network Administration, O'Reilly) and read chapter 4. That was the reference many of us followed when getting our first address blocks. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From zaid at zaidali.com Mon Apr 12 11:17:38 2010 From: zaid at zaidali.com (Zaid Ali) Date: Mon, 12 Apr 2010 09:17:38 -0700 Subject: Carrier class email security recommendation In-Reply-To: Message-ID: I think it is a perfectly reasonable question to ask in NANOG. If someone asks how much memory do I need on my router to do BGP, you have to ask the fundamental question of how big your routing table will be. I don't see this as any different. Its helpful to provide opinions when you are guided by some data :) Zaid On 4/12/10 9:06 AM, "Suresh Ramasubramanian" wrote: > Its nanog and not an RFQ process or I'd have asked him that too :) > > On Mon, Apr 12, 2010 at 9:29 PM, Zaid Ali wrote: >> I haven't seen the man ask support for messages/hour, 3M..10M..1B ? Or maybe >> I missed this question? > > From ops.lists at gmail.com Mon Apr 12 11:21:57 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 12 Apr 2010 21:51:57 +0530 Subject: Carrier class email security recommendation In-Reply-To: References: Message-ID: I did ask him how many users he was looking to size email for. But a lot of questions like, and beyond, that - you may or may not want to answer on nanog. The man said carrier class .. and you have a set of assumptions. If you say enterprise you're assuming like 300K..400K mailboxes for the very largest enterprises. Tops. That'd be a small to mid sized carrier to spec carrier class for. I'll end this thread here. On Mon, Apr 12, 2010 at 9:47 PM, Zaid Ali wrote: > I think it is a perfectly reasonable question to ask in NANOG. If someone > asks how much memory do I need on my router to do BGP, you have to ask the > fundamental question of how big your routing table will be. I don't see this > as any different. Its helpful to provide opinions when you are guided by > some data :) > -- Suresh Ramasubramanian (ops.lists at gmail.com) From joelja at bogus.com Mon Apr 12 11:21:45 2010 From: joelja at bogus.com (joel jaeggli) Date: Mon, 12 Apr 2010 12:21:45 -0400 Subject: Carrier class email security recommendation In-Reply-To: References: <1271065747.2453.26.camel@akamiru> <4BC32988.5080606@earthlink.net> <1271081674.13545.125.camel@petrie> <4BC32BAA.5080601@earthlink.net> Message-ID: <4BC34899.8050000@bogus.com> On 4/12/2010 10:22 AM, Suresh Ramasubramanian wrote: > The man did say "carrier class" .. not "small webhost for four > families and dog". You're talking multiple mailservers + filtering > gateways / appliances etc, clustered .. rather tough to do that with > one pizzabox 1U running a linux that's not updated in years and > configured with webmin. I build basically the same mail-system where is collapsed into a single box or spread out across a cluster. sendmail + clamav milter + milter graylist -> procmail -> spamd -> maildir delivery -> dovecot imap. When you need to scale the front end you deploy a load balancer and fire up more smtp boxes... When you need to scale the filestore you move it to nfs and divide and conquer. When you need to scale imap you shift it in front of the load balancer and deploy more boxes. For load balancer we used LVS back in the day. can replace sendmail with postfix or exim, it's mostly a place to hang the various on-connect filter regimes. > And have you used / deployed any of those devices to claim they don't > support NTP? Or whether that's a bigger constraint than an > underpowered linux box? :) > > On Mon, Apr 12, 2010 at 7:48 PM, todd glassey wrote: >> Yes William, but realize that was an "easiest method" solution. There >> are any number of others as well. >> >> The point is that integrating an appliance type functionality is pretty >> easy if you bother to take the time. >> >> What I really wanted to point out is how many of the devices dont allow >> authenticated NTP meaning they are worthless from an evidence >> perspective, something that we as network engineers are constrained by >> as well. > > > From ops.lists at gmail.com Mon Apr 12 11:28:16 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 12 Apr 2010 21:58:16 +0530 Subject: Carrier class email security recommendation In-Reply-To: <4BC34899.8050000@bogus.com> References: <1271065747.2453.26.camel@akamiru> <4BC32988.5080606@earthlink.net> <1271081674.13545.125.camel@petrie> <4BC32BAA.5080601@earthlink.net> <4BC34899.8050000@bogus.com> Message-ID: Scale it all. Then manage it centrally. Provision users. Manage security. etc etc. You use much the same IOS whether you run a router for a T1 or run networks for a tier 1 :) On Mon, Apr 12, 2010 at 9:51 PM, joel jaeggli wrote: > > I build basically the same mail-system where is collapsed into a single box > or spread out across a cluster. > > sendmail + clamav milter + milter graylist -> procmail -> spamd -> maildir > delivery -> dovecot imap. > > When you need to scale the front end you deploy a load balancer and fire up > more smtp boxes... > > When you need to scale the filestore you move it to nfs and divide and > conquer. > > When you need to scale imap you shift it in front of the load balancer and > deploy more boxes. > > For load balancer we used LVS back in the day. > > can replace sendmail with postfix or exim, it's mostly a place to hang the > various on-connect filter regimes. -- Suresh Ramasubramanian (ops.lists at gmail.com) From egon at egon.cc Mon Apr 12 11:44:05 2010 From: egon at egon.cc (James Downs) Date: Mon, 12 Apr 2010 09:44:05 -0700 Subject: Solar Flux In-Reply-To: <4BC31413.5080307@earthlink.net> References: <4BC20126.30808@opus1.com> <4BC31413.5080307@earthlink.net> Message-ID: <11A583C1-5ACD-49F8-80EC-9C72532CAB2D@egon.cc> On Apr 12, 2010, at 5:37 AM, todd glassey wrote: > Barbie is "geek girl" or "Engineer Barbie" the idea that being a > geek is > offensive may have finally been put to death as it should have 20 > years ago. Of course, Joel used the word "nerd", so.. So, does anyone actually talk about networks on nanog anymore? -j From erik_list at caneris.com Mon Apr 12 11:51:30 2010 From: erik_list at caneris.com (Erik L) Date: Mon, 12 Apr 2010 12:51:30 -0400 Subject: Seeking Amazon EC2 abuse contact In-Reply-To: <02a601cada45$91aa34d0$b4fe9e70$@nl> References: , <1271063763.6107.3179.camel@mike-desktop> , <02a601cada45$91aa34d0$b4fe9e70$@nl> Message-ID: Many thanks again to the large number of off-list responses. After making human contact, the issue was very promptly resolved by Amazon and a gentleman there has promised to look into the error on the abuse form as well. Erik ________________________________________ From: Mark Scholten [mark at streamservice.nl] Sent: Monday, April 12, 2010 9:39 AM To: Erik L; 'Michael J McCafferty' Cc: nanog at nanog.org Subject: RE: Seeking Amazon EC2 abuse contact Hello Erik, Do you care to share the IP address? So everyone could update their firewalls to block the attacks? Even only blocking known SIP ports (5060) could be a good idea. With kind regards, Mark Scholten > -----Original Message----- > From: Erik L [mailto:erik_list at caneris.com] > Sent: Monday, April 12, 2010 3:05 PM > To: Michael J McCafferty > Cc: nanog at nanog.org > Subject: RE: Seeking Amazon EC2 abuse contact > > Michael, > > I've received numerous off-list responses yesterday. Most of them were > asking if I've made contact with anyone there as they were being > attacked as well. One gentleman who works at AWS (but not EC2 abuse) > promised to forward my e-mail to them. I've also been reading the > asterisk-users list where many have reported attacks from Amazon EC2 as > well over the past few days. > > At one point we were seeing 197 SIP brute force attempts per second > against a customer's box. The intensity in terms of bandwidth is low, > but if you do the math, you can see that this isn't the point. > > This morning I received an e-mail from Amazon which was basically the > same as the one you received. The attack is still on-going and I've > still not made contact with a human at Amazon. > > Erik > > > > > -----Original Message----- > > From: Michael J McCafferty [mailto:mike at m5computersecurity.com] > > Sent: April 12, 2010 05:16 > > To: Erik L > > Cc: nanog at nanog.org > > Subject: Re: Seeking Amazon EC2 abuse contact > > > > Erik, > > We have several customers being attacked from the same > > EC2 instance on > > their network for 2 full days now. Contacted them at > > ec2-abuse at amazon.com and 25 hours later received a message that > > basically said, "Yep, we can confirm that a customer of ours is > > attacking you but that's their fault. We sometimes do stuff, > > but not in > > this case. Please don't block us, because the IP might be someone > else > > later. Have a nice day". > > The telephone number in the WHOIS record goes to a > > general voicemail > > box for their legal department. > > A few of our customers who are being attacked by this > > same instance at > > EC2 have also contacted Amazon, and were told essentially the same > > thing. > > While I appreciate that they sent a response, I do not > > appreciate it's > > uselessness. > > Anyone over there at AWS that can do something willing > > to reply to me > > directly? > > > > Thanks! > > Mike > > > > > > On Sun, 2010-04-11 at 10:38 -0400, Erik L wrote: > > > Could someone from Amazon EC2 please contact me off-list > > regarding an abuse issue from one of their IPs? > > Alternatively, could someone please send me the contact > > details of someone there? > > > > > > E-mailing the abuse e-mail listed in WHOIS per their > > instructions, including all pertinent data, results in an > > auto-reply indicating to use a form on their site. Submitting > > the form results in "There has been an error while submitting > > your data. Please try again later." Calling their supposed > > NOC (as per WHOIS) results in "You have reached the legal > > department at Amazon...please leave a message". > > > > > > Thanks > > > > > -- > > ************************************************************ > > 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 LarrySheldon at cox.net Mon Apr 12 12:14:39 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 12 Apr 2010 12:14:39 -0500 Subject: Seeking Amazon EC2 abuse contact In-Reply-To: References: , <1271063763.6107.3179.camel@mike-desktop> , <02a601cada45$91aa34d0$b4fe9e70$@nl> Message-ID: <4BC354FF.9080106@cox.net> On 4/12/2010 11:51, Erik L wrote: > Many thanks again to the large number of off-list responses. After > making human contact, the issue was very promptly resolved by Amazon > and a gentleman there has promised to look into the error on the > abuse form as well. And people say talk of routing their traffic to 600-ohm resistors doesn't do any good. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From jnegro at billtrust.com Mon Apr 12 12:28:45 2010 From: jnegro at billtrust.com (Jeffrey Negro) Date: Mon, 12 Apr 2010 13:28:45 -0400 Subject: Router for Metro Ethernet Message-ID: Before I get taken for a ride by salespeople, I figured it would be best to ask the experts of Nanog.... My company is currently in talks to bring an ethernet circuit into our headquarters, initially committing around 40Mbps. The ISP will be providing ethernet handoff, but I do not want their managed router offering (Adtran 4430) since it is pricey, non-redundant and I'd rather manage it myself. My question is about hardware. Can I assume that I can use something like a Cisco 2000 series router with two built in fast/gig ethernet ports, without a WIC? and since both sides are ethernet would the routing throughput be near fast ethernet speed? This is my first dealing with metro ethernet offerings, and I don't want to assume that the Cisco throughput rates listed for T1/ADSL etc. are the same for a metro ethernet as the WAN. Any and all suggestions on the hardware would be greatly appreciated. Thank you in advance! From dmburgess at linktechs.net Mon Apr 12 12:32:57 2010 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 12 Apr 2010 12:32:57 -0500 Subject: Router for Metro Ethernet References: Message-ID: <91522911795E174F97E7EF8B792A1031228980@ltiserver.LTI.local> a PowerRouter at http://www.mikrotikrouter.com can handle several hundred meg without issues. ----------------------------------------------------------- Dennis Burgess, CCNA, Mikrotik Certified Trainer, MTCNA, MTCRE, MTCWE, MTCTCE, MTCUME Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" -----Original Message----- From: Jeffrey Negro [mailto:jnegro at billtrust.com] Sent: Monday, April 12, 2010 12:29 PM To: nanog at nanog.org Subject: Router for Metro Ethernet Before I get taken for a ride by salespeople, I figured it would be best to ask the experts of Nanog.... My company is currently in talks to bring an ethernet circuit into our headquarters, initially committing around 40Mbps. The ISP will be providing ethernet handoff, but I do not want their managed router offering (Adtran 4430) since it is pricey, non-redundant and I'd rather manage it myself. My question is about hardware. Can I assume that I can use something like a Cisco 2000 series router with two built in fast/gig ethernet ports, without a WIC? and since both sides are ethernet would the routing throughput be near fast ethernet speed? This is my first dealing with metro ethernet offerings, and I don't want to assume that the Cisco throughput rates listed for T1/ADSL etc. are the same for a metro ethernet as the WAN. Any and all suggestions on the hardware would be greatly appreciated. Thank you in advance! From Jay.Murphy at state.nm.us Mon Apr 12 12:53:46 2010 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Mon, 12 Apr 2010 11:53:46 -0600 Subject: Router for Metro Ethernet In-Reply-To: References: Message-ID: Jeffrey, We have deployed metro Ethernet in our network... some things to consider: 1) Is metro Ethernet available end to end, if not will you utilize MPLS? 2) We've deployed Juniper EX3200s, Cisco has great solutions as well... for example 2800 series router. We use Cisco as well. 3) Metro Ethernet is available in increments up to 1G, aka 1000Mbs, so I would explore cost solutions for scalability and future proofing. 4) Benchmark tests revealed near wire speed... however, this is contingent upon region, carrier, provider, locale, etc. 5) It's quick. We use it and it works! Hope this sheds some light. ~Jay Murphy IP Network Specialist NM State Government IT Services Division PSB ? IP Network Management Center Santa F?, New M?xico 87505 "We move the information that moves your world." ?Good engineering demands that we understand what we?re doing and why, keep an open mind, and learn from experience.? ?Engineering is about finding the sweet spot between what's solvable and what isn't." Radia Perlman ? Please consider the environment before printing e-mail -----Original Message----- From: Jeffrey Negro [mailto:jnegro at billtrust.com] Sent: Monday, April 12, 2010 11:29 AM To: nanog at nanog.org Subject: Router for Metro Ethernet Before I get taken for a ride by salespeople, I figured it would be best to ask the experts of Nanog.... My company is currently in talks to bring an ethernet circuit into our headquarters, initially committing around 40Mbps. The ISP will be providing ethernet handoff, but I do not want their managed router offering (Adtran 4430) since it is pricey, non-redundant and I'd rather manage it myself. My question is about hardware. Can I assume that I can use something like a Cisco 2000 series router with two built in fast/gig ethernet ports, without a WIC? and since both sides are ethernet would the routing throughput be near fast ethernet speed? This is my first dealing with metro ethernet offerings, and I don't want to assume that the Cisco throughput rates listed for T1/ADSL etc. are the same for a metro ethernet as the WAN. Any and all suggestions on the hardware would be greatly appreciated. Thank you in advance! Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From dylan.ebner at crlmed.com Mon Apr 12 12:55:29 2010 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Mon, 12 Apr 2010 17:55:29 +0000 Subject: Router for Metro Ethernet In-Reply-To: References: Message-ID: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> We use metro E for our WAN and our internet access delivery. The 2600 series routers do not have enough horsepower to do a 40 Mb connection and eigrp. The 2811 can do 40 mb and eigrp but they start to have difficulty when you add in inspection or large ACLs. We just last week turned a 40mb metroe circuit into a 60mb and the router, a 2811, is now have constant problems. We are replacing it with a 2921. However, this router also has 2 100mb connections from local lans that it is also terminiating. For our 100mb metro e connections we use 3845s. The 100 mb service terminates into NM-GEs, which have a faster throughput than the hwics. This setup works well. On our internet edges we use 2811s with their memory maxed. We have partial BGP routers from 2 isps. One connection is a 30mb and the other is a 25mb. no inspection is done on these but we do have stateless acls running on the inbound. these are running just fine today, but they sit at about 20% cpu all the time. When doing a metro e connection, make sure the router/switch can do traffic shaping. If it can't, you are relying on the provider to shape your outgoing traffic, which of course will happen down the line, adding additional delay during high usage times. You should also look at the new cisco small metro switches. They can traffic shape, do bgp and have more than one interface. one of the annoying thing about metro e(at least with qwest) is they have a tendancy to install new pe switches at your locations when you upgrade your service. this means a new connection from them and unless you have extra fiber or copper ports on your router. So to transition to the new circuit, you need to unplug your existing service first. And that means downtime, which no one likes. Dylan -----Original Message----- From: Jeffrey Negro [mailto:jnegro at billtrust.com] Sent: Monday, April 12, 2010 12:29 PM To: nanog at nanog.org Subject: Router for Metro Ethernet Before I get taken for a ride by salespeople, I figured it would be best to ask the experts of Nanog.... My company is currently in talks to bring an ethernet circuit into our headquarters, initially committing around 40Mbps. The ISP will be providing ethernet handoff, but I do not want their managed router offering (Adtran 4430) since it is pricey, non-redundant and I'd rather manage it myself. My question is about hardware. Can I assume that I can use something like a Cisco 2000 series router with two built in fast/gig ethernet ports, without a WIC? and since both sides are ethernet would the routing throughput be near fast ethernet speed? This is my first dealing with metro ethernet offerings, and I don't want to assume that the Cisco throughput rates listed for T1/ADSL etc. are the same for a metro ethernet as the WAN. Any and all suggestions on the hardware would be greatly appreciated. Thank you in advance! From cjp at 0x1.net Mon Apr 12 13:25:40 2010 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Mon, 12 Apr 2010 14:25:40 -0400 Subject: Router for Metro Ethernet In-Reply-To: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> References: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> Message-ID: <20100412182540.GF17196@0x1.net> On Mon, Apr 12, 2010 at 05:55:29PM +0000, Dylan Ebner wrote: > also terminiating. For our 100mb metro e connections we use > 3845s. The 100 mb service terminates into NM-GEs, which have a FWIW, we made the mistake of going for 3825s on a 50Mb/s policed GigE. Running GRE/IPSec (AIM-VPN'd) and QoS, the boxes go to 100% CPU in the vicinity of 40Mb/s. -cjp From jnegro at billtrust.com Mon Apr 12 13:26:21 2010 From: jnegro at billtrust.com (Jeffrey Negro) Date: Mon, 12 Apr 2010 14:26:21 -0400 Subject: Router for Metro Ethernet In-Reply-To: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> References: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> Message-ID: In our case I believe we would be dealing with just static routes and a lines of ACL. Do you think the routing protocols are your largest resource usage in your scenario, or is it also just simple routing as well? Jeffrey Negro, Network Engineer Billtrust - Improving Your Billing, Improving Your Business www.billtrust.com 609.235.1010 x137 On Mon, Apr 12, 2010 at 1:55 PM, Dylan Ebner wrote: > We use metro E for our WAN and our internet access delivery. The 2600 > series routers do not have enough horsepower to do a 40 Mb connection and > eigrp. The 2811 can do 40 mb and eigrp but they start to have difficulty > when you add in inspection or large ACLs. We just last week turned a 40mb > metroe circuit into a 60mb and the router, a 2811, is now have constant > problems. We are replacing it with a 2921. However, this router also has 2 > 100mb connections from local lans that it is also terminiating. For our > 100mb metro e connections we use 3845s. The 100 mb service terminates into > NM-GEs, which have a faster throughput than the hwics. This setup works > well. > On our internet edges we use 2811s with their memory maxed. We have partial > BGP routers from 2 isps. One connection is a 30mb and the other is a 25mb. > no inspection is done on these but we do have stateless acls running on the > inbound. these are running just fine today, but they sit at about 20% cpu > all the time. > When doing a metro e connection, make sure the router/switch can do traffic > shaping. If it can't, you are relying on the provider to shape your outgoing > traffic, which of course will happen down the line, adding additional delay > during high usage times. > > You should also look at the new cisco small metro switches. They can > traffic shape, do bgp and have more than one interface. one of the annoying > thing about metro e(at least with qwest) is they have a tendancy to install > new pe switches at your locations when you upgrade your service. this means > a new connection from them and unless you have extra fiber or copper ports > on your router. So to transition to the new circuit, you need to unplug your > existing service first. And that means downtime, which no one likes. > > > > Dylan > > > -----Original Message----- > From: Jeffrey Negro [mailto:jnegro at billtrust.com] > Sent: Monday, April 12, 2010 12:29 PM > To: nanog at nanog.org > Subject: Router for Metro Ethernet > > Before I get taken for a ride by salespeople, I figured it would be best to > ask the experts of Nanog.... > > My company is currently in talks to bring an ethernet circuit into our > headquarters, initially committing around 40Mbps. The ISP will be > providing > ethernet handoff, but I do not want their managed router offering (Adtran > 4430) since it is pricey, non-redundant and I'd rather manage it myself. > My > question is about hardware. Can I assume that I can use something like a > Cisco 2000 series router with two built in fast/gig ethernet ports, without > a WIC? and since both sides are ethernet would the routing throughput be > near fast ethernet speed? This is my first dealing with metro ethernet > offerings, and I don't want to assume that the Cisco throughput rates > listed > for T1/ADSL etc. are the same for a metro ethernet as the WAN. > > Any and all suggestions on the hardware would be greatly appreciated. > Thank > you in advance! > From nonobvious at gmail.com Mon Apr 12 13:27:14 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Mon, 12 Apr 2010 11:27:14 -0700 Subject: Router for Metro Ethernet In-Reply-To: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> References: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> Message-ID: On Mon, Apr 12, 2010 at 10:55 AM, Dylan Ebner wrote: > However, this router also has 2 100mb connections from local lans that it is also terminiating. > For our 100mb metro e connections we use 3845s. The 100 mb service terminates into NM-GEs, which have a faster throughput than the hwics. Be careful using 3845s for 100 Mbps connections or above - Cisco rates them at 45 Mbps (and 3825 at half of that) but last time I checked doesn't make any promises at faster than T3. They're being conservative about it, but one thing that really can burn the horsepower is traffic shaping, which you need with some MetroE carriers. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From kloch at kl.net Mon Apr 12 13:31:42 2010 From: kloch at kl.net (Kevin Loch) Date: Mon, 12 Apr 2010 14:31:42 -0400 Subject: Router for Metro Ethernet In-Reply-To: References: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> Message-ID: <4BC3670E.7040706@kl.net> Jeffrey Negro wrote: > In our case I believe we would be dealing with just static routes and a > lines of ACL. In that case a linux/FreeBSD router would work great. - Kevin From drc at virtualized.org Mon Apr 12 13:36:45 2010 From: drc at virtualized.org (David Conrad) Date: Mon, 12 Apr 2010 08:36:45 -1000 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <4C3EFA25-69C2-47B9-8976-8AD329BE7C2D@arin.net> References: <201004121251.o3CCpP9P001633@aurora.sol.net> <4C3EFA25-69C2-47B9-8976-8AD329BE7C2D@arin.net> Message-ID: <9A24C4A5-8A6D-4512-B1EA-6F9F247F486D@virtualized.org> John, On Apr 12, 2010, at 5:23 AM, John Curran wrote: > On this matter we do agree, since allocations prior to ARIN's formation were > generally made pursuant to a US Government contract or cooperative agreement. As we're both aware, Jon was funded in part via the ISI Teranode Network Technologies project. Folks who were directly involved have told me that IANA-related activities weren't even identified in the original contracts until the mid- to late-90s (around the time when lawsuits were being thrown at Jon because of the domain name wars -- odd coincidence, that) when the IANA activities were codified as "Task 4". IANAL, but it seems a bit of a stretch to me for ARIN to assert policy control over resources allocated prior to ARIN's existence without any sort of documentation that explicitly lists that policy control in ARIN's predecessor (ever). Like I said, it'll be an interesting court case. Regards, -drc From richard at bennett.com Mon Apr 12 13:42:49 2010 From: richard at bennett.com (Richard Bennett) Date: Mon, 12 Apr 2010 11:42:49 -0700 Subject: FCC dealt major blow in net neutrality ruling favoring, Comcast In-Reply-To: References: <4BC0F119.2030802@bennett.com> Message-ID: <4BC369A9.3060805@bennett.com> One of the things I like about e-mail lists is learning things about myself that I never knew before, especially regarding my occupation. For the last 9 months or so I've been working part-time with a Washington think tank in an analyst capacity, not as a lobbyist, and not on the Comcast payroll. My views about Internet regulation precede this job and haven't been altered by it. For purposes of the present discussion, I'd rather be known as the guy who wrote the first IEEE 802 standard for Ethernet over twisted pair, or designed the Wi-Fi MAC protocol, or the DRP for UWB, or something like that. As Suresh notes, the idea that the FCC overstepped its bounds in the Comcast order is hardly controversial. It's not even a matter of opinion any more, as the decision written by the most liberal judge on the 3rd Circuit, David Tatel, means it's the law. The debate about how to regulate the Internet is now premised on the fact that the old rationale doesn't hold up to scrutiny, so deal with it. RB On 4/11/2010 11:23 PM, Suresh Ramasubramanian wrote: > On Mon, Apr 12, 2010 at 11:41 AM, Paul WALL wrote: > >> It should probably be noted, for purpose of establishing bias, that >> Richard is a Washington lobbyist, hired to represent Comcast on >> regulatory matters. What he views as overstepping legal bounds, >> others may view as protecting consumers... >> > Hell, funnily enough Susan Crawford warned at the time that the FCC > action wouldn't stand up in court the way it was done. > > http://www.circleid.com/posts/comcast_vs_the_fcc_a_reply_to_susan_crawfords_article/ > > --srs > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From brunner at nic-naa.net Mon Apr 12 13:50:18 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 12 Apr 2010 14:50:18 -0400 Subject: FCC dealt major blow in net neutrality ruling favoring, Comcast In-Reply-To: <4BC369A9.3060805@bennett.com> References: <4BC0F119.2030802@bennett.com> <4BC369A9.3060805@bennett.com> Message-ID: <4BC36B6A.4050909@nic-naa.net> On 4/12/10 2:42 PM, Richard Bennett wrote: > ... the guy who wrote the first IEEE 802 standard for > Ethernet over twisted pair ... I'm certain that's who you are. Hell, what I do for CORE means I'm a ICANN lobbyist when I'm not writing code, and I'd prefer to be the guy who wrote XPG/1 and XPG/4.2 (Single Unix Specification to those on Redmond shared fate devices). Eric From jasongurtz at npumail.com Mon Apr 12 13:54:10 2010 From: jasongurtz at npumail.com (Jason Gurtz) Date: Mon, 12 Apr 2010 14:54:10 -0400 Subject: Router for Metro Ethernet In-Reply-To: References: Message-ID: > question is about hardware. Can I assume that I can use something like a > Cisco 2000 series router with two built in fast/gig ethernet ports, > without a WIC? For Cisco, check out the ME3400 series of switches. Be sure to look at the IOS licensing carefully to see if the features you need are there. ~JasonG -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5103 bytes Desc: not available URL: From james at freedomnet.co.nz Mon Apr 12 13:54:59 2010 From: james at freedomnet.co.nz (James Jones) Date: Mon, 12 Apr 2010 14:54:59 -0400 Subject: Mikrotik RouterOS Message-ID: <4BC36C83.7040200@freedomnet.co.nz> I am currently looking at using RouterOS as a way to build a Metro Ethernet solution. Does anyone have experience with the device and the OS? How is the performance? Are there any "Gotchas"? -James From dylan.ebner at crlmed.com Mon Apr 12 13:58:32 2010 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Mon, 12 Apr 2010 18:58:32 +0000 Subject: Router for Metro Ethernet In-Reply-To: References: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> Message-ID: <017265BF3B9640499754DD48777C3D20685A19F24E@MBX9.EXCHPROD.USA.NET> Taffic shaping and eigrp eat a lot. inspection is huge as well. I have no ida what the new zone based firewalling will do to a 2800, but after seeing it on an 1800, I know it will not be pretty. static acls should be easy if they are not really large. I wouldn't go out and grab the new CRYMU bogon list, that would kill you. The problem is the router CAN do these things, but if you want any management on the back end you get in trouble. things like NBAR and netflow are incredibly important, but the router cannot handle all these services and the routing protocols and the traffic. If you are not doing nbar or netflow today, that doesn't mean you won't in the near future. I have been finding that getting a router that is too small puts you in a precarious position at times. You can either know where your traffic is going and have a router that drops packets, or you can run blind knowing that all those unmonitored packets are getting through. Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. 612.573.2250 dylan.ebner at crlmed.com www.consultingradiologists.com From: Jeffrey Negro [mailto:jnegro at billtrust.com] Sent: Monday, April 12, 2010 1:26 PM To: Dylan Ebner Cc: nanog at nanog.org Subject: Re: Router for Metro Ethernet In our case I believe we would be dealing with just static routes and a lines of ACL. Do you think the routing protocols are your largest resource usage in your scenario, or is it also just simple routing as well? Jeffrey Negro, Network Engineer Billtrust - Improving Your Billing, Improving Your Business www.billtrust.com 609.235.1010 x137 On Mon, Apr 12, 2010 at 1:55 PM, Dylan Ebner > wrote: We use metro E for our WAN and our internet access delivery. The 2600 series routers do not have enough horsepower to do a 40 Mb connection and eigrp. The 2811 can do 40 mb and eigrp but they start to have difficulty when you add in inspection or large ACLs. We just last week turned a 40mb metroe circuit into a 60mb and the router, a 2811, is now have constant problems. We are replacing it with a 2921. However, this router also has 2 100mb connections from local lans that it is also terminiating. For our 100mb metro e connections we use 3845s. The 100 mb service terminates into NM-GEs, which have a faster throughput than the hwics. This setup works well. On our internet edges we use 2811s with their memory maxed. We have partial BGP routers from 2 isps. One connection is a 30mb and the other is a 25mb. no inspection is done on these but we do have stateless acls running on the inbound. these are running just fine today, but they sit at about 20% cpu all the time. When doing a metro e connection, make sure the router/switch can do traffic shaping. If it can't, you are relying on the provider to shape your outgoing traffic, which of course will happen down the line, adding additional delay during high usage times. You should also look at the new cisco small metro switches. They can traffic shape, do bgp and have more than one interface. one of the annoying thing about metro e(at least with qwest) is they have a tendancy to install new pe switches at your locations when you upgrade your service. this means a new connection from them and unless you have extra fiber or copper ports on your router. So to transition to the new circuit, you need to unplug your existing service first. And that means downtime, which no one likes. Dylan -----Original Message----- From: Jeffrey Negro [mailto:jnegro at billtrust.com] Sent: Monday, April 12, 2010 12:29 PM To: nanog at nanog.org Subject: Router for Metro Ethernet Before I get taken for a ride by salespeople, I figured it would be best to ask the experts of Nanog.... My company is currently in talks to bring an ethernet circuit into our headquarters, initially committing around 40Mbps. The ISP will be providing ethernet handoff, but I do not want their managed router offering (Adtran 4430) since it is pricey, non-redundant and I'd rather manage it myself. My question is about hardware. Can I assume that I can use something like a Cisco 2000 series router with two built in fast/gig ethernet ports, without a WIC? and since both sides are ethernet would the routing throughput be near fast ethernet speed? This is my first dealing with metro ethernet offerings, and I don't want to assume that the Cisco throughput rates listed for T1/ADSL etc. are the same for a metro ethernet as the WAN. Any and all suggestions on the hardware would be greatly appreciated. Thank you in advance! From pauldotwall at gmail.com Mon Apr 12 14:08:14 2010 From: pauldotwall at gmail.com (Paul WALL) Date: Mon, 12 Apr 2010 15:08:14 -0400 Subject: FCC dealt major blow in net neutrality ruling favoring, Comcast In-Reply-To: <4BC369A9.3060805@bennett.com> References: <4BC0F119.2030802@bennett.com> <4BC369A9.3060805@bennett.com> Message-ID: On Mon, Apr 12, 2010 at 2:42 PM, Richard Bennett wrote: > One of the things I like about e-mail lists is learning things about myself > that I never knew before, especially regarding my occupation. For the last 9 > months or so I've been working part-time with a Washington think tank in an > analyst capacity, not as a lobbyist, and not on the Comcast payroll. You neglected to mention that the "think tank" (where I'm from in Houston, we call them lobbys) is funded by Comcast, among other big cable/telecom players. Drive Slow, Paul Wall From jlewis at lewis.org Mon Apr 12 14:32:35 2010 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 12 Apr 2010 15:32:35 -0400 (EDT) Subject: Router for Metro Ethernet In-Reply-To: References: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> Message-ID: On Mon, 12 Apr 2010, Jeffrey Negro wrote: > In our case I believe we would be dealing with just static routes and a > lines of ACL. Do you think the routing protocols are your largest resource > usage in your scenario, or is it also just simple routing as well? If your needs are simple IP routing + simple ACL, but you want line rate ethernet, a layer 3 switch might make sense. -- ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From adrian.minta at gmail.com Mon Apr 12 14:01:59 2010 From: adrian.minta at gmail.com (Adrian Minta) Date: Mon, 12 Apr 2010 22:01:59 +0300 Subject: Mikrotik RouterOS In-Reply-To: <4BC36C83.7040200@freedomnet.co.nz> References: <4BC36C83.7040200@freedomnet.co.nz> Message-ID: <4BC36E27.4000005@gmail.com> James Jones wrote: > > I am currently looking at using RouterOS as a way to build a Metro > Ethernet solution. Does anyone have experience with the device and the > OS? How is the performance? Are there any "Gotchas"? > > > -James > > Be carefull not to crash the whole internet: http://www.renesys.com/blog/2009/02/longer-is-not-better.shtml From dga at cs.cmu.edu Mon Apr 12 14:36:02 2010 From: dga at cs.cmu.edu (David Andersen) Date: Mon, 12 Apr 2010 15:36:02 -0400 Subject: FCC dealt major blow in net neutrality ruling favoring, Comcast In-Reply-To: References: <4BC0F119.2030802@bennett.com> <4BC369A9.3060805@bennett.com> Message-ID: On Apr 12, 2010, at 3:08 PM, Paul WALL wrote: > On Mon, Apr 12, 2010 at 2:42 PM, Richard Bennett wrote: >> One of the things I like about e-mail lists is learning things about myself >> that I never knew before, especially regarding my occupation. For the last 9 >> months or so I've been working part-time with a Washington think tank in an >> analyst capacity, not as a lobbyist, and not on the Comcast payroll. > > You neglected to mention that the "think tank" (where I'm from in > Houston, we call them lobbys) is funded by Comcast, among other big > cable/telecom players. In fairness to to the ITIF (his current employer), they're well-respected in their core area, studying innovation policy. I've seen some of the work done by Rob Atkinson (full disclosure: Rob is currently visiting my university giving a talk), and it's good. That said, I dislike strongly Richard's M.O. of trying to stir up hornets nests by playing the fool/troll in order to get NANOG and other venues to do his job for him, and I hope this statement doesn't come across as a defense of that. I've already plonked him. -Dave From gustkiller at gmail.com Mon Apr 12 14:44:14 2010 From: gustkiller at gmail.com (Gustavo Santos) Date: Mon, 12 Apr 2010 16:44:14 -0300 Subject: Mikrotik RouterOS In-Reply-To: <4BC36E27.4000005@gmail.com> References: <4BC36C83.7040200@freedomnet.co.nz> <4BC36E27.4000005@gmail.com> Message-ID: its was an old bug, that had been fixed for a while.. 2010/4/12 Adrian Minta > James Jones wrote: > >> >> I am currently looking at using RouterOS as a way to build a Metro >> Ethernet solution. Does anyone have experience with the device and the >> OS? How is the performance? Are there any "Gotchas"? >> >> >> -James >> >> >> Be carefull not to crash the whole internet: > http://www.renesys.com/blog/2009/02/longer-is-not-better.shtml > > > > > -- Gustavo Santos Analista de Redes -Cisco Certified Network Associate -Juniper Certified Internet Associate - ER -Mikrotik Certified Consultant From dmburgess at linktechs.net Mon Apr 12 14:47:44 2010 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 12 Apr 2010 14:47:44 -0500 Subject: Mikrotik RouterOS References: <4BC36C83.7040200@freedomnet.co.nz> <4BC36E27.4000005@gmail.com> Message-ID: <91522911795E174F97E7EF8B792A1031228997@ltiserver.LTI.local> As it said, it was two fold, one the MT allowed it, and 2, the Cisco's crashed with it! ----------------------------------------------------------- Dennis Burgess, CCNA, Mikrotik Certified Trainer, MTCNA, MTCRE, MTCWE, MTCTCE, MTCUME Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" -----Original Message----- From: Gustavo Santos [mailto:gustkiller at gmail.com] Sent: Monday, April 12, 2010 2:44 PM To: Adrian Minta Cc: nanog at nanog.org Subject: Re: Mikrotik RouterOS its was an old bug, that had been fixed for a while.. 2010/4/12 Adrian Minta > James Jones wrote: > >> >> I am currently looking at using RouterOS as a way to build a Metro >> Ethernet solution. Does anyone have experience with the device and the >> OS? How is the performance? Are there any "Gotchas"? >> >> >> -James >> >> >> Be carefull not to crash the whole internet: > http://www.renesys.com/blog/2009/02/longer-is-not-better.shtml > > > > > -- Gustavo Santos Analista de Redes -Cisco Certified Network Associate -Juniper Certified Internet Associate - ER -Mikrotik Certified Consultant From Grzegorz at Janoszka.pl Mon Apr 12 14:48:56 2010 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Mon, 12 Apr 2010 21:48:56 +0200 Subject: Mikrotik RouterOS In-Reply-To: References: <4BC36C83.7040200@freedomnet.co.nz> <4BC36E27.4000005@gmail.com> Message-ID: <4BC37928.5030004@Janoszka.pl> On 12-4-2010 21:44, Gustavo Santos wrote: > its was an old bug, that had been fixed for a while.. You should still keep in mind Mikrotik is just Linux, with all its (dis)advantages, plus some scripts and weird CLI. -- Grzegorz Janoszka From dmburgess at linktechs.net Mon Apr 12 14:52:23 2010 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 12 Apr 2010 14:52:23 -0500 Subject: Mikrotik RouterOS References: <4BC36C83.7040200@freedomnet.co.nz> <4BC36E27.4000005@gmail.com> <4BC37928.5030004@Janoszka.pl> Message-ID: <91522911795E174F97E7EF8B792A1031228999@ltiserver.LTI.local> It runs the Linux kernal, bout it anymore! A few existing linux apps but super clean CLI, easy to use, awsome GUI. ;) Heck, the whole OS runs within 64meg of disk space if you wanted it too! ----------------------------------------------------------- Dennis Burgess, CCNA, Mikrotik Certified Trainer, MTCNA, MTCRE, MTCWE, MTCTCE, MTCUME Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" -----Original Message----- From: Grzegorz Janoszka [mailto:Grzegorz at Janoszka.pl] Sent: Monday, April 12, 2010 2:49 PM To: nanog list Subject: Re: Mikrotik RouterOS On 12-4-2010 21:44, Gustavo Santos wrote: > its was an old bug, that had been fixed for a while.. You should still keep in mind Mikrotik is just Linux, with all its (dis)advantages, plus some scripts and weird CLI. -- Grzegorz Janoszka From richard at bennett.com Mon Apr 12 15:05:43 2010 From: richard at bennett.com (Richard Bennett) Date: Mon, 12 Apr 2010 13:05:43 -0700 Subject: FCC dealt major blow in net neutrality ruling favoring, Comcast In-Reply-To: References: <4BC0F119.2030802@bennett.com> <4BC369A9.3060805@bennett.com> Message-ID: <4BC37D17.5010400@bennett.com> You're speculating that ITIF gets funding from Comcast, and therefore guessing I'm singing Comcast's song. But you don't know whether Comcast actually is an ITIF sponsor, just as you don't know whether Google, Intel, and Microsoft are ITIF sponsors. And then you're speculating again regarding the relationships between sponsors and fellows. Paul, it's obvious you don't know what you're talking about re: Internet regulation policy or the nature of DC think tanks, so why you you just STFU rather than embarrass yourself further? RB On 4/12/2010 12:08 PM, Paul WALL wrote: On Mon, Apr 12, 2010 at 2:42 PM, Richard Bennett [1] wrote: One of the things I like about e-mail lists is learning things about myself that I never knew before, especially regarding my occupation. For the last 9 months or so I've been working part-time with a Washington think tank in an analyst capacity, not as a lobbyist, and not on the Comcast payroll. You neglected to mention that the "think tank" (where I'm from in Houston, we call them lobbys) is funded by Comcast, among other big cable/telecom players. Drive Slow, Paul Wall -- References 1. mailto:richard at bennett.com From franck at genius.com Mon Apr 12 15:05:50 2010 From: franck at genius.com (Franck Martin) Date: Tue, 13 Apr 2010 08:05:50 +1200 (MAGST) Subject: Router for Metro Ethernet In-Reply-To: Message-ID: <30109649.393.1271102748626.JavaMail.franck@franck-martins-macbook-pro.local> http://www.vyatta.com/ ? From james at freedomnet.co.nz Mon Apr 12 15:06:45 2010 From: james at freedomnet.co.nz (James Jones) Date: Mon, 12 Apr 2010 16:06:45 -0400 Subject: Mikrotik RouterOS In-Reply-To: <4BC37928.5030004@Janoszka.pl> References: <4BC36C83.7040200@freedomnet.co.nz> <4BC36E27.4000005@gmail.com> <4BC37928.5030004@Janoszka.pl> Message-ID: <4BC37D55.6050806@freedomnet.co.nz> kind of....routerOS supports MPLS, linux does not On 4/12/10 3:48 PM, Grzegorz Janoszka wrote: > On 12-4-2010 21:44, Gustavo Santos wrote: >> its was an old bug, that had been fixed for a while.. > > You should still keep in mind Mikrotik is just Linux, with all its > (dis)advantages, plus some scripts and weird CLI. > From dmburgess at linktechs.net Mon Apr 12 15:24:19 2010 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 12 Apr 2010 15:24:19 -0500 Subject: Mikrotik RouterOS References: <4BC36C83.7040200@freedomnet.co.nz><4BC36E27.4000005@gmail.com> <4BC37928.5030004@Janoszka.pl> <4BC37D55.6050806@freedomnet.co.nz> Message-ID: <91522911795E174F97E7EF8B792A103122899B@ltiserver.LTI.local> Most of the major features of RouterOS are not "Linux" native apps anymore. Back in v2.9 this was the case, i.e. the Proxy server was SQUID, OSPF was again, the same way using a Linux app. However, especially in v3, and 4, as well as now v5, MikroTik has really made their own system. Not wishing to go into, what is better, the key here is that they have a super small footprint, and their hardware (for the cost) can't be beat. A sub 20-40 meg MPLS router with 5 ports for $40 USD. . 7200VXR replacements for under 1500. Other than they primary focus on Ethernet/Fiber/Wireless hardware, virtually no Legacy WAN interfaces anymore. ----------------------------------------------------------- Dennis Burgess, CCNA, Mikrotik Certified Trainer, MTCNA, MTCRE, MTCWE, MTCTCE, MTCUME Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" -----Original Message----- From: James Jones [mailto:james at freedomnet.co.nz] Sent: Monday, April 12, 2010 3:07 PM To: nanog at nanog.org Subject: Re: Mikrotik RouterOS kind of....routerOS supports MPLS, linux does not On 4/12/10 3:48 PM, Grzegorz Janoszka wrote: > On 12-4-2010 21:44, Gustavo Santos wrote: >> its was an old bug, that had been fixed for a while.. > > You should still keep in mind Mikrotik is just Linux, with all its > (dis)advantages, plus some scripts and weird CLI. > From khuon at neebu.net Mon Apr 12 15:28:46 2010 From: khuon at neebu.net (Jake Khuon) Date: Mon, 12 Apr 2010 13:28:46 -0700 Subject: Mikrotik RouterOS In-Reply-To: <4BC37928.5030004@Janoszka.pl> References: <4BC36C83.7040200@freedomnet.co.nz> <4BC36E27.4000005@gmail.com> <4BC37928.5030004@Janoszka.pl> Message-ID: <1271104126.7847.10.camel@localhost> On Mon, 2010-04-12 at 21:48 +0200, Grzegorz Janoszka wrote: > On 12-4-2010 21:44, Gustavo Santos wrote: > > its was an old bug, that had been fixed for a while.. > > You should still keep in mind Mikrotik is just Linux, with all its > (dis)advantages, plus some scripts and weird CLI. That's like saying that a Juniper is just FreeBSD with a bunch of scripts and a weird CLI. -- /*=================[ Jake Khuon ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ From egon at egon.cc Mon Apr 12 15:35:51 2010 From: egon at egon.cc (James Downs) Date: Mon, 12 Apr 2010 13:35:51 -0700 Subject: FCC dealt major blow in net neutrality ruling favoring, Comcast In-Reply-To: <4BC37D17.5010400@bennett.com> References: <4BC0F119.2030802@bennett.com> <4BC369A9.3060805@bennett.com> <4BC37D17.5010400@bennett.com> Message-ID: <73677FCA-B04E-4E92-BFE0-B5A697C8A297@egon.cc> On Apr 12, 2010, at 1:05 PM, Richard Bennett wrote: > You're speculating that ITIF gets funding from Comcast, and therefore If only the ITIF released information about their funding sources. So, does Comcast contribute funds or otherwise sponsor ITIF? Does Google, Intel, or Microsoft? Cheers, -j From cook at cookreport.com Mon Apr 12 15:58:33 2010 From: cook at cookreport.com (Gordon Cook) Date: Mon, 12 Apr 2010 16:58:33 -0400 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <9A24C4A5-8A6D-4512-B1EA-6F9F247F486D@virtualized.org> References: <201004121251.o3CCpP9P001633@aurora.sol.net> <4C3EFA25-69C2-47B9-8976-8AD329BE7C2D@arin.net> <9A24C4A5-8A6D-4512-B1EA-6F9F247F486D@virtualized.org> Message-ID: <396DA23E-152F-4115-B2FB-49C17E203E2D@cookreport.com> David, in 1997 and 1998 I was spending about 25% of my time interview the principals and engaged in informal conversations with Ira Magaziner,Kim Hubbard, DonMitchell and others. I was in Londone in late jan 1998 when Jon tried to redirect the root. Magaziner was there and daniel karenburg and others. We did an entire day on these issues. In addition to my published record, I have extensive electronic archives related to the manueverings in the founding of Arin. Should it come to a court case i believe that arin will come court fine and i trust that i will be able to asist the people involved in determining who did what to whom when and for what reasons. Steve Wolff will remember attending with me a late afternoon meeting with magaziner in Ira office in mid december 1997 on the day that Ira took Jon to lunch and announced to Jon that he had put together funding to carry the IANA activities through Oct 1 of 1998 and the founding of newco. Don Mitchel is Mr "cooperative agreement." I am quite confident that what John Curran is saying below is solid. Don did yeoman's work in ensuring the birth and independence of ARIN. ============================================================= The COOK Report on Internet Protocol, 609 882-2572 (PSTN) 609 403-2067 (mjack) Back Issues: http://www.cookreport.com/index.php?option=com_docman&task=cat_view&gid=37&Itemid=61 Cook's Collaborative Edge Blog http://gordoncook.net/wp/ Subscription info: http://www.cookreport.com/index.php?option=com_content&view=article&id=54&Itemid=65 ============================================================= On Apr 12, 2010, at 2:36 PM, David Conrad wrote: > John, > > On Apr 12, 2010, at 5:23 AM, John Curran wrote: >> On this matter we do agree, since allocations prior to ARIN's formation were >> generally made pursuant to a US Government contract or cooperative agreement. > > As we're both aware, Jon was funded in part via the ISI Teranode Network Technologies project. Folks who were directly involved have told me that IANA-related activities weren't even identified in the original contracts until the mid- to late-90s (around the time when lawsuits were being thrown at Jon because of the domain name wars -- odd coincidence, that) when the IANA activities were codified as "Task 4". IANAL, but it seems a bit of a stretch to me for ARIN to assert policy control over resources allocated prior to ARIN's existence without any sort of documentation that explicitly lists that policy control in ARIN's predecessor (ever). Like I said, it'll be an interesting court case. > > Regards, > -drc > > > > From netpowercock at gmail.com Mon Apr 12 16:06:36 2010 From: netpowercock at gmail.com (Stonix Farstone) Date: Mon, 12 Apr 2010 17:06:36 -0400 Subject: FCC dealt major blow in net neutrality ruling favoring, Comcast In-Reply-To: <4BC369A9.3060805@bennett.com> References: <4BC0F119.2030802@bennett.com> <4BC369A9.3060805@bennett.com> Message-ID: On Mon, Apr 12, 2010 at 2:42 PM, Richard Bennett wrote: > One of the things I like about e-mail lists is learning things about myself > that I never knew before, especially regarding my occupation. For the last 9 > months or so I've been working part-time with a Washington think tank in an > analyst capacity, not as a lobbyist, and not on the Comcast payroll. My > views about Internet regulation precede this job and haven't been altered by > it. For purposes of the present discussion, I'd rather be known as the guy > who wrote the first IEEE 802 standard for Ethernet over twisted pair, or > designed the Wi-Fi MAC protocol, or the DRP for UWB, or something like that. You might want to ring up the IEEE and get them to fix their egregious omission of your name as the designer of the Wi-Fi MAC protocol. http://standards.ieee.org/getieee802/download/802.11-2007.pdf *Participants* At the time the draft of this revision was sent to sponsor ballot, the IEEE 802.11 Working Group had the following officers: *Stuart J. Kerry*, *Chair **Al Petrick*, *Vice-Chair and Treasurer **Harry R. Worstell*, *Vice-Chair **Tim Godfrey*, *Secretary **Nanci Vogtli*, *Publicity Standing Committee **Teik-Kheong Tan*, *Chair, Wireless Next Generation Standing Committee **Terry L. Cole *and *Simon Barber*, *Technical Editors* *Richard H. Paine*, *Chair, Task Group k **Bruce P. Kraemer*, *Chair, Task Group n **Sheung Li*, *Vice-Chair, Task Group n **Lee Armstrong*, *Chair, Task Group p **Clint Chaplin*, *Chair, Task Group r **Donald E. Eastlake III *, *Chair, Task Group s **Charles R. Wright*, *Chair, Task Group t **Stephen McCann*, *Chair, Task Group u **Pat R. Calhoun*, *Chair, Task Group v **Jesse Walker*, *Chair, Task Group w **Peter Ecclesine*, *Chair, Contention-Based Protocol Study Group* When the IEEE 802.11 Working Group approved this revision, Task Group m had the following membership: Bernard D. Aboba Osama S. Aboul-Magd Santosh P. Abraham Tomoko Adachi Jonathan R. Agre Jon Adams Carlos H. Aldana Thomas Alexander Areg Alimian Keith Amann Veera Anantha Merwyn B. Andrade Carl F. Andren Scott Andrews David C. Andrus Hidenori Aoki Tsuguhide Aoki Michimasa Aramaki Takashi Aramaki Sirikiat Lek Ariyavisitakul Lee R. Armstrong Larry Arnett Yusuke Asai Arthur W. Astrin Malik Audeh Geert A. Awater David Bagby Michael Bahr Dennis J. Baker *Robert O?Hara*, *Chair **Terry L. Cole*, *Editor* Ramanathan Balachander Simon Barber Richard N. Barnwell John R. Barr Kevin M. Barry Charles R. Bartel Burak H. Baysal John L. Benko Mathilde Benveniste Don Berry Nehru Bhandaru Yogesh B. Bhatt Bjorn A. Bjerke Simon Black Scott Blue Jan Boer Herve Bonneville William M. Brasier Alistair G. Buttar Pat R. Calhoun Nancy Cam-Winget Necati Canpolat Bill Carney Pat Carson Broady B. Cash RongFeng Chang Clint F. Chaplin Amalavoyal Chari James Chen Jeng-Hong Chen Shiuh Chen Ye Chen Yi-Ming Chen Alexander L. Cheng Hong Cheng Greg L. Chesson Aik Chindapol Sunghyun Choi Won-Joon Choi Liwen Chu Dong-Ming Chuang Ken Clements John T. Coffey W. Steven Conner Charles I. Cook Kenneth Cook Steven Crowley Marc de Courville Rolf J. De Vegt Sabine Demel Yoshiharu Doi Brett L. Douglas Baris B. Dundar Chris Durand Roger P. Durand Sebastien Dure Yaron Dycian Donald E. Eastlake Peter Ecclesine Copyright ? 2007 IEEE. All rights reserved. vvi Copyright ? 2007 IEEE. All rights reserved. Richard Eckard Jonathan P. Edney Bruce Edwards John Egan Stephen P. Emeott Marc Emmelmann Darwin Engwer Joseph Epstein Patrik Eriksson Mustafa Eroz Andrew X. Estrada Christoph Euscher Stefano M. Faccin John C. Fakatselis Lars P. Falk Steve W. Fantaske Michael Faulkner Paul H. Feinberg Alex Feldman Matthew J. Fischer Wayne K. Fisher Michael D. Foegelle Brian Ford Guido Frederiks Benoit Fremont Takashi Fukagawa Hiroshi Furukawa James Gardner Monisha Ghosh James P. K. Gilb Jeffrey M. Gilbert Tim Godfrey Sandesh Goel Wataru Gohda Sudheer Grandhi Gordon P. Gray Paul K. Gray Larry Green Daqing Gu Srikanth Gumamdi David Gurevich Fred Haisch Robert J. Hall Neil N. Hamady Seishi Hanaoka Christopher J. Hansen James J. Harford Daniel N. Harkins Brian D. Hart Chris Hartman Thomas Haslestad Amer A. Hassan Vann (William) Hasty James P. Hauser Yutaka Hayakawa Shigenori Hayase Kevin V. Hayes Haixiang He David J. Hedberg Robert F. Heile Gregory Scott Henderson Eleanor Hepworth Frans M. Hermodsson Karl F. Heubaum Odagiri Hideaki Guido R. Hiertz Garth D. Hillman Christopher S. Hinsz Michael M. Hoghooghi Allen Hollister Hooman Honary William D. Horne Henry Horng Yungping A. Hsu David Hunter Muhammad Z. Ikram Daichi Imamura Yasuhiko Inoue Kazuhito Ishida Takashi Ishidoshiro Takumi Ito Lakshmi Iyer Eric A. Jacobsen Marc Jalfon KyungHun Jang Yuh-Ren Jauh Ho-In J. Jeon Taehyun Jeon Jorjeta G. Jetcheva Lusheng Ji Yung-Yih Jian Jari E. Jokela VK Jones Bobby Jose Avinash Joshi Tyan-Shu Jou Carl W. Kain Naveen K. Kakani Srinivas Kandala Shantanu Kangude Jeyhan Karaoguz Kevin J. Karcz Pankaj R. Karnik Assaf Y. Kasher Masato Kato Douglas Kavner Patrick Kelly Stuart J. Kerry John W. Ketchum Ryoji Kido Tomohiro Kikuma JinKyeong (Joseph) Kim Joonsuk Kim Yongsuk Kim Youngsoo Kim Ziv Kimhi Shigeo Kishimoto Guenter Kleindl Jarkko Kneckt Kiyotaka Kobayashi Mark M. Kobayashi Keiichiro Koga Andrei Kojukhov Thomas Kolze George Kondylis Rahul Kopikar John M. Kowalski Bruce P. Kraemer Jan P. Kruys Thomas Kuehnel Rajneesh Kumar Takushi Kunihiro Ted Kuo Thomas M. Kurihara Denis Kuwahara Bo Kvarnstrom Joe Kwak Edwin Kwon Paul Lambert David S. Landeta Jeremy A. Landt Joseph P. Lauer David J. Leach Dongjun Lee Insun Lee Myung J. Lee Sung-Won Lee Tae-Jin Lee Martin Lefkowitz Uriel Lemberger Joseph Levy Scott Leyonhjelm Jia-Ru Li Pen Li Sheung Li Yuan Li Haixiang Liang Jie Liang Wei Lih Lim Huashih A. Lin Albert Liu Changwen Liu Der-Zheng Liu Ed W. Liu Hang Liu I-Ru Liu Jason Liu Xiaoyu Liu Yong Liu Peter Loc Peter M. Lojko Hui-Ling Lou Phil MacKenzie Doug K. Makishima Majid M. Malek Jouni K. Malinen Mahalingam Mani Kevin Mankin William Marshall Art Martin Tomoyuki Matsumoto Yoichi Matsumoto Ryoko Matsuo Sudheer Matta Thomas A. Maufer Stephen McCann Kelly P. McClellan William J. McFarland Timothy McGovern Darren P. McNamara Justin P. McNew Irina Medvedev Pratik Mehta Mark G. Merrill Klaus Meyer Arnaud Meylan Morgan H. Miki Robert R. Miller Seungwook Min Cimarron Mittelsteadt Fanny Mlinarsky Andreas F. Molisch Michael Montemurro Rondal J. Moore Rajendra T. Moorti Mike Moreton Yuichi Morioka Steven A. Morley Patrick Mourot Markus D. Muck Syed Aon Mujtaba Peter A. Murphy Peter Murray Andrew Myles Yukimasa Nagai Tetsuya Nakamura Seigo Nakao Hiroyuki Nakase Bhaskar Nallapureddy Seung Hoon Nam Sanjiv Nanda Partha Narasimhan Slobodan Nedic Paul D. Newton Chiu Ngo Qiang Ni Gunnar Nitsche Huaning Niu Erwin Noble Richard H. Noens Ivan F. Oakes Knut T. Odman Masakatsu Ogawa Hiroshi Oguma Eric J. Ojard Chandra S. Olson Timothy S. Olson Jon O?Nan Job Oostveen Satoshi Oyama Sebnem Z. Ozer Richard H. Paine Michael J. Paljug Stephen Palm Ashish Pandharipande Paul W. Panish Thomas Pare Jong Ae Park Steve Parker Kourosh Parsa Yaron Peleg Eldad Perahia James E. Petranovich Al Petrick Fahd Pirzada Joe Pitarresi Subbu Ponnuswamy Neeraj Poojary Stephen P. Pope James D. Portaro Henry Ptasinski Aleksandar Purkovic Emily H. Qi Luke Qian Jim E. Raab Ali Raissinia Ajay Rajkumar Taori Rakesh Sridhar Ramesh Noman Rangwala Gregg Rasor Stephen G. Rayment Ivan Reede Stanley A. Reible Joe A. Repice Edward Reuss Maximilian Riegel Eilon Riess Carlos A. Rios Randy Roebuck Justinian Rosca Jon W. Rosdahl Michael Rude Marian X. Rudolf Bahareh Sadeghi Emek Sadot Yousuf Saifullah Kazuyuki Sakoda Atul Salhotra Hemanth Sampath Anil Sanwalka Octavian V. Sarca Toshiyuki Sashihara Ambatipudi R. Sastry Monica Saxena Vincenzo Scarpa Richard N. Schnacke Steven D. Schnier Erik Schylander Michael Seals Joe Sensendorf Vikram Seth Ariel Sharon Stephen J. Shellhammer Ian Sherlock Matthew J. Sherman Ming Sheu Shusaku Shimada Takashi Shono William M. Shvodian D. J. Shyy Thomas M. Siep Floyd Simpson Massimiliano Siti Roger R. Skidmore Matt Smith Kapil Sood Amjad Soomro Robert T. Soranno Ranga Srinivasan Robert Stacey R. J. Stancavage Dorothy Stanley Martin J. Staszak William K. Steck Adrian P. Stephens Fabrice Stevens Carl R. Stevenson Victor J. Stolpman Guenael T. Strutt Tsutomu Sugawara Sumei Sun Shravan K. Surineni Hirokazu Tagiri Eiji Takagi Masahiro Takagi Seiichiro Takahashi Mineo Takai Daisuke Takeda Sonal Tambe Pek-Yew Tan Teik-Kheong Tan Hideki Tanaka Yasuhiro Tanaka Jeffrey Tao Clifford Tavares Stephan Ten Brink Jerry Thrasher Eric T. Tokubo Alexander Tolpin James D. Tomcik Timothy P. Towell Jason Trachewsky Solomon B. Trainin Jean Tsao Rodger Tseng Chih C. Tsien Tom Tsoulogiannis David Tung Sandra L. Turner Mike E. Tzamaloukas Yusuke Uchida Stefano Valle Niels Van Erven Richard van Leeuwen Richard D. J. Van Nee Bart Van Poucke Nico J. van Waes Allert van Zelst Fabian Varas Dmitri Varsanofiev Dalton T. Victor Bert Visscher George A. Vlantis Nanci Vogtli Tim Wakeley Jesse R. Walker Brad N. Wallace Vivek Wandile Huaiyuan Wang Copyright ? 2007 IEEE. All rights reserved. vii viii Copyright ? 2007 IEEE. All rights reserved. Christopher G. Ware Craig D. Warren Fujio Watanabe Mati A. Wax Mark Webster Bryan Wells Jim Wendt Menzo M. Wentink Filip Weytjens Stephen R. Whitesell Richard Williams James M. Wilson Jack H. Winters Jeffrey J. Wojtiuk Jin Kue Wong Timothy G. Wong Marcus Wong James Woodyatt Harry R. Worstell Charles R. Wright Gang Wu Ariton Xhafa Bo Xia Akiyoshi Yagi Katsuhiko Yamada Takeshi Yamamoto Tomoya Yamaura Lily Yang Raziq Yaqub Huanchun Ye James Yee Chi-Hsiang Yeh Chris Young Heejung Yu Hon M. Yung Erol K. Yurtkuran Artur Zaks Eldad Zeira Jinyun Zhang Chunhui Zhu Jeffrey C. Zhu Juan-Carlos Zuniga Johnny Zweig James Zyren The following members of the individual balloting committee voted on this revision. Balloters may have voted for approval, disapproval, or abstention. Ahmed Abdelhalim Osama S. Aboulmagd Tomoko Adachi Toru Aihara Keith Amann Butch Anton Charles L. Barest John R. Barr Hugh Barrass Roger Berg Parag D. Bhatt Gennaro Boggia Matthew K. Burnburg Alistair G. Buttar William A. Byrd James T. Carlo Jay Catelli Clint F. Chaplin Yi-Ming Chen Yung-Mu Chen Mr Aik Chindapol Keith Chow Tommy P. Cooper Javier Del-Prado-Pavon Kalyan R. Dharanipragada Thomas J. Dineen Surinder K. Dureja Sourav K. Dutta Peter Ecclesine Darwin A. Engwer John W. Fendrich Michael A. Fischer Wayne K. Fisher Andre F. Fournier Devon L. Gayle Michael D. Geipel Fernando Genkuong Theodore Georgantas Ian C. Gifford James P. Gilb Nikhil Goel Sergiu R. Goma Randall C. Groves Robert M. Grow C. G. Guy Siamack Haghighi David E. Halasz Samudra E. Haque Karl F. Heubaum Shui H. Heung Werner Hoelzl Dennis Horwitz Yasuhiko Inoue Sergiu A. Iordanescu Atsushi Ito Peeya Iwagoshi Raj Jain David Johnston Bobby Jose Srinivas Kandala Junghong Kao Efthymios G. Karabetsos Kevin J. Karcz Stuart J. Kerry Brian G. Kiernan Yongbum Kim Patrick W. Kinney Gunter Kleindl Thomas M. Kurihara Jeremy A. Landt Juan L. Lazaro Solomon Lee John Lemon Daniel G. Levesque Joseph S. Levy Jan-Ray Liao William Lumpkins G. L. Luri Kevin D. Marquess George J. Miao William J. Mitchell Jose Morales Mike Moreton Ronald G. Murias Andrew F. Myles M. Narayanan Michael S. Newman Erwin R. Noble Richard H. Noens Satoshi Obara Robert O?hara Stephen R. Palm Glenn W. Parsons Paul W. Piggin Subburajan Ponnuswamy Vikram Punj Maximilian Riegel Philip T. Robinson Stephen C. Schwarm Perry L. Schwartz William M. Shvodian Floyd D. Simpson Jung Je Son Amjad A. Soomro Manikantan Srinivasan Dorothy V. Stanley Thomas E. Starai Adrian P. Stephens Mark A. Sturza Masahiro Takagi Sandra L. Turner Mark-Rene Uchida Harry R. Worstell Forrest D. Wright Oren Yuen Janusz Zalewski When the IEEE-SA Standards Board approved this revision on 8 March 2007, it had the following membership: Richard DeBlasio Julian Forster* Alex Gelman William R. Goldbach Arnold M. Greenspan Joanna N. Guenin Kenneth S. Hanus William B. Hopf *Steve M. Mills, **Chair **Robert M. Grow, **Vice Chair **Don Wright, **Past Chair **Judith Gorman, **Secretary* Richard H. Hulett Hermann Koch Joseph L. Koepfinger* John Kulick David J. Law Glenn Parsons Ronald C. Petersen Tom A. Prevost Narayanan Ramachandran Greg Ratta Robby Robson Anne-Marie Sahazizian Virginia C. Sulzberger* Malcolm V. Thaden Richard L. Townsend Howard L. Wolfman *Member Emeritus Also included are the following nonvoting IEEE-SA Standards Board liaisons: Satish K. Aggarwal, *NRC Representative *Alan H. Cookson, *NIST Representative *Virginia C. Sulzberger, *Member/TAB Representative* Michelle D. Turner IEEE Standards Program Manager, Document Development Michael D. Kipness IEEE Standards Program Manager, Technical Program Development -- Stonix Farstone Network Power Consulting CCNA, A+, MCSE, CCSP, CCDA, GRAYHAT, JCNIP, NETWORK+, ASE, RHCP, JNCI-M, JNCI-J, ACSA, N+ PGP key ID E99A11FF "Television is where you watch people in your living room that you would not want near your house." -- Groucho Marx +++++++++++++++++++++++++++++++++++ The information contained in this e-mail is confidential and is intended only for the named recipient(s). If you are not the intended recipient you must not copy, distribute, or take any action or reliance on it. If you have received this e-mail in error, please notify the sender. Any unauthorized disclosure of the information contained in this e-mail is strictly prohibited and this means you! +++++++++++++++++++++++++++++++++++ From richard at bennett.com Mon Apr 12 16:10:55 2010 From: richard at bennett.com (Richard Bennett) Date: Mon, 12 Apr 2010 14:10:55 -0700 Subject: FCC dealt major blow in net neutrality ruling favoring, Comcast In-Reply-To: References: <4BC0F119.2030802@bennett.com> <4BC369A9.3060805@bennett.com> Message-ID: <4BC38C5F.20904@bennett.com> Thanks for pointing that out. RB On 4/12/2010 2:06 PM, Stonix Farstone wrote: On Mon, Apr 12, 2010 at 2:42 PM, Richard Bennett <[1]richard at bennett.com> wrote: One of the things I like about e-mail lists is learning things about myself that I never knew before, especially regarding my occupation. For the last 9 months or so I've been working part-time with a Washington think tank in an analyst capacity, not as a lobbyist, and not on the Comcast payroll. My views about Internet regulation precede this job and haven't been altered by it. For purposes of the present discussion, I'd rather be known as the guy who wrote the first IEEE 802 standard for Ethernet over twisted pair, or designed the Wi-Fi MAC protocol, or the DRP for UWB, or something like that. You might want to ring up the IEEE and get them to fix their egregious omission of your name as the designer of the Wi-Fi MAC protocol. [2]http://standards.ieee.org/getieee802/download/802.11-2007.pdf Participants At the time the draft of this revision was sent to sponsor ballot, the IEEE 802.11 Working Group had the following officers: Stuart J. Kerry, Chair Al Petrick, Vice-Chair and Treasurer Harry R. Worstell, Vice-Chair Tim Godfrey, Secretary Nanci Vogtli, Publicity Standing Committee Teik-Kheong Tan, Chair, Wireless Next Generation Standing Committee Terry L. Cole and Simon Barber, Technical Editors Richard H. Paine, Chair, Task Group k Bruce P. Kraemer, Chair, Task Group n Sheung Li, Vice-Chair, Task Group n Lee Armstrong, Chair, Task Group p Clint Chaplin, Chair, Task Group r Donald E. Eastlake III, Chair, Task Group s Charles R. Wright, Chair, Task Group t Stephen McCann, Chair, Task Group u Pat R. Calhoun, Chair, Task Group v Jesse Walker, Chair, Task Group w Peter Ecclesine, Chair, Contention-Based Protocol Study Group When the IEEE 802.11 Working Group approved this revision, Task Group m had the following membership: Bernard D. Aboba Osama S. Aboul-Magd Santosh P. Abraham Tomoko Adachi Jonathan R. Agre Jon Adams Carlos H. Aldana Thomas Alexander Areg Alimian Keith Amann Veera Anantha Merwyn B. Andrade Carl F. Andren Scott Andrews David C. Andrus Hidenori Aoki Tsuguhide Aoki Michimasa Aramaki Takashi Aramaki Sirikiat Lek Ariyavisitakul Lee R. Armstrong Larry Arnett Yusuke Asai Arthur W. Astrin Malik Audeh Geert A. Awater David Bagby Michael Bahr Dennis J. Baker Robert O'Hara, Chair Terry L. Cole, Editor Ramanathan Balachander Simon Barber Richard N. Barnwell John R. Barr Kevin M. Barry Charles R. Bartel Burak H. Baysal John L. Benko Mathilde Benveniste Don Berry Nehru Bhandaru Yogesh B. Bhatt Bjorn A. Bjerke Simon Black Scott Blue Jan Boer Herve Bonneville William M. Brasier Alistair G. Buttar Pat R. Calhoun Nancy Cam-Winget Necati Canpolat Bill Carney Pat Carson Broady B. Cash RongFeng Chang Clint F. Chaplin Amalavoyal Chari James Chen Jeng-Hong Chen Shiuh Chen Ye Chen Yi-Ming Chen Alexander L. Cheng Hong Cheng Greg L. Chesson Aik Chindapol Sunghyun Choi Won-Joon Choi Liwen Chu Dong-Ming Chuang Ken Clements John T. Coffey W. Steven Conner Charles I. Cook Kenneth Cook Steven Crowley Marc de Courville Rolf J. De Vegt Sabine Demel Yoshiharu Doi Brett L. Douglas Baris B. Dundar Chris Durand Roger P. Durand Sebastien Dure Yaron Dycian Donald E. Eastlake Peter Ecclesine Copyright ? 2007 IEEE. All rights reserved. vvi Copyright ? 2007 IEEE. All rights reserved. Richard Eckard Jonathan P. Edney Bruce Edwards John Egan Stephen P. Emeott Marc Emmelmann Darwin Engwer Joseph Epstein Patrik Eriksson Mustafa Eroz Andrew X. Estrada Christoph Euscher Stefano M. Faccin John C. Fakatselis Lars P. Falk Steve W. Fantaske Michael Faulkner Paul H. Feinberg Alex Feldman Matthew J. Fischer Wayne K. Fisher Michael D. Foegelle Brian Ford Guido Frederiks Benoit Fremont Takashi Fukagawa Hiroshi Furukawa James Gardner Monisha Ghosh James P. K. Gilb Jeffrey M. Gilbert Tim Godfrey Sandesh Goel Wataru Gohda Sudheer Grandhi Gordon P. Gray Paul K. Gray Larry Green Daqing Gu Srikanth Gumamdi David Gurevich Fred Haisch Robert J. Hall Neil N. Hamady Seishi Hanaoka Christopher J. Hansen James J. Harford Daniel N. Harkins Brian D. Hart Chris Hartman Thomas Haslestad Amer A. Hassan Vann (William) Hasty James P. Hauser Yutaka Hayakawa Shigenori Hayase Kevin V. Hayes Haixiang He David J. Hedberg Robert F. Heile Gregory Scott Henderson Eleanor Hepworth Frans M. Hermodsson Karl F. Heubaum Odagiri Hideaki Guido R. Hiertz Garth D. Hillman Christopher S. Hinsz Michael M. Hoghooghi Allen Hollister Hooman Honary William D. Horne Henry Horng Yungping A. Hsu David Hunter Muhammad Z. Ikram Daichi Imamura Yasuhiko Inoue Kazuhito Ishida Takashi Ishidoshiro Takumi Ito Lakshmi Iyer Eric A. Jacobsen Marc Jalfon KyungHun Jang Yuh-Ren Jauh Ho-In J. Jeon Taehyun Jeon Jorjeta G. Jetcheva Lusheng Ji Yung-Yih Jian Jari E. Jokela VK Jones Bobby Jose Avinash Joshi Tyan-Shu Jou Carl W. Kain Naveen K. Kakani Srinivas Kandala Shantanu Kangude Jeyhan Karaoguz Kevin J. Karcz Pankaj R. Karnik Assaf Y. Kasher Masato Kato Douglas Kavner Patrick Kelly Stuart J. Kerry John W. Ketchum Ryoji Kido Tomohiro Kikuma JinKyeong (Joseph) Kim Joonsuk Kim Yongsuk Kim Youngsoo Kim Ziv Kimhi Shigeo Kishimoto Guenter Kleindl Jarkko Kneckt Kiyotaka Kobayashi Mark M. Kobayashi Keiichiro Koga Andrei Kojukhov Thomas Kolze George Kondylis Rahul Kopikar John M. Kowalski Bruce P. Kraemer Jan P. Kruys Thomas Kuehnel Rajneesh Kumar Takushi Kunihiro Ted Kuo Thomas M. Kurihara Denis Kuwahara Bo Kvarnstrom Joe Kwak Edwin Kwon Paul Lambert David S. Landeta Jeremy A. Landt Joseph P. Lauer David J. Leach Dongjun Lee Insun Lee Myung J. Lee Sung-Won Lee Tae-Jin Lee Martin Lefkowitz Uriel Lemberger Joseph Levy Scott Leyonhjelm Jia-Ru Li Pen Li Sheung Li Yuan Li Haixiang Liang Jie Liang Wei Lih Lim Huashih A. Lin Albert Liu Changwen Liu Der-Zheng Liu Ed W. Liu Hang Liu I-Ru Liu Jason Liu Xiaoyu Liu Yong Liu Peter Loc Peter M. Lojko Hui-Ling Lou Phil MacKenzie Doug K. Makishima Majid M. Malek Jouni K. Malinen Mahalingam Mani Kevin Mankin William Marshall Art Martin Tomoyuki Matsumoto Yoichi Matsumoto Ryoko Matsuo Sudheer Matta Thomas A. Maufer Stephen McCann Kelly P. McClellan William J. McFarland Timothy McGovern Darren P. McNamara Justin P. McNew Irina Medvedev Pratik Mehta Mark G. Merrill Klaus Meyer Arnaud Meylan Morgan H. Miki Robert R. Miller Seungwook Min Cimarron Mittelsteadt Fanny Mlinarsky Andreas F. Molisch Michael Montemurro Rondal J. Moore Rajendra T. Moorti Mike Moreton Yuichi Morioka Steven A. Morley Patrick Mourot Markus D. Muck Syed Aon Mujtaba Peter A. Murphy Peter Murray Andrew Myles Yukimasa Nagai Tetsuya Nakamura Seigo Nakao Hiroyuki Nakase Bhaskar Nallapureddy Seung Hoon Nam Sanjiv Nanda Partha Narasimhan Slobodan Nedic Paul D. Newton Chiu Ngo Qiang Ni Gunnar Nitsche Huaning Niu Erwin Noble Richard H. Noens Ivan F. Oakes Knut T. Odman Masakatsu Ogawa Hiroshi Oguma Eric J. Ojard Chandra S. Olson Timothy S. Olson Jon O'Nan Job Oostveen Satoshi Oyama Sebnem Z. Ozer Richard H. Paine Michael J. Paljug Stephen Palm Ashish Pandharipande Paul W. Panish Thomas Pare Jong Ae Park Steve Parker Kourosh Parsa Yaron Peleg Eldad Perahia James E. Petranovich Al Petrick Fahd Pirzada Joe Pitarresi Subbu Ponnuswamy Neeraj Poojary Stephen P. Pope James D. Portaro Henry Ptasinski Aleksandar Purkovic Emily H. Qi Luke Qian Jim E. Raab Ali Raissinia Ajay Rajkumar Taori Rakesh Sridhar Ramesh Noman Rangwala Gregg Rasor Stephen G. Rayment Ivan Reede Stanley A. Reible Joe A. Repice Edward Reuss Maximilian Riegel Eilon Riess Carlos A. Rios Randy Roebuck Justinian Rosca Jon W. Rosdahl Michael Rude Marian X. Rudolf Bahareh Sadeghi Emek Sadot Yousuf Saifullah Kazuyuki Sakoda Atul Salhotra Hemanth Sampath Anil Sanwalka Octavian V. Sarca Toshiyuki Sashihara Ambatipudi R. Sastry Monica Saxena Vincenzo Scarpa Richard N. Schnacke Steven D. Schnier Erik Schylander Michael Seals Joe Sensendorf Vikram Seth Ariel Sharon Stephen J. Shellhammer Ian Sherlock Matthew J. Sherman Ming Sheu Shusaku Shimada Takashi Shono William M. Shvodian D. J. Shyy Thomas M. Siep Floyd Simpson Massimiliano Siti Roger R. Skidmore Matt Smith Kapil Sood Amjad Soomro Robert T. Soranno Ranga Srinivasan Robert Stacey R. J. Stancavage Dorothy Stanley Martin J. Staszak William K. Steck Adrian P. Stephens Fabrice Stevens Carl R. Stevenson Victor J. Stolpman Guenael T. Strutt Tsutomu Sugawara Sumei Sun Shravan K. Surineni Hirokazu Tagiri Eiji Takagi Masahiro Takagi Seiichiro Takahashi Mineo Takai Daisuke Takeda Sonal Tambe Pek-Yew Tan Teik-Kheong Tan Hideki Tanaka Yasuhiro Tanaka Jeffrey Tao Clifford Tavares Stephan Ten Brink Jerry Thrasher Eric T. Tokubo Alexander Tolpin James D. Tomcik Timothy P. Towell Jason Trachewsky Solomon B. Trainin Jean Tsao Rodger Tseng Chih C. Tsien Tom Tsoulogiannis David Tung Sandra L. Turner Mike E. Tzamaloukas Yusuke Uchida Stefano Valle Niels Van Erven Richard van Leeuwen Richard D. J. Van Nee Bart Van Poucke Nico J. van Waes Allert van Zelst Fabian Varas Dmitri Varsanofiev Dalton T. Victor Bert Visscher George A. Vlantis Nanci Vogtli Tim Wakeley Jesse R. Walker Brad N. Wallace Vivek Wandile Huaiyuan Wang Copyright ? 2007 IEEE. All rights reserved. vii viii Copyright ? 2007 IEEE. All rights reserved. Christopher G. Ware Craig D. Warren Fujio Watanabe Mati A. Wax Mark Webster Bryan Wells Jim Wendt Menzo M. Wentink Filip Weytjens Stephen R. Whitesell Richard Williams James M. Wilson Jack H. Winters Jeffrey J. Wojtiuk Jin Kue Wong Timothy G. Wong Marcus Wong James Woodyatt Harry R. Worstell Charles R. Wright Gang Wu Ariton Xhafa Bo Xia Akiyoshi Yagi Katsuhiko Yamada Takeshi Yamamoto Tomoya Yamaura Lily Yang Raziq Yaqub Huanchun Ye James Yee Chi-Hsiang Yeh Chris Young Heejung Yu Hon M. Yung Erol K. Yurtkuran Artur Zaks Eldad Zeira Jinyun Zhang Chunhui Zhu Jeffrey C. Zhu Juan-Carlos Zuniga Johnny Zweig James Zyren The following members of the individual balloting committee voted on this revision. Balloters may have voted for approval, disapproval, or abstention. Ahmed Abdelhalim Osama S. Aboulmagd Tomoko Adachi Toru Aihara Keith Amann Butch Anton Charles L. Barest John R. Barr Hugh Barrass Roger Berg Parag D. Bhatt Gennaro Boggia Matthew K. Burnburg Alistair G. Buttar William A. Byrd James T. Carlo Jay Catelli Clint F. Chaplin Yi-Ming Chen Yung-Mu Chen Mr Aik Chindapol Keith Chow Tommy P. Cooper Javier Del-Prado-Pavon Kalyan R. Dharanipragada Thomas J. Dineen Surinder K. Dureja Sourav K. Dutta Peter Ecclesine Darwin A. Engwer John W. Fendrich Michael A. Fischer Wayne K. Fisher Andre F. Fournier Devon L. Gayle Michael D. Geipel Fernando Genkuong Theodore Georgantas Ian C. Gifford James P. Gilb Nikhil Goel Sergiu R. Goma Randall C. Groves Robert M. Grow C. G. Guy Siamack Haghighi David E. Halasz Samudra E. Haque Karl F. Heubaum Shui H. Heung Werner Hoelzl Dennis Horwitz Yasuhiko Inoue Sergiu A. Iordanescu Atsushi Ito Peeya Iwagoshi Raj Jain David Johnston Bobby Jose Srinivas Kandala Junghong Kao Efthymios G. Karabetsos Kevin J. Karcz Stuart J. Kerry Brian G. Kiernan Yongbum Kim Patrick W. Kinney Gunter Kleindl Thomas M. Kurihara Jeremy A. Landt Juan L. Lazaro Solomon Lee John Lemon Daniel G. Levesque Joseph S. Levy Jan-Ray Liao William Lumpkins G. L. Luri Kevin D. Marquess George J. Miao William J. Mitchell Jose Morales Mike Moreton Ronald G. Murias Andrew F. Myles M. Narayanan Michael S. Newman Erwin R. Noble Richard H. Noens Satoshi Obara Robert O'hara Stephen R. Palm Glenn W. Parsons Paul W. Piggin Subburajan Ponnuswamy Vikram Punj Maximilian Riegel Philip T. Robinson Stephen C. Schwarm Perry L. Schwartz William M. Shvodian Floyd D. Simpson Jung Je Son Amjad A. Soomro Manikantan Srinivasan Dorothy V. Stanley Thomas E. Starai Adrian P. Stephens Mark A. Sturza Masahiro Takagi Sandra L. Turner Mark-Rene Uchida Harry R. Worstell Forrest D. Wright Oren Yuen Janusz Zalewski When the IEEE-SA Standards Board approved this revision on 8 March 2007, it had the following membership: Richard DeBlasio Julian Forster* Alex Gelman William R. Goldbach Arnold M. Greenspan Joanna N. Guenin Kenneth S. Hanus William B. Hopf Steve M. Mills, Chair Robert M. Grow, Vice Chair Don Wright, Past Chair Judith Gorman, Secretary Richard H. Hulett Hermann Koch Joseph L. Koepfinger* John Kulick David J. Law Glenn Parsons Ronald C. Petersen Tom A. Prevost Narayanan Ramachandran Greg Ratta Robby Robson Anne-Marie Sahazizian Virginia C. Sulzberger* Malcolm V. Thaden Richard L. Townsend Howard L. Wolfman *Member Emeritus Also included are the following nonvoting IEEE-SA Standards Board liaisons: Satish K. Aggarwal, NRC Representative Alan H. Cookson, NIST Representative Virginia C. Sulzberger, Member/TAB Representative Michelle D. Turner IEEE Standards Program Manager, Document Development Michael D. Kipness IEEE Standards Program Manager, Technical Program Development -- Stonix Farstone Network Power Consulting CCNA, A+, MCSE, CCSP, CCDA, GRAYHAT, JCNIP, NETWORK+, ASE, RHCP, JNCI-M, JNCI-J, ACSA, N+ PGP key ID E99A11FF "Television is where you watch people in your living room that you would not want near your house." -- Groucho Marx +++++++++++++++++++++++++++++++++++ The information contained in this e-mail is confidential and is intended only for the named recipient(s). If you are not the intended recipient you must not copy, distribute, or take any action or reliance on it. If you have received this e-mail in error, please notify the sender. Any unauthorized disclosure of the information contained in this e-mail is strictly prohibited and this means you! +++++++++++++++++++++++++++++++++++ -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC References 1. mailto:richard at bennett.com 2. http://standards.ieee.org/getieee802/download/802.11-2007.pdf From patrick at ianai.net Mon Apr 12 16:39:11 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 12 Apr 2010 17:39:11 -0400 Subject: Please do not respond to Dean and CC the NANOG list In-Reply-To: <4BC38FFD.9050407@bennett.com> References: <4BC38FFD.9050407@bennett.com> Message-ID: <6236D1CC-1E22-4CA9-88A2-600C35548FB4@ianai.net> [SNIP] Richard, and anyone else who missed the last dozen or more times this has been discussed: The NANOG list would appreciate if people who are sent Dean's private missives do not "reply all" and CC the list. Those who were not CC'ed personally (and do not filter Dean) do not see his posts. You are helping him circumvent that block. Thank you. -- TTFN, patrick From sethm at rollernet.us Mon Apr 12 17:05:56 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 12 Apr 2010 15:05:56 -0700 Subject: ARIN IP6 policy for those with legacy IP4 Space In-Reply-To: <201004091227.o39CRSva030382@aurora.sol.net> References: <201004091227.o39CRSva030382@aurora.sol.net> Message-ID: <4BC39944.706@rollernet.us> On 4/9/10 5:27 AM, Joe Greco wrote: > > ARIN might not have a contract with us, or with other legacy holders. > It wasn't our choice for ARIN to be tasked with holding up InterNIC's > end of things. However, it's likely that they've concluded that they > better do so, because if they don't, it'll probably turn into a costly > legal battle on many fronts, and I doubt ARIN has the budget for that. > > As a legacy holder, we don't really care who is currently "responsible" > for legacy maintenance/etc. However, whoever it is, if they're not > going to take on those responsibilities, that's a problem. > > The previous poster asked, "If you don't have a contract with ARIN, > why should ARIN provide you with anything?" > > Well, the flip side to that is, "ARIN doesn't have a contract with us, > but we still have copies of the InterNIC policies under which we were > assigned space, and ARIN undertook those duties, so ARIN is actually > the one with significant worries if they were to try to pull anything, > otherwise, we don't really care." > What do those InterNIC policies say about getting IPv6 space? If nothing, expect nothing. If something, hold them to it. ~Seth From gordslater at ieee.org Mon Apr 12 19:56:15 2010 From: gordslater at ieee.org (gordon b slater) Date: Tue, 13 Apr 2010 01:56:15 +0100 Subject: Mikrotik RouterOS In-Reply-To: <4BC37D55.6050806@freedomnet.co.nz> References: <4BC36C83.7040200@freedomnet.co.nz> <4BC36E27.4000005@gmail.com> <4BC37928.5030004@Janoszka.pl> <4BC37D55.6050806@freedomnet.co.nz> Message-ID: <1271120175.15669.35.camel@ub-g-d2> On Mon, 2010-04-12 at 16:06 -0400, James Jones wrote: > kind of....routerOS supports MPLS, linux does not It could (unfortunately) be a while before a full linux implementation of MPLS gains enough speed, it's very much out on the fringe of what linux "does daily". This mean that getting enough developers, free time to develop and equipment to test with seems to be quite a steep problem right now. Likewise the FreeBSD MPLS effort, though this seems to be more like familiar territory for BSD-heads, but, as ever, funding and equipment are sorely needed. If anyone (I'm thinking of the bigger players) could lend a hand, loan/ship out a box, or offer a few test-box out onto the cloud by (arrangement) the lack of MPLS on BSD and Linux machines could probably be rectified a little quicker. Or maybe someone has a tiny pot of cash to sponsor some "bounty" development? back onto the main topic... +1 for routerOS, but never needed MPLS in my encounters with it. I have to say the Microtiks do nothing (in my world, that is) that I couldn't do with half an hour and similar (but very slightly beefier) hardware and a generic/minimal BSD or linux install, but given the price, I'd be a fool to DIY if I need to hand over to others, erm , well, shall we say, `less interested` at the end of the day. It earns an extra Kibo Cookie for that, certainly. Gord -- | * error 34 * | auto-sig could find no relevant content for the message text | please change to previous tape to continue searching or enable FidoNet searching From persio at gmail.com Mon Apr 12 20:04:52 2010 From: persio at gmail.com (Persio Pucci) Date: Mon, 12 Apr 2010 22:04:52 -0300 Subject: Mikrotik RouterOS In-Reply-To: <1271120175.15669.35.camel@ub-g-d2> References: <4BC36C83.7040200@freedomnet.co.nz> <4BC36E27.4000005@gmail.com> <4BC37928.5030004@Janoszka.pl> <4BC37D55.6050806@freedomnet.co.nz> <1271120175.15669.35.camel@ub-g-d2> Message-ID: I've been considering routerOS boxes to my "less important" POPs that are candidates to be promoted to MPLS-enabled POPs, although I am still a little skeptical about it. Still doing some lab trials with it, but have not deployed it yet besides as a CE router. The reason is that I've ran into problems with it going haywire for no apparent reasons as CE, lowering my confidence on the box and keeping it a little longer into the test bed. It would be nice to hear more experiences with this little box-that-could in MPLS environments. On Mon, Apr 12, 2010 at 9:56 PM, gordon b slater wrote: > On Mon, 2010-04-12 at 16:06 -0400, James Jones wrote: > > kind of....routerOS supports MPLS, linux does not > > It could (unfortunately) be a while before a full linux implementation > of MPLS gains enough speed, it's very much out on the fringe of what > linux "does daily". This mean that getting enough developers, free time > to develop and equipment to test with seems to be quite a steep problem > right now. > > Likewise the FreeBSD MPLS effort, though this seems to be more like > familiar territory for BSD-heads, but, as ever, funding and equipment > are sorely needed. > > If anyone (I'm thinking of the bigger players) could lend a hand, > loan/ship out a box, or offer a few test-box out onto the cloud by > (arrangement) the lack of MPLS on BSD and Linux machines could probably > be rectified a little quicker. > Or maybe someone has a tiny pot of cash to sponsor some "bounty" > development? > > back onto the main topic... > > +1 for routerOS, but never needed MPLS in my encounters with it. > > I have to say the Microtiks do nothing (in my world, that is) that I > couldn't do with half an hour and similar (but very slightly beefier) > hardware and a generic/minimal BSD or linux install, but given the > price, I'd be a fool to DIY if I need to hand over to others, erm , > well, shall we say, `less interested` at the end of the day. > It earns an extra Kibo Cookie for that, certainly. > > Gord > -- > | * error 34 * | auto-sig could find no relevant content for the message > text | please change to previous tape to continue searching or enable > FidoNet searching > > > From owen at delong.com Mon Apr 12 20:41:32 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 12 Apr 2010 18:41:32 -0700 Subject: Router for Metro Ethernet In-Reply-To: <91522911795E174F97E7EF8B792A1031228980@ltiserver.LTI.local> References: <91522911795E174F97E7EF8B792A1031228980@ltiserver.LTI.local> Message-ID: <2943D53D-2716-4170-9E54-0955D065FEDA@delong.com> Yes, but, according to the Mikrotik web site they appear to be obsolete and incapable of routing IPv6. Owen On Apr 12, 2010, at 10:32 AM, Dennis Burgess wrote: > a PowerRouter at http://www.mikrotikrouter.com can handle several > hundred meg without issues. > > ----------------------------------------------------------- > Dennis Burgess, CCNA, Mikrotik Certified Trainer, MTCNA, MTCRE, MTCWE, > MTCTCE, MTCUME > Link Technologies, Inc -- Mikrotik & WISP Support Services > Office: 314-735-0270 Website: http://www.linktechs.net > LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" > > > -----Original Message----- > From: Jeffrey Negro [mailto:jnegro at billtrust.com] > Sent: Monday, April 12, 2010 12:29 PM > To: nanog at nanog.org > Subject: Router for Metro Ethernet > > Before I get taken for a ride by salespeople, I figured it would be best > to > ask the experts of Nanog.... > > My company is currently in talks to bring an ethernet circuit into our > headquarters, initially committing around 40Mbps. The ISP will be > providing > ethernet handoff, but I do not want their managed router offering > (Adtran > 4430) since it is pricey, non-redundant and I'd rather manage it myself. > My > question is about hardware. Can I assume that I can use something like > a > Cisco 2000 series router with two built in fast/gig ethernet ports, > without > a WIC? and since both sides are ethernet would the routing throughput > be > near fast ethernet speed? This is my first dealing with metro ethernet > offerings, and I don't want to assume that the Cisco throughput rates > listed > for T1/ADSL etc. are the same for a metro ethernet as the WAN. > > Any and all suggestions on the hardware would be greatly appreciated. > Thank > you in advance! From jmamodio at gmail.com Mon Apr 12 22:35:19 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 12 Apr 2010 22:35:19 -0500 Subject: Mikrotik RouterOS In-Reply-To: <1271104126.7847.10.camel@localhost> References: <4BC36C83.7040200@freedomnet.co.nz> <4BC36E27.4000005@gmail.com> <4BC37928.5030004@Janoszka.pl> <1271104126.7847.10.camel@localhost> Message-ID: On Mon, Apr 12, 2010 at 3:28 PM, Jake Khuon wrote: > On Mon, 2010-04-12 at 21:48 +0200, Grzegorz Janoszka wrote: >> On 12-4-2010 21:44, Gustavo Santos wrote: >> > its was an old bug, that had been fixed for a while.. >> >> You should still keep in mind Mikrotik is just Linux, with all its >> (dis)advantages, plus some scripts and weird CLI. > > That's like saying that a Juniper is just FreeBSD with a bunch of > scripts and a weird CLI. Yes but it has a fantastic and reliable power supply !! Cheers Jorge From frnkblk at iname.com Mon Apr 12 22:56:45 2010 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 12 Apr 2010 22:56:45 -0500 Subject: Router for Metro Ethernet In-Reply-To: References: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> Message-ID: We run a 3845 at over 300 Mbps and it's less than 50% CPU....most times less than 30%. No BGP, just OSPF. Frank -----Original Message----- From: Bill Stewart [mailto:nonobvious at gmail.com] Sent: Monday, April 12, 2010 1:27 PM To: nanog at nanog.org Subject: Re: Router for Metro Ethernet On Mon, Apr 12, 2010 at 10:55 AM, Dylan Ebner wrote: > However, this router also has 2 100mb connections from local lans that it is also terminiating. > For our 100mb metro e connections we use 3845s. The 100 mb service terminates into NM-GEs, which have a faster throughput than the hwics. Be careful using 3845s for 100 Mbps connections or above - Cisco rates them at 45 Mbps (and 3825 at half of that) but last time I checked doesn't make any promises at faster than T3. They're being conservative about it, but one thing that really can burn the horsepower is traffic shaping, which you need with some MetroE carriers. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From owen at delong.com Mon Apr 12 23:12:55 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 12 Apr 2010 21:12:55 -0700 Subject: Router for Metro Ethernet In-Reply-To: References: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> Message-ID: I stand corrected on the Mikrotik... Apparently, while not well documented, they do, indeed support IPv6 and their Wiki even includes tunnel configuration information. Apologies to Mikrotik (and some encouragement to add this to your main-line documentation). Owen On Apr 12, 2010, at 8:56 PM, Frank Bulk wrote: > We run a 3845 at over 300 Mbps and it's less than 50% CPU....most times less > than 30%. No BGP, just OSPF. > > Frank > > -----Original Message----- > From: Bill Stewart [mailto:nonobvious at gmail.com] > Sent: Monday, April 12, 2010 1:27 PM > To: nanog at nanog.org > Subject: Re: Router for Metro Ethernet > > On Mon, Apr 12, 2010 at 10:55 AM, Dylan Ebner > wrote: >> However, this router also has 2 100mb connections from local lans that it > is also terminiating. >> For our 100mb metro e connections we use 3845s. The 100 mb service > terminates into NM-GEs, which have a faster throughput than the hwics. > > Be careful using 3845s for 100 Mbps connections or above - Cisco rates > them at 45 Mbps (and 3825 at half of that) but last time I checked > doesn't make any promises at faster than T3. They're being > conservative about it, but one thing that really can burn the > horsepower is traffic shaping, which you need with some MetroE > carriers. > > > -- > ---- > Thanks; Bill > > Note that this isn't my regular email account - It's still experimental so > far. > And Google probably logs and indexes everything you send it. > > From swmike at swm.pp.se Mon Apr 12 23:42:47 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 13 Apr 2010 06:42:47 +0200 (CEST) Subject: Router for Metro Ethernet In-Reply-To: References: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> Message-ID: On Mon, 12 Apr 2010, Jeffrey Negro wrote: > In our case I believe we would be dealing with just static routes and a > lines of ACL. Do you think the routing protocols are your largest resource > usage in your scenario, or is it also just simple routing as well? Get a used 3550 or a new 3400ME or something. Sounds likeyuou'll get by just fine using an L3 switch. -- Mikael Abrahamsson email: swmike at swm.pp.se From bjorn at mork.no Tue Apr 13 04:05:52 2010 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 13 Apr 2010 11:05:52 +0200 Subject: Mikrotik RouterOS In-Reply-To: <4BC37928.5030004@Janoszka.pl> (Grzegorz Janoszka's message of "Mon, 12 Apr 2010 21:48:56 +0200") References: <4BC36C83.7040200@freedomnet.co.nz> <4BC36E27.4000005@gmail.com> <4BC37928.5030004@Janoszka.pl> Message-ID: <87pr23g1sf.fsf@nemi.mork.no> Grzegorz Janoszka writes: > On 12-4-2010 21:44, Gustavo Santos wrote: >> its was an old bug, that had been fixed for a while.. > > You should still keep in mind Mikrotik is just Linux, with all its > (dis)advantages, plus some scripts and weird CLI. Just like IOS XE... Bj?rn From jeremyparr at gmail.com Tue Apr 13 08:44:39 2010 From: jeremyparr at gmail.com (Jeremy Parr) Date: Tue, 13 Apr 2010 09:44:39 -0400 Subject: Router for Metro Ethernet In-Reply-To: References: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> Message-ID: On 13 April 2010 00:12, Owen DeLong wrote: > I stand corrected on the Mikrotik... Apparently, while not well documented, they > do, indeed support IPv6 and their Wiki even includes tunnel configuration > information. > > Apologies to Mikrotik (and some encouragement to add this to your main-line > documentation). For better or worse, the Wiki *IS* their mainline documentation. From joe.abley at icann.org Tue Apr 13 09:18:46 2010 From: joe.abley at icann.org (Joe Abley) Date: Tue, 13 Apr 2010 07:18:46 -0700 Subject: Trusted Community Representatives Message-ID: <42CABFEB-03A9-437A-94E0-CD166A8AB74D@icann.org> Colleagues, ICANN and VeriSign, with the support of the US Department of Commerce, continue to work towards DNSSEC deployment in the root zone of the DNS. ICANN is looking for Trusted Community Representatives (TCRs) to help us carry out various technical security operations. An announcement can be found here: You can submit an expression of interest here: DNSSEC key ceremonies are carried out in English. TCRs must therefore have a good understanding of written and spoken English. Regards, Joe From owen at delong.com Tue Apr 13 09:14:35 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 13 Apr 2010 07:14:35 -0700 Subject: Router for Metro Ethernet In-Reply-To: References: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> Message-ID: <9C5974A3-6001-4191-B150-20973F33B5FE@delong.com> On Apr 13, 2010, at 6:44 AM, Jeremy Parr wrote: > On 13 April 2010 00:12, Owen DeLong wrote: >> I stand corrected on the Mikrotik... Apparently, while not well documented, they >> do, indeed support IPv6 and their Wiki even includes tunnel configuration >> information. >> >> Apologies to Mikrotik (and some encouragement to add this to your main-line >> documentation). > > For better or worse, the Wiki *IS* their mainline documentation. Fair enough... My point is that http://wiki.mikrotik.com/wiki/Category:Manual#list Contains no mention whatsoever of IPv6. If you go, for example, to the Static IP Addressing page from there, there is also no mention of IPv6. It would be nice if they made IPv6 easier to find in the same places you would find the corresponding IPv4 information. Owen From dmburgess at linktechs.net Tue Apr 13 09:23:40 2010 From: dmburgess at linktechs.net (Dennis Burgess) Date: Tue, 13 Apr 2010 09:23:40 -0500 Subject: Router for Metro Ethernet References: <91522911795E174F97E7EF8B792A1031228980@ltiserver.LTI.local> <2943D53D-2716-4170-9E54-0955D065FEDA@delong.com> Message-ID: <91522911795E174F97E7EF8B792A10312289A8@ltiserver.LTI.local> Actually, the latest version 5 adds IP6 over PPP, I don't know where you got that they are not capable of routing IPv6. Just have to install the V6 package. ----------------------------------------------------------- Dennis Burgess, CCNA, Mikrotik Certified Trainer, MTCNA, MTCRE, MTCWE, MTCTCE, MTCUME Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, April 12, 2010 8:42 PM To: Dennis Burgess Cc: Jeffrey Negro; nanog at nanog.org Subject: Re: Router for Metro Ethernet Yes, but, according to the Mikrotik web site they appear to be obsolete and incapable of routing IPv6. Owen On Apr 12, 2010, at 10:32 AM, Dennis Burgess wrote: > a PowerRouter at http://www.mikrotikrouter.com can handle several > hundred meg without issues. > > ----------------------------------------------------------- > Dennis Burgess, CCNA, Mikrotik Certified Trainer, MTCNA, MTCRE, MTCWE, > MTCTCE, MTCUME > Link Technologies, Inc -- Mikrotik & WISP Support Services > Office: 314-735-0270 Website: http://www.linktechs.net > LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" > > > -----Original Message----- > From: Jeffrey Negro [mailto:jnegro at billtrust.com] > Sent: Monday, April 12, 2010 12:29 PM > To: nanog at nanog.org > Subject: Router for Metro Ethernet > > Before I get taken for a ride by salespeople, I figured it would be best > to > ask the experts of Nanog.... > > My company is currently in talks to bring an ethernet circuit into our > headquarters, initially committing around 40Mbps. The ISP will be > providing > ethernet handoff, but I do not want their managed router offering > (Adtran > 4430) since it is pricey, non-redundant and I'd rather manage it myself. > My > question is about hardware. Can I assume that I can use something like > a > Cisco 2000 series router with two built in fast/gig ethernet ports, > without > a WIC? and since both sides are ethernet would the routing throughput > be > near fast ethernet speed? This is my first dealing with metro ethernet > offerings, and I don't want to assume that the Cisco throughput rates > listed > for T1/ADSL etc. are the same for a metro ethernet as the WAN. > > Any and all suggestions on the hardware would be greatly appreciated. > Thank > you in advance! From dmburgess at linktechs.net Tue Apr 13 09:24:58 2010 From: dmburgess at linktechs.net (Dennis Burgess) Date: Tue, 13 Apr 2010 09:24:58 -0500 Subject: Router for Metro Ethernet References: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> Message-ID: <91522911795E174F97E7EF8B792A10312289A9@ltiserver.LTI.local> They just added IPv6 over PPP Support in v5 too :) ----------------------------------------------------------- Dennis Burgess, CCNA, Mikrotik Certified Trainer, MTCNA, MTCRE, MTCWE, MTCTCE, MTCUME Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, April 12, 2010 11:13 PM To: frnkblk at iname.com Cc: nanog at nanog.org; 'Bill Stewart' Subject: Re: Router for Metro Ethernet I stand corrected on the Mikrotik... Apparently, while not well documented, they do, indeed support IPv6 and their Wiki even includes tunnel configuration information. Apologies to Mikrotik (and some encouragement to add this to your main-line documentation). Owen On Apr 12, 2010, at 8:56 PM, Frank Bulk wrote: > We run a 3845 at over 300 Mbps and it's less than 50% CPU....most times less > than 30%. No BGP, just OSPF. > > Frank > > -----Original Message----- > From: Bill Stewart [mailto:nonobvious at gmail.com] > Sent: Monday, April 12, 2010 1:27 PM > To: nanog at nanog.org > Subject: Re: Router for Metro Ethernet > > On Mon, Apr 12, 2010 at 10:55 AM, Dylan Ebner > wrote: >> However, this router also has 2 100mb connections from local lans that it > is also terminiating. >> For our 100mb metro e connections we use 3845s. The 100 mb service > terminates into NM-GEs, which have a faster throughput than the hwics. > > Be careful using 3845s for 100 Mbps connections or above - Cisco rates > them at 45 Mbps (and 3825 at half of that) but last time I checked > doesn't make any promises at faster than T3. They're being > conservative about it, but one thing that really can burn the > horsepower is traffic shaping, which you need with some MetroE > carriers. > > > -- > ---- > Thanks; Bill > > Note that this isn't my regular email account - It's still experimental so > far. > And Google probably logs and indexes everything you send it. > > From dholmes at mwdh2o.com Tue Apr 13 13:06:56 2010 From: dholmes at mwdh2o.com (Holmes,David A) Date: Tue, 13 Apr 2010 11:06:56 -0700 Subject: Router for Metro Ethernet In-Reply-To: References: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E0AE01686@usmsxt104.mwd.h2o> We use Cisco 3750 L3 switches for Metro Ethernet connectivity. The 3750 SFPs can run at wire speed up to 1 GiGE. The 3750s are very reliable, and have good, follow-the-sun technical support in case of problems. Some caveats: 1. only the ME version supports MPLS, in case you want to overlay an MPLS TE/VPN network on a Metro Ethernet Forum (MEF) ELAN raw Ethernet service. 2. If you are using IP multicast, make sure that the Metro Ethernet provider supports PIM snooping, otherwise (S,G) directed multicast packets will be flooded out all service provider ports that connect to your devices, emulating a 1993-style Ethernet hub. -----Original Message----- From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] Sent: Monday, April 12, 2010 9:43 PM To: Jeffrey Negro Cc: nanog at nanog.org Subject: Re: Router for Metro Ethernet On Mon, 12 Apr 2010, Jeffrey Negro wrote: > In our case I believe we would be dealing with just static routes and a > lines of ACL. Do you think the routing protocols are your largest resource > usage in your scenario, or is it also just simple routing as well? Get a used 3550 or a new 3400ME or something. Sounds likeyuou'll get by just fine using an L3 switch. -- Mikael Abrahamsson email: swmike at swm.pp.se From nicotine at warningg.com Tue Apr 13 13:21:04 2010 From: nicotine at warningg.com (Brandon Ewing) Date: Tue, 13 Apr 2010 13:21:04 -0500 Subject: Router for Metro Ethernet In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E0AE01686@usmsxt104.mwd.h2o> References: <485ED9BA02629E4BBBA53AC892EDA50E0AE01686@usmsxt104.mwd.h2o> Message-ID: <20100413182104.GA30664@radiological.warningg.com> On Tue, Apr 13, 2010 at 11:06:56AM -0700, Holmes,David A wrote: > We use Cisco 3750 L3 switches for Metro Ethernet connectivity. The 3750 > SFPs can run at wire speed up to 1 GiGE. The 3750s are very reliable, > and have good, follow-the-sun technical support in case of problems. If you do not need MPLS, and do not need the StackWise ports on 3750s, the 3560 is the same switch, minus the stackwise ports, and ~33% cheaper. -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From positivelyoptimistic at gmail.com Tue Apr 13 15:05:57 2010 From: positivelyoptimistic at gmail.com (Positively Optimistic) Date: Tue, 13 Apr 2010 16:05:57 -0400 Subject: Mikrotik RouterOS In-Reply-To: <87pr23g1sf.fsf@nemi.mork.no> References: <4BC36C83.7040200@freedomnet.co.nz> <4BC36E27.4000005@gmail.com> <4BC37928.5030004@Janoszka.pl> <87pr23g1sf.fsf@nemi.mork.no> Message-ID: We use mikrotik in several enterprise networks and on our carrier ethernet network. We use their routerboard products as CPE in a lot of customer environments. They have a failure rate.. as does Cisco, Adtran, etc. IMHO, any device that depends on a wall wart for a power supply, is subject to occasional failure.. However, we've had as many adtran total access products fail as we've had mikrotik routerboards fail.. The powerrouter product that Dennis has referred to, although he may be more biased than I, is a solid product that I personally feel is carrier grade. Especially with redundant power or a DC power option.. I'm far from an expert in cisco or mikrotik, however, to accomplish the same end result with Cisco that is possible with Mikrotik, the cost is exponentially greater,.. Disclaimer.. I have zero financial interest in Mikrotik. Simply a loyal customer. On Tue, Apr 13, 2010 at 5:05 AM, Bj?rn Mork wrote: > Grzegorz Janoszka writes: > > On 12-4-2010 21:44, Gustavo Santos wrote: > >> its was an old bug, that had been fixed for a while.. > > > > You should still keep in mind Mikrotik is just Linux, with all its > > (dis)advantages, plus some scripts and weird CLI. > > Just like IOS XE... > > > > Bj?rn > > From rubensk at gmail.com Tue Apr 13 16:23:39 2010 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 13 Apr 2010 18:23:39 -0300 Subject: Router for Metro Ethernet In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E0AE01686@usmsxt104.mwd.h2o> References: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> <485ED9BA02629E4BBBA53AC892EDA50E0AE01686@usmsxt104.mwd.h2o> Message-ID: On Tue, Apr 13, 2010 at 3:06 PM, Holmes,David A wrote: > We use Cisco 3750 L3 switches for Metro Ethernet connectivity. The 3750 > SFPs can run at wire speed up to 1 GiGE. The 3750s are very reliable, > and have good, follow-the-sun technical support in case of problems. > Some caveats: > > 1. only the ME version supports MPLS, in case you want to overlay an > MPLS TE/VPN network on a Metro Ethernet Forum (MEF) ELAN raw Ethernet > service. The MPLS implementation of Cisco 3750 Metro is buggy enough to the point that I recommend it to all my friend's competitors (TM of Randy Bush). On the other side, Cisco ME6500 has MPLS (with some limitations usually accepted with L3 switches) and it works pretty good. It's not cheap, though. Rubens From mrz at velvet.org Tue Apr 13 16:33:07 2010 From: mrz at velvet.org (matthew zeier) Date: Tue, 13 Apr 2010 14:33:07 -0700 Subject: conference bandwidth (Whistler) Message-ID: <9CDE2322-695E-41CF-87CA-43B56DC1BE13@velvet.org> I'll be hosting a 500 person conference in Whistler this July. The hotel we're looking at only has a 30Mbps pipe from Telus. Looking for recommendations on someone who can get me 100Mbps for a week. - mz From tim at broadlinenetworks.com Tue Apr 13 16:40:15 2010 From: tim at broadlinenetworks.com (Tim Lampman) Date: Tue, 13 Apr 2010 17:40:15 -0400 Subject: conference bandwidth (Whistler) In-Reply-To: <9CDE2322-695E-41CF-87CA-43B56DC1BE13@velvet.org> References: <9CDE2322-695E-41CF-87CA-43B56DC1BE13@velvet.org> Message-ID: <4BC4E4BF.1030302@broadlinenetworks.com> Probably your only options for something short term like that would be telus or shaw. I would contact them both directly or perhaps go through the account that has the hotel connection. matthew zeier wrote: > I'll be hosting a 500 person conference in Whistler this July. The hotel we're looking at only has a 30Mbps pipe from Telus. > > Looking for recommendations on someone who can get me 100Mbps for a week. > > - mz > > -- Tim Lampman Co-Owner/CTO *Broadline Networks Inc.* 57 Colborne Street West, Brantford, ON, N3T 1K6 *p.* 1-866-546-8486 *c.* 905-746-3114 www.broadlinenetworks.com | tim at broadlinenetworks.com From leo.vegoda at icann.org Tue Apr 13 17:46:43 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 13 Apr 2010 15:46:43 -0700 Subject: 14/8 and 223/8 allocated to APNIC Message-ID: <5CEDF3B9-67FC-469F-8D71-5CCF92749796@icann.org> Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to APNIC in April 2010: 14/8 and 223/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. The IANA free pool contains 20 unallocated unicast IPv4 /8s. Regards, Leo Vegoda Number Resources Manager, IANA ICANN From dmburgess at linktechs.net Tue Apr 13 18:30:57 2010 From: dmburgess at linktechs.net (Dennis Burgess) Date: Tue, 13 Apr 2010 18:30:57 -0500 Subject: conference bandwidth (Whistler) References: <9CDE2322-695E-41CF-87CA-43B56DC1BE13@velvet.org> Message-ID: <91522911795E174F97E7EF8B792A10312289E6@ltiserver.LTI.local> Don't forget to contact the local WISP, they may have big pipes already in the area! ----------------------------------------------------------- Dennis Burgess, CCNA, A+, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" -----Original Message----- From: matthew zeier [mailto:mrz at velvet.org] Sent: Tuesday, April 13, 2010 4:33 PM To: nanog at nanog.org Subject: conference bandwidth (Whistler) I'll be hosting a 500 person conference in Whistler this July. The hotel we're looking at only has a 30Mbps pipe from Telus. Looking for recommendations on someone who can get me 100Mbps for a week. - mz From feldman at twincreeks.net Tue Apr 13 20:06:58 2010 From: feldman at twincreeks.net (Steve Feldman) Date: Tue, 13 Apr 2010 18:06:58 -0700 Subject: [NANOG-announce] The Evolution of NANOG In-Reply-To: <190783.4621.qm@web44710.mail.sp1.yahoo.com> References: <190783.4621.qm@web44710.mail.sp1.yahoo.com> Message-ID: <7BA54D81-F3D6-4ED1-8D9C-F6905FD5E331@twincreeks.net> Dear members of the NANOG community, Since its inception in 1994, the North American Network Operators Group (NANOG) has had its meetings and activities organized under the auspices of Merit, providing an incredible service to the North American region, and in fact, to the global Internet engineering community. The value of this work can not be easily overstated ? it is likely that, absent Merit?s involvement, the pace of global Internet development would have significantly slowed and that the high levels of Internet performance that we all enjoy today would not have come to pass. Several periods of evolution have marked the Merit/NANOG relationship. The most significant inflections have been the sharp growth in NANOG attendance in the late 1990s, the increasing importance of the NANOG mailing list as a method of inter-carrier communication, the utilization of NANOG meetings as a conduit of communications between major government entities and the Internetworking community, and the 2004-2005 Charter Process where NANOG took a significant step towards self-governance while remaining a Merit activity. Through the successive evolutions, Merit has stayed loyal to the ideals of NANOG, providing staff to administer conferences; administer servers to host presentations, mailing lists, and archives from the early days of the Internet; funds to pay for all of NANOG?s activities; and, equally as important, entering into contract obligations on NANOG?s behalf for meeting venue hotels, at times taking on significant contract liability. Since the beginning of this relationship, one constant has been the gratitude of NANOG?s membership and governance communities towards Merit for their dedication, hard work and financial commitment. Starting from the ratification of the 2005 NANOG Charter, the membership of NANOG has worked hard to establish self-governance institutions including our Steering Committee, Program Committee, Communications Committee, and Marketing Working Group. These institutions have acquired experience and resilience over the past five years and matured to the point of self-governance. The Steering Committee believes the time has come for NANOG to continue its natural evolution toward an independent organization. We are therefore beginning the process of creating a non-profit, tax- exempt entity that will produce NANOG conferences, administer the NANOG mailing list, and expand our educational mission. A re- structuring of the NANOG/Merit relationship allows each organization to focus on the direct needs of its respective constituency. This effort is still in the preliminary stages. Our intention is to work jointly with Merit to devise a transition plan and a transition timeline before NANOG 49 in June of this year. This transition will be gradual and designed to ensure a seamless handover of responsibility to the new entity, minimizing changes seen by the community as a whole. The governance and committee structure will be left largely intact, with our current charter converted into a set of governing bylaws. We expect to hold a community vote to ratify the new bylaws and structure during the annual October election. We expect there will be many questions and concerns raised regarding this process, and suggest that the nanog-futures mailing list is the appropriate venue for discussion. (See https://mailman.nanog.org/mailman/listinfo/nanog-futures for subscription information.) We also encourage you to share reactions directly with the Steering Committee. In the next few days, the Communications Committee will create and post a Frequently Asked Questions page. We will also hold an extended community meeting during NANOG 49 to review progress and discuss the transition. One thing that won?t change throughout the course of this next evolution is the gratitude of the NANOG membership for the hard work and support that the Merit board, staff, and member institutions have provided to us over the course of the last 16 years. For the NANOG leadership, Steve Feldman (Steering Committee chair) Patrick W. Gilmore (SC member) Sylvie LaPerri?re (SC member) Joe Provo (SC member) Robert Seastrom (SC member) Duane Wessels (SC member) David Meyer (Program Committee chair) Tom Daly (PC vice chair) _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From tvarriale at comcast.net Tue Apr 13 23:12:25 2010 From: tvarriale at comcast.net (Tony Varriale) Date: Tue, 13 Apr 2010 23:12:25 -0500 Subject: Router for Metro Ethernet References: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> Message-ID: Cisco rates it at 256mbps which places it above a NPE-400. The 3825 says 179mbps on their spec sheet. Not sure where you are getting your numbers but they are way off. All of those numbers are straight forwarding with nothing turned on and 64 byte packets. That way you get a nice idea of what the CPU can do. tv ----- Original Message ----- From: "Bill Stewart" To: Sent: Monday, April 12, 2010 1:27 PM Subject: Re: Router for Metro Ethernet > On Mon, Apr 12, 2010 at 10:55 AM, Dylan Ebner > wrote: >> However, this router also has 2 100mb connections from local lans that it >> is also terminiating. >> For our 100mb metro e connections we use 3845s. The 100 mb service >> terminates into NM-GEs, which have a faster throughput than the hwics. > > Be careful using 3845s for 100 Mbps connections or above - Cisco rates > them at 45 Mbps (and 3825 at half of that) but last time I checked > doesn't make any promises at faster than T3. They're being > conservative about it, but one thing that really can burn the > horsepower is traffic shaping, which you need with some MetroE > carriers. > > > -- > ---- > Thanks; Bill > > Note that this isn't my regular email account - It's still experimental so > far. > And Google probably logs and indexes everything you send it. > From da.shi at 3z.ca Tue Apr 13 23:20:14 2010 From: da.shi at 3z.ca (Da Shi) Date: Wed, 14 Apr 2010 00:20:14 -0400 Subject: Router for Metro Ethernet In-Reply-To: References: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> Message-ID: plz dont go with 3825/3845 unless you need it for voice etc. we have clients run 3825/3845 and they don't work properly beyond 50mbps with traffic shaping. On Wed, Apr 14, 2010 at 12:12 AM, Tony Varriale wrote: > Cisco rates it at 256mbps which places it above a NPE-400. > > The 3825 says 179mbps on their spec sheet. ?Not sure where you are getting > your numbers but they are way off. > > All of those numbers are straight forwarding with nothing turned on and 64 > byte packets. ?That way you get a nice idea of what the CPU can do. > > tv > ----- Original Message ----- From: "Bill Stewart" > To: > Sent: Monday, April 12, 2010 1:27 PM > Subject: Re: Router for Metro Ethernet > > >> On Mon, Apr 12, 2010 at 10:55 AM, Dylan Ebner >> wrote: >>> >>> However, this router also has 2 100mb connections from local lans that it >>> is also terminiating. >>> For our 100mb metro e connections we use 3845s. The 100 mb service >>> terminates into NM-GEs, which have a faster throughput than the hwics. >> >> Be careful using 3845s for 100 Mbps connections or above - Cisco rates >> them at 45 Mbps (and 3825 at half of that) but last time I checked >> doesn't make any promises at faster than T3. ?They're being >> conservative about it, but one thing that really can burn the >> horsepower is traffic shaping, which you need with some MetroE >> carriers. >> >> >> -- >> ---- >> ? ? ? ? ? ?Thanks; ? ? Bill >> >> Note that this isn't my regular email account - It's still experimental so >> far. >> And Google probably logs and indexes everything you send it. >> > > > From Skeeve at eintellego.net Wed Apr 14 02:02:10 2010 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Wed, 14 Apr 2010 17:02:10 +1000 Subject: APNIC Allocated 14/8, 223/8 today Message-ID: <292AF25E62B8894C921B893B53A19D973974B781A9@BUSINESSEX.business.ad> Hey all, As the subject says, APNIC was allocated 14/8 and 223/8 today... which does seems a little close after 1/8 and 27/8 in January 2010 - since 1/8 hasn't started, I'm surprised about the new ones. Not sure why I haven't seen any announcements about it... just thought I'd break the news... ...Skeeve -- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- NOC, NOC, who's there? Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced. From bortzmeyer at nic.fr Wed Apr 14 02:06:59 2010 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 14 Apr 2010 09:06:59 +0200 Subject: APNIC Allocated 14/8, 223/8 today In-Reply-To: <292AF25E62B8894C921B893B53A19D973974B781A9@BUSINESSEX.business.ad> References: <292AF25E62B8894C921B893B53A19D973974B781A9@BUSINESSEX.business.ad> Message-ID: <20100414070659.GA25319@nic.fr> On Wed, Apr 14, 2010 at 05:02:10PM +1000, Skeeve Stevens wrote a message of 37 lines which said: > As the subject says, APNIC was allocated 14/8 and 223/8 today... Actually, it was a few days ago. > Not sure why I haven't seen any announcements about it... There have been announcements (here a mail from APNIC on the Sanog mailing list). -------------- next part -------------- An embedded message was scrubbed... From: Srinivas Chendi Subject: Two /8s allocated to APNIC from IANA (14/8 and 223/8) Date: Mon, 12 Apr 2010 15:18:12 +1000 Size: 6526 URL: From gih at apnic.net Wed Apr 14 04:08:14 2010 From: gih at apnic.net (Geoff Huston) Date: Wed, 14 Apr 2010 19:08:14 +1000 Subject: advertisements of 14/8 and 223/8 Message-ID: <3E3330CF-2F54-42C0-9DE8-C8D0B5C0C0AB@apnic.net> Hi, APNIC and NTT are cooperating in a project to investigate the properties of unwanted traffic that is being sent to specific destinations in the address blocks of 14.0.0.0/8 and 223.0.0.0/8. These address blocks have been recently allocated to APNIC from the IANA, and APNIC and NTT are wanting to undertake this investigation prior to the commencement of ordinary allocations. Accordingly, APNIC has authorized AS38639 to advertise routes for 14.0.0.0/8 and 223.0.0.0/8 from now until 26 April 2010, and requests that AS38639's peers and upstreams accept this as a legitimate routing advertisement. thanks, Geoff Huston APNIC From nick at foobar.org Wed Apr 14 04:20:43 2010 From: nick at foobar.org (Nick Hilliard) Date: Wed, 14 Apr 2010 10:20:43 +0100 Subject: APNIC Allocated 14/8, 223/8 today In-Reply-To: <20100414070659.GA25319@nic.fr> References: <292AF25E62B8894C921B893B53A19D973974B781A9@BUSINESSEX.business.ad> <20100414070659.GA25319@nic.fr> Message-ID: <4BC588EB.8000105@foobar.org> On 14/04/2010 08:06, Srinivas Chendi wrote: > APNIC received the following IPv4 address blocks from IANA in April > 2010 and will be making allocations from these ranges in the near > future: > > 014/8 > 223/8 Sunny, Please be careful about how you write this. "014" is formally an octal representation, and what you've written there actually means that APNIC has received 12/8 (= octal 014). Nick From allan.eising+gmane at gmail.com Wed Apr 14 04:46:06 2010 From: allan.eising+gmane at gmail.com (Allan Eising) Date: Wed, 14 Apr 2010 09:46:06 +0000 (UTC) Subject: Mikrotik RouterOS References: <4BC36C83.7040200@freedomnet.co.nz> Message-ID: On Mon, 12 Apr 2010 14:54:59 -0400, James Jones wrote: > I am currently looking at using RouterOS as a way to build a Metro > Ethernet solution. Does anyone have experience with the device and the > OS? How is the performance? Are there any "Gotchas"? > > > -James I've been working with RouterOS for a while, especially with it's more service provider oriented features such as MPLS and BGP. Here are some points that might help you: 1) Consider what device you want to run it on, especially regarding expected throughput. If you want to run it on x86 hardware, consider either buying one of the available x86 solutions, such as PoweRouter or OGMA connect, or spend some time evaluating that your hardware configuration is indeed supported. RouterOS is based on a 32-bit linux kernel, and it's not the newest one... The upcoming version 5 will feature a recent kernel, but is still 32bit, so don't expect things like multiqueue to work on your intel NICs. 2) Understand that bugs happen, and new software is released frequently. Acknowledge that there might be issues with quality assurance for new software versions. Expect to test new versions rigorously before rolling out. That said, MikroTik support is very friendly and will help you with most issues. 3) Their RouterBoard products are cheap, and are often made from the cheapest components. I have seen issues with faulty components. Recently, they EOL'd their only rack-mount router, the RB1000U, while the replacement - a cheaper router with more ports, and little less power - has not yet gone into sale. And now for all the good things: 4) Their MPLS support, as well as their implementations of routing protocols are quite good. They support both MPLS and VPLS and can even work with Cisco's BGP-signalled VPLS, as well as the rfc version of it. 5) The CLI is easy to work with, and has an excellent API that allows you to easily integrate provisioning into your existing systems. There is also a graphic tool called WinBox. This tool gives you a very easy overview of your router's configuration, so put away any CLI-only bias you might have inherited from working with other vendors. I consider their routers great for Metro Ethernet solutions on a lower scale. Their low cost makes it very easy to roll out an MPLS network, as the price for a PoP will be low, however keep an eye on the performance of the routers. You are welcome to contact me if you have any additional questions. Regards, Allan Eising From tim at pelican.org Wed Apr 14 05:07:28 2010 From: tim at pelican.org (Tim Franklin) Date: Wed, 14 Apr 2010 10:07:28 +0000 (GMT) Subject: Router for Metro Ethernet In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E0AE01686@usmsxt104.mwd.h2o> Message-ID: <25015904.01271239648918.JavaMail.root@jennyfur.pelican.org> > Some caveats: > > 1. only the ME version supports MPLS, in case you want to overlay an > MPLS TE/VPN network on a Metro Ethernet Forum (MEF) ELAN raw Ethernet > service. > 2. If you are using IP multicast, make sure that the Metro Ethernet > provider supports PIM snooping, otherwise (S,G) directed multicast > packets will be flooded out all service provider ports that connect > to > your devices, emulating a 1993-style Ethernet hub. 3. Only "switch-style" QoS, not full-blown MQC. The 3750ME has two "router" ports which do mostly support MQC, but still have some limitations (e.g. traffic locally sourced from the device is not correctly classified / marked). Which is all kind of what you'd expect from a switch, but may be relevent if the original question was "which router?" Regards, Tim. From tim at pelican.org Wed Apr 14 05:11:49 2010 From: tim at pelican.org (Tim Franklin) Date: Wed, 14 Apr 2010 10:11:49 +0000 (GMT) Subject: Router for Metro Ethernet In-Reply-To: <14864555.31271239750247.JavaMail.root@jennyfur.pelican.org> Message-ID: <21598548.51271239909317.JavaMail.root@jennyfur.pelican.org> > All of those numbers are straight forwarding with nothing turned on > and 64 > byte packets. That way you get a nice idea of what the CPU can do. They're also, as ever, unidirectional, so you can immediately halve them if your question is "what size pipe can I connect this device to?" As a VPN managed CE, with QoS, BGP, a little bit of IPSLA etc, I'm seeing a practical limit of around 70Mb/s bidirectional out of the 3845. Regards, Tim. From davehart at gmail.com Wed Apr 14 07:45:23 2010 From: davehart at gmail.com (Dave Hart) Date: Wed, 14 Apr 2010 12:45:23 +0000 Subject: APNIC Allocated 14/8, 223/8 today In-Reply-To: <4BC588EB.8000105@foobar.org> References: <292AF25E62B8894C921B893B53A19D973974B781A9@BUSINESSEX.business.ad> <20100414070659.GA25319@nic.fr> <4BC588EB.8000105@foobar.org> Message-ID: On Wed, Apr 14, 2010 at 09:20 UTC, Nick Hilliard wrote: > On 14/04/2010 08:06, Srinivas Chendi wrote to SANOG: >> ? ? 014/8 >> ? ? 223/8 > > Sunny, > > Please be careful about how you write this. "014" is formally an octal > representation, and what you've written there actually means that APNIC has > received 12/8 (= octal 014). > > Nick Nick, My eyebrow raised at the leading zero as well, but I'd call it ambiguous. 0x14 is unambiguously decimal 20, but 014 is only unambiguous in a context that defines leading zero as implying octal. For a C program relying on the runtime to convert text to numeric representation, it depends. sscanf("%d", &myint) will convert 014 to decimal 14, "%i" gets decimal 12. I personally hunt down and kill %i and other octal-assuming code when I see it, except where octal is conventional. To my eyes, 0xFF (or FF) screams "all bits lit" while 0377 (or 377) only hesitantly clears its throat. Moreover, I assume computers will be used by people who have never had reason to believe a leading zero implies base 8, and I find no joy in forcing them to learn that quirk of computing history. Take care, Dave Hart From jabley at hopcount.ca Wed Apr 14 09:35:10 2010 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 14 Apr 2010 10:35:10 -0400 Subject: APNIC Allocated 14/8, 223/8 today In-Reply-To: References: <292AF25E62B8894C921B893B53A19D973974B781A9@BUSINESSEX.business.ad> <20100414070659.GA25319@nic.fr> <4BC588EB.8000105@foobar.org> Message-ID: <3B891736-7081-4224-AC08-2BDF58E46C4B@hopcount.ca> On 2010-04-14, at 08:45, Dave Hart wrote: > My eyebrow raised at the leading zero as well, but I'd call it > ambiguous. 0x14 is unambiguously decimal 20, but 014 is only > unambiguous in a context that defines leading zero as implying octal. Note that such a context is inet_ntoa(), at least on BSD-based machines I have handy. From inet(3): All numbers supplied as ``parts'' in a `.' notation may be decimal, octal, or hexadecimal, as specified in the C language (i.e., a leading 0x or 0X implies hexadecimal; otherwise, a leading 0 implies octal; other- wise, the number is interpreted as decimal). Given the popularity of Octal in address nomenclature in 2010 this seems like a small problem for mail to NANOG. However, if the practice extends to use in contexts which might be machine-readable (e.g. in text files which are auto-curl(1)d out of cron to build filters) then there is potential for hilarity. Joe From jhary at unsane.co.uk Wed Apr 14 09:35:28 2010 From: jhary at unsane.co.uk (Vincent Hoffman) Date: Wed, 14 Apr 2010 15:35:28 +0100 Subject: APNIC Allocated 14/8, 223/8 today In-Reply-To: References: <292AF25E62B8894C921B893B53A19D973974B781A9@BUSINESSEX.business.ad> <20100414070659.GA25319@nic.fr> <4BC588EB.8000105@foobar.org> Message-ID: <4BC5D2B0.6000404@unsane.co.uk> On 14/04/2010 13:45, Dave Hart wrote: > On Wed, Apr 14, 2010 at 09:20 UTC, Nick Hilliard wrote: > >> On 14/04/2010 08:06, Srinivas Chendi wrote to SANOG: >> >>> 014/8 >>> 223/8 >>> >> Sunny, >> >> Please be careful about how you write this. "014" is formally an octal >> representation, and what you've written there actually means that APNIC has >> received 12/8 (= octal 014). >> >> Nick >> > Nick, > > My eyebrow raised at the leading zero as well, but I'd call it > ambiguous. 0x14 is unambiguously decimal 20, but 014 is only > unambiguous in a context that defines leading zero as implying octal. > For a C program relying on the runtime to convert text to numeric > representation, it depends. sscanf("%d", &myint) will convert 014 to > decimal 14, "%i" gets decimal 12. > > I personally hunt down and kill %i and other octal-assuming code when > I see it, except where octal is conventional. To my eyes, 0xFF (or > FF) screams "all bits lit" while 0377 (or 377) only hesitantly clears > its throat. Moreover, I assume computers will be used by people who > have never had reason to believe a leading zero implies base 8, and I > find no joy in forcing them to learn that quirk of computing history. > On an up to date OSX install (and Centos linux and FreeBSD) (15:23:17 <~>) 0 $ ping 014.0.0.1 PING 014.0.0.1 (12.0.0.1): 56 data bytes Request timeout for icmp_seq 0 >From windows 2003 servert C:\Documents and Settings\Administrator>ping 014.0.0.01 Pinging 12.0.0.1 with 32 bytes of data: wget (on linux and freebsd) (15:26:02 <~>) 0 $ wget 014.0.0.1 --2010-04-14 15:26:06-- http://014.0.0.1/ Connecting to 014.0.0.1|12.0.0.1|:80... Oddly on OSX it doesnt take it as octal (15:27:30 <~>) 130 $ wget 014.0.0.1 --2010-04-14 15:27:31-- http://014.0.0.1/ Connecting to 014.0.0.1 (014.0.0.1)|14.0.0.1|:80... When it comes to IP addresses, its not history, its important :) Vince > Take care, > Dave Hart > From LarrySheldon at cox.net Wed Apr 14 09:48:29 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 14 Apr 2010 09:48:29 -0500 Subject: APNIC Allocated 14/8, 223/8 today In-Reply-To: <4BC5D2B0.6000404@unsane.co.uk> References: <292AF25E62B8894C921B893B53A19D973974B781A9@BUSINESSEX.business.ad> <20100414070659.GA25319@nic.fr> <4BC588EB.8000105@foobar.org> <4BC5D2B0.6000404@unsane.co.uk> Message-ID: <4BC5D5BD.1030809@cox.net> On 4/14/2010 09:35, Vincent Hoffman wrote: > On 14/04/2010 13:45, Dave Hart wrote: >> On Wed, Apr 14, 2010 at 09:20 UTC, Nick Hilliard wrote: >> >>> On 14/04/2010 08:06, Srinivas Chendi wrote to SANOG: >>> >>>> 014/8 >>>> 223/8 >>>> >>> Sunny, >>> >>> Please be careful about how you write this. "014" is formally an octal >>> representation, and what you've written there actually means that APNIC has >>> received 12/8 (= octal 014). >>> >>> Nick >>> >> Nick, >> >> My eyebrow raised at the leading zero as well, but I'd call it >> ambiguous. 0x14 is unambiguously decimal 20, but 014 is only >> unambiguous in a context that defines leading zero as implying octal. >> For a C program relying on the runtime to convert text to numeric >> representation, it depends. sscanf("%d", &myint) will convert 014 to >> decimal 14, "%i" gets decimal 12. >> >> I personally hunt down and kill %i and other octal-assuming code when >> I see it, except where octal is conventional. To my eyes, 0xFF (or >> FF) screams "all bits lit" while 0377 (or 377) only hesitantly clears >> its throat. Moreover, I assume computers will be used by people who >> have never had reason to believe a leading zero implies base 8, and I >> find no joy in forcing them to learn that quirk of computing history. >> > > On an up to date OSX install (and Centos linux and FreeBSD) > (15:23:17 <~>) 0 $ ping 014.0.0.1 > PING 014.0.0.1 (12.0.0.1): 56 data bytes > Request timeout for icmp_seq 0 > >>From windows 2003 servert > > C:\Documents and Settings\Administrator>ping 014.0.0.01 > Pinging 12.0.0.1 with 32 bytes of data: > > > wget (on linux and freebsd) > > (15:26:02 <~>) 0 $ wget 014.0.0.1 > --2010-04-14 15:26:06-- http://014.0.0.1/ > Connecting to 014.0.0.1|12.0.0.1|:80... > > Oddly on OSX it doesnt take it as octal > (15:27:30 <~>) 130 $ wget 014.0.0.1 > --2010-04-14 15:27:31-- http://014.0.0.1/ > Connecting to 014.0.0.1 (014.0.0.1)|14.0.0.1|:80... > > > When it comes to IP addresses, its not history, its important :) I think it is important form us to recognize and accept that this is 2010. The Constitution means what ever the speaker needs for it to mean, or can be dismissed outright. 014 means what ever the speaker needs for it to mean..... It is the duty and responsibility of the hearer (or reader) to figure out how it applies to them for the moment. Standards and agreements on protocol are so eighteenth century. > > Vince >> Take care, >> Dave Hart Dark Ages Larry -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From davehart at gmail.com Wed Apr 14 09:54:11 2010 From: davehart at gmail.com (Dave Hart) Date: Wed, 14 Apr 2010 14:54:11 +0000 Subject: APNIC Allocated 14/8, 223/8 today In-Reply-To: <4BC5D2B0.6000404@unsane.co.uk> References: <292AF25E62B8894C921B893B53A19D973974B781A9@BUSINESSEX.business.ad> <20100414070659.GA25319@nic.fr> <4BC588EB.8000105@foobar.org> <4BC5D2B0.6000404@unsane.co.uk> Message-ID: On Wed, Apr 14, 2010 at 14:35 UTC, Vincent Hoffman wrote: > PING 014.0.0.1 (12.0.0.1): 56 data bytes > C:\Documents and Settings\Administrator>ping 014.0.0.01 > Pinging 12.0.0.1 with 32 bytes of data: > Connecting to 014.0.0.1|12.0.0.1|:80... > Connecting to 014.0.0.1 (014.0.0.1)|14.0.0.1|:80... > > When it comes to IP addresses, its not history, its important :) Good point. In most of these classic utility contexts, octal is generally accepted. 32-bit unsigned decimal representation has provided obfuscation for fun and profit in HTTP URIs. I'm sure you can find some software that still accepts it, and some that doesn't. For me, with no proxy, Chrome and IE both accept a non-dotted numeric IPv4 URI, but rewrite it in the address bar to the familiar dotted quad format. FireFox shows an error page that appears equivalent to:

Bad Request (Invalid Hostname)

FireFox is probably violating some spec. Thankfully. Cheers, Dave Hart From nonobvious at gmail.com Wed Apr 14 10:22:44 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Wed, 14 Apr 2010 08:22:44 -0700 Subject: Router for Metro Ethernet In-Reply-To: References: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> Message-ID: On Tue, Apr 13, 2010 at 9:12 PM, Tony Varriale wrote: > > From: "Bill Stewart" > > Be careful using 3845s for 100 Mbps connections or above > The 3825 says 179mbps on their spec sheet. ?Not sure where you are getting > your numbers but they are way off. > All of those numbers are straight forwarding with nothing turned on and 64 > byte packets. ?That way you get a nice idea of what the CPU can do. That's the spec sheet, and that's for straight forwarding. If you want to do much of anything else at all with the router, Cisco has another web page that says they only recommend 45Mbps on the 3845 and something like half that on the 3825. It's especially an issue if you need to do traffic-shaping, which you usually do for MetroE. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From lowen at pari.edu Wed Apr 14 11:49:28 2010 From: lowen at pari.edu (Lamar Owen) Date: Wed, 14 Apr 2010 12:49:28 -0400 Subject: alt.folklore.nanog (was:Re: Commodore PET, was: Re: legacy /8) In-Reply-To: <4BC1A1F4.9010801@mompl.net> References: Message-ID: <201004141249.28255.lowen@pari.edu> On Sunday 11 April 2010 06:18:28 am Jeroen van Aart wrote: > According to the book "On the edge" by Brian Bagnall the first showing > was in March 1977. In January of 1977 it was announced at the CES. .... It > was shown to John Roach, then an operations guy of Rat > Shack. He was interested to have it distributed in their stores but > because Jack Tramiel also demanded they'd order a lot of Commodore's > calculators John Roach didn't go through with the deal and decided they > could make their own... missed opportunities. While this isn't alt.folklore.computers, I have a minor correction (and a lead-in to a question about early IP routers): According to the book 'Priming the Pump: How TRS-80 Enthusiasts Helped Spark the PC Revolution' the prototype TRS-80 was shown to Charles Tandy on Groundhog Day, February 2, 1977. One of the great engineering stories of our time is that of Steve Leininger, who is the person responsible for the design and construction of the prototype. It was announced to the public on August 3, 1977, and sold a quarter of a million units over its lifetime (talking about the 'Model I' only). IOW, the TRS-80 was already in design before the PET was shown to John Roach; that's the minor correction. Three Steves (Leininger, Wozniak, Jobs.... others?) at the lead-in of the microcomputer (and thus the Internet) age. Along those lines (and the primary reason I reply), does anyone here have any Proteon routers still in operation? I have three with full docs and those 80Mb/s ProNET over fiber links, and am wondering if they are at all useful in this day and age....if nothing else, the enclosure makes a nice shielded rack box....Hey, I hate to see gear sit on the shelf unused, regardless of how old it is! From ASTONGE at travelers.com Wed Apr 14 13:13:46 2010 From: ASTONGE at travelers.com (St. Onge,Adam) Date: Wed, 14 Apr 2010 14:13:46 -0400 Subject: Undersea cable cut? Message-ID: <768FB653686AE54A9B4FB9A1503F03F51C9BFF502A@TENK7MVB.prod.travp.net> Seeing a serious uptick in latency to India from North America and am hearing reports of an undersea cable cut in the Mediterranean? Has anyone else heard something similar? Thanks, Adam ============================================================================== This communication, including attachments, is confidential, may be subject to legal privileges, and is intended for the sole use of the addressee. Any use, duplication, disclosure or dissemination of this communication, other than by the addressee, is prohibited. If you have received this communication in error, please notify the sender immediately and delete or destroy this communication and all copies. From copraphage at gmail.com Wed Apr 14 13:18:49 2010 From: copraphage at gmail.com (Chris McDonald) Date: Wed, 14 Apr 2010 14:18:49 -0400 Subject: Undersea cable cut? In-Reply-To: <768FB653686AE54A9B4FB9A1503F03F51C9BFF502A@TENK7MVB.prod.travp.net> References: <768FB653686AE54A9B4FB9A1503F03F51C9BFF502A@TENK7MVB.prod.travp.net> Message-ID: There's a cut in SWM4 *SMW4 Segment 4.1 cable fault* Cable shunt fault developed on SMW4 segment 4.1 (Egypt / Alexandria ? Branching Unit #4A onward France / Marseilles) at 07:15GMT on 14-Apr. 2010. However the shunt fault has further deteriorated and the cable segment was down at 10:03GMT. Only four unprotected Singapore ? London / Frankfurt STM-4c IP trunks were being affected. SMW4 NOC updated that there is a shunt fault in segment 4.1 between Egypt / Alexandria and France / Marseilles with cable fault on Fiber Pair #2 at 1886.152 km from Alexandria towards Palermo. The traffic landed at Palermo onwards to Europe was being affected, while the traffic running between Alexandria and Marseilles via Fiber Pair #1 is still maintained. On Wed, Apr 14, 2010 at 2:13 PM, St. Onge,Adam wrote: > Seeing a serious uptick in latency to India from North America and am > hearing reports of an undersea cable cut in the Mediterranean? Has anyone > else heard something similar? > > Thanks, > Adam > > > ============================================================================== > This communication, including attachments, is confidential, may be subject > to legal privileges, and is intended for the sole use of the addressee. Any > use, duplication, disclosure or dissemination of this communication, other > than by the addressee, is prohibited. If you have received this > communication in error, please notify the sender immediately and delete or > destroy this communication and all copies. > From lowen at pari.edu Wed Apr 14 13:29:28 2010 From: lowen at pari.edu (Lamar Owen) Date: Wed, 14 Apr 2010 14:29:28 -0400 Subject: Router for Metro Ethernet In-Reply-To: References: Message-ID: <201004141429.28681.lowen@pari.edu> On Monday 12 April 2010 01:28:45 pm Jeffrey Negro wrote: > Any and all suggestions on the hardware would be greatly appreciated. > Thank you in advance! Well, I've read through this thread as it's unfolded.... I repurposed some big hardware (that we already had on-hand) to terminate our metro ethernet connection, which replaced a point to point OC3. The carrier was easy to work with, and provisioned the local loop over 1000Base-LX, which I terminated on a 12008 (same router that previously terminated the OC3). Yep, overkill. Until I want IPv6, that is, and then the 1 port GE will be about right for a metro e at less than 100Mb/s bandwidth. And 12000's are beasts for HA. Now, 12000's aren't designed for edges, really, so there's no NAT and some other edge features. And it has a pretty weak CPU for the control plane, especially if it's a GRP. But if you happen to have one on hand..... A 7200 NPE-G1 or G2 would work, as would a 7400 if you don't mind older IOS. The 7400 is more than capable of 150Mb/s throughput with features; I have one that had previously terminated the other end of the OC3, which is still there, and still doing NAT and other edge features very well. I was able to saturate the OC3 when it was lit, with features turned on, and the 7400 churned through it quite well, with max CPU hitting 75% or so under the heaviest loads. If you have a 7500 series lying around you can go that route, too, as current 12.4 mainline is still there for the RSP platform. But the HA with 12.4 is not as robust as with 12.0S, and with 12.0S it acts more like a 12000 and less like an edge router. And even the RSP16's CPU is a little weak for heavy edge features. There's a lot of older Cisco kit that will handle 40Mb/s quite well. And, well, Cisco gear is built better than most 'industrial' x86 boxes out there (even if Cisco has shipped 'industrial' x86 boxes before, like the rebranded IBM x Series servers that were labeled 'Content Engines' and the PC's relabeled as LocalDirectors and PIXen of various models; the router platforms have, in my experience at least, been more reliable). As much as I like and use Linux (and I installed SLS from floppy tape back in the day), I rest easier at night with a 12008 terminating the circuit. From thomas at habets.pp.se Wed Apr 14 13:31:59 2010 From: thomas at habets.pp.se (Thomas Habets) Date: Wed, 14 Apr 2010 20:31:59 +0200 (CEST) Subject: APNIC Allocated 14/8, 223/8 today In-Reply-To: <3B891736-7081-4224-AC08-2BDF58E46C4B@hopcount.ca> References: <292AF25E62B8894C921B893B53A19D973974B781A9@BUSINESSEX.business.ad> <20100414070659.GA25319@nic.fr> <4BC588EB.8000105@foobar.org> <3B891736-7081-4224-AC08-2BDF58E46C4B@hopcount.ca> Message-ID: On Wed, 14 Apr 2010, Joe Abley wrote: > From inet(3): > All numbers supplied as ``parts'' in a `.' notation may be decimal, > octal, or hexadecimal, as specified in the C language (i.e., a leading 0x > or 0X implies hexadecimal; otherwise, a leading 0 implies octal; other- > wise, the number is interpreted as decimal). But note Theos reply about just this paragraph: "Yes, we should fix the manual page. Single Unix is wrong in this regard." -- http://kerneltrap.org/mailarchive/openbsd-bugs/2009/6/6/5882713/thread Also this from two months ago: http://www.merit.edu/mail.archives/nanog/msg05062.html Don't expect non-canonical IP address formats to work. Because they often don't. And you just might get silent errors. --------- typedef struct me_s { char name[] = { "Thomas Habets" }; char email[] = { "thomas at habets.pp.se" }; char kernel[] = { "Linux" }; char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt" }; char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854" }; char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" }; } me_t; From neil at tonal.clara.co.uk Wed Apr 14 18:02:20 2010 From: neil at tonal.clara.co.uk (Neil Harris) Date: Thu, 15 Apr 2010 00:02:20 +0100 Subject: APNIC Allocated 14/8, 223/8 today In-Reply-To: References: <292AF25E62B8894C921B893B53A19D973974B781A9@BUSINESSEX.business.ad> <20100414070659.GA25319@nic.fr> <4BC588EB.8000105@foobar.org> <4BC5D2B0.6000404@unsane.co.uk> Message-ID: <4BC6497C.6070801@tonal.clara.co.uk> On 14/04/10 15:54, Dave Hart wrote: > On Wed, Apr 14, 2010 at 14:35 UTC, Vincent Hoffman wrote: > >> PING 014.0.0.1 (12.0.0.1): 56 data bytes >> C:\Documents and Settings\Administrator>ping 014.0.0.01 >> Pinging 12.0.0.1 with 32 bytes of data: >> Connecting to 014.0.0.1|12.0.0.1|:80... >> Connecting to 014.0.0.1 (014.0.0.1)|14.0.0.1|:80... >> >> When it comes to IP addresses, its not history, its important :) >> > Good point. In most of these classic utility contexts, octal is > generally accepted. 32-bit unsigned decimal representation has > provided obfuscation for fun and profit in HTTP URIs. I'm sure you > can find some software that still accepts it, and some that doesn't. > For me, with no proxy, Chrome and IE both accept a non-dotted numeric > IPv4 URI, but rewrite it in the address bar to the familiar dotted > quad format. FireFox shows an error page that appears equivalent to: >

Bad Request (Invalid Hostname)

> > FireFox is probably violating some spec. Thankfully. > > Cheers, > Dave Hart > > > This is a historical issue with inet_aton(). See http://tools.ietf.org/html/draft-main-ipaddr-text-rep-00 for more details on the history behind this. Firefox bug 554596 addresses this problem. -- N. From joe.abley at icann.org Wed Apr 14 18:19:30 2010 From: joe.abley at icann.org (Joe Abley) Date: Wed, 14 Apr 2010 16:19:30 -0700 Subject: Root Zone DNSSEC Deployment Technical Status Update Message-ID: This is the fourth of a series of technical status updates intended to inform a technical audience on progress in signing the root zone of the DNS. RESOURCES Details of the project, including documentation published to date, can be found at http://www.root-dnssec.org/. We'd like to hear from you. If you have feedback for us, please send it to rootsign at icann.org. DOCUMENTATION The following draft document was recently published: - Resolver Testing with a DURZ - TCR - Proposed Approach to Root Key Management ICANN has begun the process of formally soliciting expressions of interest for volunteers from the technical community to act as Trusted Community Representatives. These volunteers will witness cryptographic key ceremonies and also carry out various important roles relating to KSK key management. For more information, see: http://www.icann.org/en/announcements/announcement-12apr10-en.htm Expressions of interest can be submitted here: http://www.root-dnssec.org/tcr/ DEPLOYMENT STATUS KSR exchanges continue between production platforms at VeriSign and ICANN. Build-out of KSK Key Ceremony facilities at ICANN continues, and both facilities (east- and west-coast USA) are expected to be ready on schedule. The incremental deployment of DNSSEC in the Root Zone is being carried out first by serving a Deliberately Unvalidatable Root Zone (DURZ), and subsequently by a conventionally signed root zone. Discussion of the approach can be found in the document "DNSSEC Deployment for the Root Zone", as well as in the technical presentations delivered at RIPE, NANOG, IETF and ICANN meetings. Twelve of the thirteen root servers have now made the transition to the DURZ. No harmful effects have been identified. Some early analysis of packet captures from many root servers surrounding each event was recently presented at the IETF meeting in Anaheim, CA, USA and can be found with other presentation materials at . PLANNED DEPLOYMENT SCHEDULE Already completed: 2010-01-27: L starts to serve DURZ 2010-02-10: A starts to serve DURZ 2010-03-03: M, I start to serve DURZ 2010-03-24: D, K, E start to serve DURZ 2010-04-14: B, H, C, G, F start to serve DURZ To come: 2010-05-05: J starts to serve DURZ 2010-07-01: Distribution of validatable, production, signed root zone; publication of root zone trust anchor (Please note that this schedule is tentative and subject to change based on testing results or other unforeseen factors.) A more detailed DURZ transition timetable with maintenance windows can be found in the document "DNSSEC Deployment for the Root Zone", the most recent draft of which can be found on the project web page at . From jeroen at mompl.net Wed Apr 14 19:04:21 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 14 Apr 2010 17:04:21 -0700 Subject: alt.folklore.nanog In-Reply-To: <201004141249.28255.lowen@pari.edu> References: <201004141249.28255.lowen@pari.edu> Message-ID: <4BC65805.7050705@mompl.net> Lamar Owen wrote: > and construction of the prototype. It was announced to the public on August > 3, 1977, and sold a quarter of a million units over its lifetime (talking > about the 'Model I' only). IOW, the TRS-80 was already in design before the > PET was shown to John Roach; that's the minor correction. Right, I believe the book was trying to say that the missed opportunity is that Commodore could have sold the original PET in Tandy's stores. I assume you were (as I was) wondering why the hell Tandy would have done that as it've been a competitor to the TRS-80. But then Commodore (having taken over MOS technologies) sold CPUs to their major competitors including Apple and Atari. So it's not unheard of. Regards, Jeroen From jjeffries at labs.net Wed Apr 14 21:02:47 2010 From: jjeffries at labs.net (jason jeffries) Date: Wed, 14 Apr 2010 22:02:47 -0400 Subject: comcast routing contact needed (wheeling/weirton, wv) Message-ID: <201004142202.AA1132069052@labs.net> Can a router-handy person with Comcast contact me off-list? We have a customer that is having problems between a branch office on our network, and their HQ's Comcast connection--seems like packets from (at least) one particular IP on their net here are going awry in Comcast somewhere. Thanks! jason jeffries - jjeffries at labs.net labyrinth solutions - as26097 From yoshida at nttv6.jp Thu Apr 15 12:32:39 2010 From: yoshida at nttv6.jp (Tomoya Yoshida) Date: Fri, 16 Apr 2010 02:32:39 +0900 Subject: advertisements of 14/8 and 223/8 In-Reply-To: <3E3330CF-2F54-42C0-9DE8-C8D0B5C0C0AB@apnic.net> References: <3E3330CF-2F54-42C0-9DE8-C8D0B5C0C0AB@apnic.net> Message-ID: <20100416010159.AC87.9C4C12A4@nttv6.jp> Hi, I started to advertise for test two /8s and in addition to collecting of unwanted traffic I checked the status of route-views of these two /8s including two experimental prefixes in 27/8 which is allocated to APNIC on Jan 2010 and old 115/8 space. http://www.nttv6.jp/~yoshida/bogon_rviews_20100415_yoshida.pdf For 27/8, It seemse that some ISP still dosen't update their filter or dosen't advertise to route-views by some reasons. Now I'm using 27/8 space and I found that there is no reachability about 10% ASes, at least 2,000 ASes as our test, It can't be said the good situation at all. I will continue to test this month and would like to share about the result somewhere. Also the interesting result is that there is differences between 14/8 and 223/8 on route-views result. Do you have any idea? -tomoya On Wed, 14 Apr 2010 19:08:14 +1000 Geoff Huston wrote: |Hi, | |APNIC and NTT are cooperating in a project to investigate the properties of unwanted traffic that is being sent to specific destinations in the address blocks of 14.0.0.0/8 and 223.0.0.0/8. These address blocks have been recently allocated to APNIC from the IANA, and APNIC and NTT are wanting to undertake this investigation prior to the commencement of ordinary allocations. Accordingly, APNIC has authorized AS38639 to advertise routes for 14.0.0.0/8 and 223.0.0.0/8 from now until 26 April 2010, and requests that AS38639's peers and upstreams accept this as a legitimate routing advertisement. | |thanks, | | Geoff Huston | APNIC -- Tomoya Yoshida From r.bhatia at ipax.at Thu Apr 15 14:37:28 2010 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Thu, 15 Apr 2010 21:37:28 +0200 Subject: advertisements of 14/8 and 223/8 In-Reply-To: <20100416010159.AC87.9C4C12A4@nttv6.jp> References: <3E3330CF-2F54-42C0-9DE8-C8D0B5C0C0AB@apnic.net> <20100416010159.AC87.9C4C12A4@nttv6.jp> Message-ID: <4BC76AF8.6020206@ipax.at> On 15.04.2010 19:32, Tomoya Yoshida wrote: > For 27/8, It seemse that some ISP still dosen't update > their filter or dosen't advertise to route-views by some reasons. > Now I'm using 27/8 space and I found that there is no reachability > about 10% ASes, at least 2,000 ASes as our test, It can't be > said the good situation at all. I will continue to test this month > and would like to share about the result somewhere. are there any ip adresses against which i/we can run some tests? (e.g. basic traceroutes) thanks, raoul From dmburgess at linktechs.net Thu Apr 15 15:07:57 2010 From: dmburgess at linktechs.net (Dennis Burgess) Date: Thu, 15 Apr 2010 15:07:57 -0500 Subject: Tracking down reverse for ip Message-ID: <91522911795E174F97E7EF8B792A1031228A4C@ltiserver.LTI.local> I have a customer that has an IP of 12.43.95.126. Currently, I can not get any reverse on this IP. What is the best way to find out the responciable servers for this? Thanx in advance. ----------------------------------------------------------- Dennis Burgess, CCNA, Mikrotik Certified Trainer, MTCNA, MTCRE, MTCWE, MTCTCE, MTCUME Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" From LarrySheldon at cox.net Thu Apr 15 15:12:38 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 15 Apr 2010 15:12:38 -0500 Subject: Tracking down reverse for ip In-Reply-To: <91522911795E174F97E7EF8B792A1031228A4C@ltiserver.LTI.local> References: <91522911795E174F97E7EF8B792A1031228A4C@ltiserver.LTI.local> Message-ID: <4BC77336.4090208@cox.net> On 4/15/2010 15:07, Dennis Burgess wrote: > I have a customer that has an IP of 12.43.95.126. Currently, I can not > get any reverse on this IP. > > > > What is the best way to find out the responciable servers for this? > Thanx in advance. CCNA, Mikrotik Certified Trainer, MTCNA, MTCRE, MTCWE, > MTCTCE, MTCUME Really? -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From jack at crepinc.com Thu Apr 15 15:12:46 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Thu, 15 Apr 2010 16:12:46 -0400 Subject: Tracking down reverse for ip In-Reply-To: <91522911795E174F97E7EF8B792A1031228A4C@ltiserver.LTI.local> References: <91522911795E174F97E7EF8B792A1031228A4C@ltiserver.LTI.local> Message-ID: jackc at anna ~ $ whois 12.43.95.126 AT&T WorldNet Services ATT (NET-12-0-0-0-1) 12.0.0.0 - 12.255.255.255 GARY SURDYKE MOTORCYCLE INC. ATT240-95-112 (NET-12-43-95-112-1) 12.43.95.112 - 12.43.95.127 jackc at anna ~ $ whois ATT240-95-112 OrgName: GARY SURDYKE MOTORCYCLE INC. OrgID: GSM-19 Address: 2435 HIGHWAY 67 City: FESTUS StateProv: MO PostalCode: 63028 Country: US NetRange: 12.43.95.112 - 12.43.95.127 CIDR: 12.43.95.112/28 NetName: ATT240-95-112 NetHandle: NET-12-43-95-112-1 Parent: NET-12-0-0-0-1 NetType: Reassigned Comment: RegDate: 2002-03-22 Updated: 2002-03-22 RTechHandle: DB2308-ARIN RTechName: Burgess, Dennis RTechPhone: +1-636-931-8700 RTechEmail: dmburgess at surdyke.com OrgTechHandle: DB2308-ARIN OrgTechName: Burgess, Dennis OrgTechPhone: +1-636-931-8700 OrgTechEmail: dmburgess at surdyke.com -Jack Carrozzo On Thu, Apr 15, 2010 at 4:07 PM, Dennis Burgess wrote: > I have a customer that has an IP of 12.43.95.126. Currently, I can not > get any reverse on this IP. > > > > What is the best way to find out the responciable servers for this? > Thanx in advance. > > > > ----------------------------------------------------------- > Dennis Burgess, CCNA, Mikrotik Certified Trainer, MTCNA, MTCRE, MTCWE, > MTCTCE, MTCUME > Link Technologies, Inc -- Mikrotik & WISP Support Services > Office: 314-735-0270 Website: http://www.linktechs.net > > LIVE On-Line Mikrotik Training > - Author of "Learn RouterOS" > > > > From joe at riversidecg.com Thu Apr 15 15:13:40 2010 From: joe at riversidecg.com (Joe Johnson) Date: Thu, 15 Apr 2010 15:13:40 -0500 Subject: Tracking down reverse for ip In-Reply-To: <91522911795E174F97E7EF8B792A1031228A4C@ltiserver.LTI.local> References: <91522911795E174F97E7EF8B792A1031228A4C@ltiserver.LTI.local> Message-ID: <154EDE9026B3D54F883B20F2BBDCF8795DF12AE3@exbe01.windows.riversidecg.com> >What is the best way to find out the responciable servers for this? >Thanx in advance. Call AT&T? Or Gary Surdyke Motorcycle, inc? root at jjohnson-ubuntu:~# whois 12.43.95.126 AT&T WorldNet Services ATT (NET-12-0-0-0-1) 12.0.0.0 - 12.255.255.255 GARY SURDYKE MOTORCYCLE INC. ATT240-95-112 (NET-12-43-95-112-1) 12.43.95.112 - 12.43.95.127 # ARIN WHOIS database, last updated 2010-04-14 20:00 # Enter ? for additional hints on searching ARIN's WHOIS database. # # ARIN WHOIS data and services are subject to the Terms of Use # available at https://www.arin.net/whois_tou.html From jeroen at mompl.net Thu Apr 15 15:14:31 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 15 Apr 2010 13:14:31 -0700 Subject: Tracking down reverse for ip In-Reply-To: <91522911795E174F97E7EF8B792A1031228A4C@ltiserver.LTI.local> References: <91522911795E174F97E7EF8B792A1031228A4C@ltiserver.LTI.local> Message-ID: <4BC773A7.7020407@mompl.net> Dennis Burgess wrote: > I have a customer that has an IP of 12.43.95.126. Currently, I can not > get any reverse on this IP. > What is the best way to find out the responciable servers for this? > Thanx in advance. AT&T owns the 12/8 address space. A quick whois gives me: AT&T WorldNet Services ATT (NET-12-0-0-0-1) 12.0.0.0 - 12.255.255.255 GARY SURDYKE MOTORCYCLE INC. ATT240-95-112 (NET-12-43-95-112-1) 12.43.95.112 - 12.43.95.127 # ARIN WHOIS database, last updated 2010-04-14 20:00 # Enter ? for additional hints on searching ARIN's WHOIS database. # # ARIN WHOIS data and services are subject to the Terms of Use # available at https://www.arin.net/whois_tou.html Assuming your customer is GARY SURDYKE MOTORCYCLE INC they probably need to talk to AT&T? Greetings, Jeroen From doon.bulk at inoc.net Thu Apr 15 15:21:49 2010 From: doon.bulk at inoc.net (Patrick Muldoon) Date: Thu, 15 Apr 2010 16:21:49 -0400 Subject: Tracking down reverse for ip In-Reply-To: <154EDE9026B3D54F883B20F2BBDCF8795DF12AE3@exbe01.windows.riversidecg.com> References: <91522911795E174F97E7EF8B792A1031228A4C@ltiserver.LTI.local> <154EDE9026B3D54F883B20F2BBDCF8795DF12AE3@exbe01.windows.riversidecg.com> Message-ID: <860165AB-2102-4E14-BD7B-2093805CAD71@inoc.net> On Apr 15, 2010, at 4:13 PM, Joe Johnson wrote: >> What is the best way to find out the responciable servers for this? >> Thanx in advance. > > Call AT&T? Or Gary Surdyke Motorcycle, inc? > > root at jjohnson-ubuntu:~# whois 12.43.95.126 > AT&T WorldNet Services ATT (NET-12-0-0-0-1) > 12.0.0.0 - 12.255.255.255 > GARY SURDYKE MOTORCYCLE INC. ATT240-95-112 (NET-12-43-95-112-1) > 12.43.95.112 - 12.43.95.127 > > # ARIN WHOIS database, last updated 2010-04-14 20:00 > # Enter ? for additional hints on searching ARIN's WHOIS database. > # > # ARIN WHOIS data and services are subject to the Terms of Use > # available at https://www.arin.net/whois_tou.html > it appears that AT&T has delegate the PTRs to... 112-28.95.43.12.in-addr.arpa. 172800 IN NS ns2.nightowl.net. 112-28.95.43.12.in-addr.arpa. 172800 IN NS mail.nightowl.net. [doon at gyruss:~] dig ns +trace -x 12.43.95.126 ; <<>> DiG 9.3.3 <<>> ns +trace -x 12.43.95.126 ;; global options: printcmd . 502744 IN NS b.root-servers.net. . 502744 IN NS l.root-servers.net. . 502744 IN NS c.root-servers.net. . 502744 IN NS g.root-servers.net. . 502744 IN NS a.root-servers.net. . 502744 IN NS f.root-servers.net. . 502744 IN NS m.root-servers.net. . 502744 IN NS e.root-servers.net. . 502744 IN NS k.root-servers.net. . 502744 IN NS d.root-servers.net. . 502744 IN NS j.root-servers.net. . 502744 IN NS i.root-servers.net. . 502744 IN NS h.root-servers.net. ;; Received 480 bytes from 127.0.0.1#53(127.0.0.1) in 2 ms 12.in-addr.arpa. 86400 IN NS CBRU.BR.NS.ELS-GMS.ATT.NET. 12.in-addr.arpa. 86400 IN NS DMTU.MT.NS.ELS-GMS.ATT.NET. 12.in-addr.arpa. 86400 IN NS DBRU.BR.NS.ELS-GMS.ATT.NET. 12.in-addr.arpa. 86400 IN NS CMTU.MT.NS.ELS-GMS.ATT.NET. ;; Received 143 bytes from 192.228.79.201#53(b.root-servers.net) in 80 ms 126.95.43.12.in-addr.arpa. 172800 IN CNAME 126.112-28.95.43.12.in-addr.arpa. 112-28.95.43.12.in-addr.arpa. 172800 IN NS ns2.nightowl.net. 112-28.95.43.12.in-addr.arpa. 172800 IN NS mail.nightowl.net. ;; Received 117 bytes from 199.191.128.105#53(CBRU.BR.NS.ELS-GMS.ATT.NET) in 42 ms -Patrick -- Patrick Muldoon Network/Software Engineer INOC (http://www.inoc.net) PGPKEY (http://www.inoc.net/~doon) Key ID: 0x370D752C There are only 10 types of people in this world, those that understand binary and those that don't From owenc at hubris.net Thu Apr 15 15:23:12 2010 From: owenc at hubris.net (Chris Owen) Date: Thu, 15 Apr 2010 15:23:12 -0500 Subject: Tracking down reverse for ip In-Reply-To: <91522911795E174F97E7EF8B792A1031228A4C@ltiserver.LTI.local> References: <91522911795E174F97E7EF8B792A1031228A4C@ltiserver.LTI.local> Message-ID: <5522A62B-2CFF-4530-8507-FE465AA441E3@hubris.net> On Apr 15, 2010, at 3:07 PM, Dennis Burgess wrote: > I have a customer that has an IP of 12.43.95.126. Currently, I can not > get any reverse on this IP. > > What is the best way to find out the responciable servers for this? > Thanx in advance. > > ----------------------------------------------------------- > Dennis Burgess, CCNA, Mikrotik Certified Trainer, MTCNA, MTCRE, MTCWE, > MTCTCE, MTCUME Don't forget WTF. Chris ------------------------------------------------------------------------- Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net ------------------------------------------------------------------------- From jeremyparr at gmail.com Thu Apr 15 15:26:13 2010 From: jeremyparr at gmail.com (Jeremy Parr) Date: Thu, 15 Apr 2010 16:26:13 -0400 Subject: Please do not respond to Dean and CC the NANOG list In-Reply-To: References: <1E8B940C5E21014AB8BE70B975D40EDB03957DE9@bert.HiberniaAtlantic.local> Message-ID: On 15 April 2010 16:18, Dean Anderson wrote: > It won't end until the truth finally prevails and they quit trying to > mislead people. Can someone remove this guy form the Nanog list please? From seitz at strato-rz.de Thu Apr 15 15:26:59 2010 From: seitz at strato-rz.de (Christian Seitz) Date: Thu, 15 Apr 2010 22:26:59 +0200 Subject: advertisements of 14/8 and 223/8 In-Reply-To: <20100416010159.AC87.9C4C12A4@nttv6.jp> References: <3E3330CF-2F54-42C0-9DE8-C8D0B5C0C0AB@apnic.net> <20100416010159.AC87.9C4C12A4@nttv6.jp> Message-ID: <4BC77693.3040708@strato-rz.de> Hello, Tomoya Yoshida wrote: > I started to advertise for test two /8s and in addition to > collecting of unwanted traffic I checked the status of > route-views of these two /8s including two experimental > prefixes in 27/8 which is allocated to APNIC on Jan 2010 > and old 115/8 space. > > http://www.nttv6.jp/~yoshida/bogon_rviews_20100415_yoshida.pdf > > For 27/8, It seemse that some ISP still dosen't update > their filter or dosen't advertise to route-views by some reasons. > Now I'm using 27/8 space and I found that there is no reachability > about 10% ASes, at least 2,000 ASes as our test, It can't be > said the good situation at all. I will continue to test this month > and would like to share about the result somewhere. > > Also the interesting result is that there is differences between > 14/8 and 223/8 on route-views result. Do you have any idea? I have heard from some carriers that they only accept selected /8s, but not from all IP ranges. Perhaps the test announcements should be 4x /10 for example instead of a single /8. Then the announcements should reach more ASes. Regards, Chris From dmburgess at linktechs.net Thu Apr 15 15:32:02 2010 From: dmburgess at linktechs.net (Dennis Burgess) Date: Thu, 15 Apr 2010 15:32:02 -0500 Subject: Tracking down reverse for ip References: <91522911795E174F97E7EF8B792A1031228A4C@ltiserver.LTI.local> <5522A62B-2CFF-4530-8507-FE465AA441E3@hubris.net> Message-ID: <91522911795E174F97E7EF8B792A1031228A56@ltiserver.LTI.local> Yep. BTW, thanks for all of the replies. In this case ATT was sending the request to another server, and that's what I needed :) ----------------------------------------------------------- Dennis Burgess, CCNA, Mikrotik Certified Trainer, MTCNA, MTCRE, MTCWE, MTCTCE, MTCUME Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" -----Original Message----- From: Chris Owen [mailto:owenc at hubris.net] Sent: Thursday, April 15, 2010 3:23 PM To: NANOG list Subject: Re: Tracking down reverse for ip On Apr 15, 2010, at 3:07 PM, Dennis Burgess wrote: > I have a customer that has an IP of 12.43.95.126. Currently, I can not > get any reverse on this IP. > > What is the best way to find out the responciable servers for this? > Thanx in advance. > > ----------------------------------------------------------- > Dennis Burgess, CCNA, Mikrotik Certified Trainer, MTCNA, MTCRE, MTCWE, > MTCTCE, MTCUME Don't forget WTF. Chris ------------------------------------------------------------------------ - Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net ------------------------------------------------------------------------ - From setient at gmail.com Thu Apr 15 15:32:29 2010 From: setient at gmail.com (Ronald Cotoni) Date: Thu, 15 Apr 2010 16:32:29 -0400 Subject: Please do not respond to Dean and CC the NANOG list In-Reply-To: References: <1E8B940C5E21014AB8BE70B975D40EDB03957DE9@bert.HiberniaAtlantic.local> Message-ID: <10DEA485-EC47-4D6C-8A2B-7BF3AB6BB5B0@gmail.com> On Apr 15, 2010, at 4:26 PM, Jeremy Parr wrote: > On 15 April 2010 16:18, Dean Anderson wrote: >> It won't end until the truth finally prevails and they quit trying to >> mislead people. > > Can someone remove this guy form the Nanog list please? > He is removed but he still harasses everyone. Do what I do, auto respond to his messages telling him to not email you then forward to abuse at . He will get the hint. From bruns at 2mbit.com Thu Apr 15 15:37:16 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 15 Apr 2010 14:37:16 -0600 Subject: Please do not respond to Dean and CC the NANOG list In-Reply-To: <10DEA485-EC47-4D6C-8A2B-7BF3AB6BB5B0@gmail.com> References: <1E8B940C5E21014AB8BE70B975D40EDB03957DE9@bert.HiberniaAtlantic.local> <10DEA485-EC47-4D6C-8A2B-7BF3AB6BB5B0@gmail.com> Message-ID: <4BC778FC.80605@2mbit.com> On 4/15/10 2:32 PM, Ronald Cotoni wrote: > > On Apr 15, 2010, at 4:26 PM, Jeremy Parr wrote: > >> On 15 April 2010 16:18, Dean Anderson wrote: >>> It won't end until the truth finally prevails and they quit >>> trying to mislead people. >> >> Can someone remove this guy form the Nanog list please? >> > He is removed but he still harasses everyone. Do what I do, auto > respond to his messages telling him to not email you then forward to > abuse at . He will get the hint. He's also just stopped short of cart00neying me after I told him where to shove his e-mails. It got to the point hes not only in the AHBL, but in my exim filters. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From nenolod at systeminplace.net Thu Apr 15 15:59:19 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 15 Apr 2010 15:59:19 -0500 Subject: Tracking down reverse for ip In-Reply-To: <91522911795E174F97E7EF8B792A1031228A4C@ltiserver.LTI.local> References: <91522911795E174F97E7EF8B792A1031228A4C@ltiserver.LTI.local> Message-ID: <1271365159.13545.243.camel@petrie> On Thu, 2010-04-15 at 15:07 -0500, Dennis Burgess wrote: > I have a customer that has an IP of 12.43.95.126. Currently, I can not > get any reverse on this IP. > > > > What is the best way to find out the responciable servers for this? > Thanx in advance. > nenolod at petrie:~$ dig -x 12.43.95.126 +trace @4.2.2.1 ; <<>> DiG 9.6.1-P2 <<>> -x 12.43.95.126 +trace @4.2.2.1 ;; global options: +cmd . 26412 IN NS j.root-servers.net. . 26412 IN NS a.root-servers.net. . 26412 IN NS l.root-servers.net. . 26412 IN NS e.root-servers.net. . 26412 IN NS g.root-servers.net. . 26412 IN NS k.root-servers.net. . 26412 IN NS d.root-servers.net. . 26412 IN NS h.root-servers.net. . 26412 IN NS i.root-servers.net. . 26412 IN NS c.root-servers.net. . 26412 IN NS m.root-servers.net. . 26412 IN NS f.root-servers.net. . 26412 IN NS b.root-servers.net. ;; Received 228 bytes from 4.2.2.1#53(4.2.2.1) in 34 ms arpa. 172800 IN NS A.ROOT-SERVERS.NET. arpa. 172800 IN NS H.ROOT-SERVERS.NET. arpa. 172800 IN NS C.ROOT-SERVERS.NET. arpa. 172800 IN NS L.ROOT-SERVERS.NET. arpa. 172800 IN NS F.ROOT-SERVERS.NET. arpa. 172800 IN NS M.ROOT-SERVERS.NET. arpa. 172800 IN NS G.ROOT-SERVERS.NET. arpa. 172800 IN NS E.ROOT-SERVERS.NET. arpa. 172800 IN NS D.ROOT-SERVERS.NET. arpa. 172800 IN NS I.ROOT-SERVERS.NET. arpa. 172800 IN NS B.ROOT-SERVERS.NET. arpa. 172800 IN NS K.ROOT-SERVERS.NET. ;; Received 495 bytes from 192.58.128.30#53(j.root-servers.net) in 28 ms 12.in-addr.arpa. 86400 IN NS DMTU.MT.NS.ELS-GMS.ATT.NET. 12.in-addr.arpa. 86400 IN NS CMTU.MT.NS.ELS-GMS.ATT.NET. 12.in-addr.arpa. 86400 IN NS CBRU.BR.NS.ELS-GMS.ATT.NET. 12.in-addr.arpa. 86400 IN NS DBRU.BR.NS.ELS-GMS.ATT.NET. ;; Received 143 bytes from 192.36.148.17#53(I.ROOT-SERVERS.NET) in 153 ms 126.95.43.12.in-addr.arpa. 172800 IN CNAME 126.112-28.95.43.12.in-addr.arpa. 112-28.95.43.12.in-addr.arpa. 172800 IN NS ns2.nightowl.net. 112-28.95.43.12.in-addr.arpa. 172800 IN NS mail.nightowl.net. ;; Received 117 bytes from 12.127.16.69#53(CMTU.MT.NS.ELS-GMS.ATT.NET) in 60 ms ns2.nightowl.net/mail.nightowl.net is broken (missing 128-28.95.43.12.in-addr.arpa) zone. For someone who is a CCNA, Mikrotik Certified Whatever, etc, etc, etc, you really should know how to use dig(1). William From blewis at hottopic.com Thu Apr 15 16:05:05 2010 From: blewis at hottopic.com (Bill Lewis) Date: Thu, 15 Apr 2010 16:05:05 -0500 Subject: DSL "aggregation".... NO Message-ID: <26CF6BC367161D4BAFC39B6ED6F885F3021901CC@TNEXPRD.hottopic.com> Group, Since I'm told that DSL aggregation / mux is currently not possible, we are looking at doing stream splitting via a technology like FatPipe uses. Anyone have this in production usage? Or something similar? Cisco has offered some ways to split via CEF, but most DSL carriers do not have this turned on / available. Thank you, Bill Network dude From shon at unwiredbb.com Thu Apr 15 16:29:26 2010 From: shon at unwiredbb.com (Shon Elliott) Date: Thu, 15 Apr 2010 14:29:26 -0700 Subject: Fiber Outage in Sunnyvale, CA. Message-ID: <43BAB891D6D01742AFDEA3D62DCE9E5D71928E@uwbb-cat2.unwiredbb.local> I heard there is a fiber outage in Sunnyvale that has taken out most of the city. Can someone from AT&T Provide any kind of clue on what's going on? I'm being told by one of our partners that their entire building is without service in Sunnyvale and apparently they've talked to other businesses in the area that have fiber-based services who are also down. Regards, Shon Elliott Senior Network Engineer unWired Broadband, Inc. Office: (559) 261-4444 x 511 Cell: (559) 917-6480 From jack at crepinc.com Thu Apr 15 16:39:54 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Thu, 15 Apr 2010 17:39:54 -0400 Subject: DSL "aggregation".... NO In-Reply-To: <26CF6BC367161D4BAFC39B6ED6F885F3021901CC@TNEXPRD.hottopic.com> References: <26CF6BC367161D4BAFC39B6ED6F885F3021901CC@TNEXPRD.hottopic.com> Message-ID: You can balance over DSL by putting different L2TPv3 tunnels over each physical device and agg it at someplace with real connections and such. It's possible to do it with GRE or OpenVPN too, but much less classy. Clearly the downside of this is that you need an agg machine on your end somewhere, but it gives you lots of control for sure. -Jack Carrozzo On Thu, Apr 15, 2010 at 5:05 PM, Bill Lewis wrote: > Group, > > Since I'm told that DSL aggregation / mux is currently not possible, we > are looking at doing stream splitting via a technology like FatPipe > uses. Anyone have this in production usage? Or something similar? > > Cisco has offered some ways to split via CEF, but most DSL carriers do > not have this turned on / available. > > > > Thank you, > > Bill > > Network dude > > From truman at suspicious.org Thu Apr 15 16:42:31 2010 From: truman at suspicious.org (Truman Boyes) Date: Thu, 15 Apr 2010 17:42:31 -0400 Subject: DSL "aggregation".... NO In-Reply-To: <26CF6BC367161D4BAFC39B6ED6F885F3021901CC@TNEXPRD.hottopic.com> References: <26CF6BC367161D4BAFC39B6ED6F885F3021901CC@TNEXPRD.hottopic.com> Message-ID: Hi Bill, You can do this in JUNOS as well with filter-based-forwarding. The key here is that you want to balance traffic out and in on the two uplinks. I suspect you will need to src-NAT all the traffic unless you are announcing your own network to the two DSL providers. You could also do some rudimentary (ie. hack) balancing by having a route for 0/1 and 128/1 with different next-hops. It's pretty easy to setup balancing on an OpenBSD box with PF as well. Truman On 15/04/2010, at 5:05 PM, Bill Lewis wrote: > Group, > > Since I'm told that DSL aggregation / mux is currently not possible, we > are looking at doing stream splitting via a technology like FatPipe > uses. Anyone have this in production usage? Or something similar? > > Cisco has offered some ways to split via CEF, but most DSL carriers do > not have this turned on / available. > > > > Thank you, > > Bill > > Network dude > From scott at doc.net.au Thu Apr 15 16:43:16 2010 From: scott at doc.net.au (Scott Howard) Date: Thu, 15 Apr 2010 14:43:16 -0700 Subject: Fiber Outage in Sunnyvale, CA. In-Reply-To: <43BAB891D6D01742AFDEA3D62DCE9E5D71928E@uwbb-cat2.unwiredbb.local> References: <43BAB891D6D01742AFDEA3D62DCE9E5D71928E@uwbb-cat2.unwiredbb.local> Message-ID: No problems here on the western side of 101 with our AT&T Opt-e-man. That said, the majority of fiber in the Sunnyvale area is on the other side of 101. Scott On Thu, Apr 15, 2010 at 2:29 PM, Shon Elliott wrote: > I heard there is a fiber outage in Sunnyvale that has taken out most of > the city. Can someone from AT&T Provide any kind of clue on what's going > on? I'm being told by one of our partners that their entire building is > without service in Sunnyvale and apparently they've talked to other > businesses in the area that have fiber-based services who are also down. > > > > Regards, > Shon Elliott > Senior Network Engineer > unWired Broadband, Inc. > Office: (559) 261-4444 x 511 > Cell: (559) 917-6480 > > > > > > From dhc2 at dcrocker.net Thu Apr 15 17:24:20 2010 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Thu, 15 Apr 2010 15:24:20 -0700 Subject: Fiber Outage in Sunnyvale, CA. In-Reply-To: <43BAB891D6D01742AFDEA3D62DCE9E5D71928E@uwbb-cat2.unwiredbb.local> References: <43BAB891D6D01742AFDEA3D62DCE9E5D71928E@uwbb-cat2.unwiredbb.local> Message-ID: <4BC79214.2070406@dcrocker.net> Near Lawrence, between El Camino and Central, seems to be working fine to the home. d/ On 4/15/2010 2:29 PM, Shon Elliott wrote: > I heard there is a fiber outage in Sunnyvale that has taken out most of > the city. Can someone from AT&T Provide any kind of clue on what's going > on? I'm being told by one of our partners that their entire building is > without service in Sunnyvale and apparently they've talked to other > businesses in the area that have fiber-based services who are also down. > > > > Regards, > Shon Elliott > Senior Network Engineer > unWired Broadband, Inc. > Office: (559) 261-4444 x 511 > Cell: (559) 917-6480 > > > > > > -- Dave Crocker Brandenburg InternetWorking bbiw.net From mrz at velvet.org Thu Apr 15 17:25:30 2010 From: mrz at velvet.org (matthew zeier) Date: Thu, 15 Apr 2010 15:25:30 -0700 Subject: Fiber Outage in Sunnyvale, CA. In-Reply-To: <43BAB891D6D01742AFDEA3D62DCE9E5D71928E@uwbb-cat2.unwiredbb.local> References: <43BAB891D6D01742AFDEA3D62DCE9E5D71928E@uwbb-cat2.unwiredbb.local> Message-ID: I'll confirm. Ticket# FE00 7756 This has taken out half of my opteman circuit from Mountain View. AT&T tells me it's a hardware failure with an ETR around 6pm Pacific. On Apr 15, 2010, at 2:29 PM, Shon Elliott wrote: > I heard there is a fiber outage in Sunnyvale that has taken out most of > the city. Can someone from AT&T Provide any kind of clue on what's going > on? I'm being told by one of our partners that their entire building is > without service in Sunnyvale and apparently they've talked to other > businesses in the area that have fiber-based services who are also down. From streiner at cluebyfour.org Thu Apr 15 16:44:27 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 15 Apr 2010 17:44:27 -0400 (EDT) Subject: Please do not respond to Dean and CC the NANOG list In-Reply-To: <4BC778FC.80605@2mbit.com> References: <1E8B940C5E21014AB8BE70B975D40EDB03957DE9@bert.HiberniaAtlantic.local> <10DEA485-EC47-4D6C-8A2B-7BF3AB6BB5B0@gmail.com> <4BC778FC.80605@2mbit.com> Message-ID: On Thu, 15 Apr 2010, Brielle Bruns wrote: > On 4/15/10 2:32 PM, Ronald Cotoni wrote: >> >> On Apr 15, 2010, at 4:26 PM, Jeremy Parr wrote: >> >> > On 15 April 2010 16:18, Dean Anderson wrote: >> > > It won't end until the truth finally prevails and they quit >> > > trying to mislead people. >> > >> > Can someone remove this guy form the Nanog list please? >> > >> He is removed but he still harasses everyone. Do what I do, auto >> respond to his messages telling him to not email you then forward to >> abuse at . He will get the hint. > > He's also just stopped short of cart00neying me after I told him where to > shove his e-mails. It got to the point hes not only in the AHBL, but in my > exim filters. Due to peoples' responses, I see only half of this thread, since I've blocked emails from Dean. This is still one-half more of this thread than I really want to see. Let's all agree to let this thread die. jms From dhc2 at dcrocker.net Thu Apr 15 18:06:23 2010 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Thu, 15 Apr 2010 16:06:23 -0700 Subject: getting the hint (was: Re: Please do not respond to Dean and CC the NANOG list) In-Reply-To: <10DEA485-EC47-4D6C-8A2B-7BF3AB6BB5B0@gmail.com> References: <1E8B940C5E21014AB8BE70B975D40EDB03957DE9@bert.HiberniaAtlantic.local> <10DEA485-EC47-4D6C-8A2B-7BF3AB6BB5B0@gmail.com> Message-ID: <4BC79BEF.8090409@dcrocker.net> On 4/15/2010 1:32 PM, Ronald Cotoni wrote: > Do what I do, auto respond to > his messages telling him to not email you then forward to abuse at . He will > get the hint. This is a common misunderstanding of the personality type. Your recommendation is based on the assumption that you are dealing with a predominantly rational person, according to a "normal" sense of rational. In reality, these situations occur with someone who thrives on getting any sort of reaction at all. Much like the claim that there is no such thing as bad publicity, this sort of person enjoys any and all interaction, no matter how distasteful and dissuading a 'normal' person might find it. The only response that works -- and even this is not guaranteed -- is shunning. Drop the message. Do not respond. Ever. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Apr 15 17:09:39 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Fri, 16 Apr 2010 07:39:39 +0930 Subject: DSL "aggregation".... NO In-Reply-To: References: <26CF6BC367161D4BAFC39B6ED6F885F3021901CC@TNEXPRD.hottopic.com> Message-ID: <20100416073939.56b75fe7@opy.nosense.org> On Thu, 15 Apr 2010 17:39:54 -0400 Jack Carrozzo wrote: > You can balance over DSL by putting different L2TPv3 tunnels over each > physical device and agg it at someplace with real connections and > such. It's possible to do it with GRE or OpenVPN too, but much less > classy. > Depends a bit on the tunnel overhead you're willing to pay. I've done this, and I'd have preferred to use pure IP in IP, however Cisco's have GRE keep alives to monitor tunnel state, so I used that, at the cost of extra 4 bytes. As the tunnel creates a dumbbell path MTU (1500 Inet, <1500, 1500 LAN), you need to pay attention to PMTU issues, such as destination unreachable rate limitting, MSS hacks, and copying the DF bit from the tunnelled packet to the outer encapsulating tunnel packet. Depending on your traffic profile, and the latency of the paths the tunnels take (i.e. if they're very similar), per packet rather than the default per src/destination CEF load balancing is worth considering. > Clearly the downside of this is that you need an agg machine on your > end somewhere, but it gives you lots of control for sure. > > -Jack Carrozzo > > On Thu, Apr 15, 2010 at 5:05 PM, Bill Lewis wrote: > > Group, > > > > Since I'm told that DSL aggregation / mux is currently not possible, we > > are looking at doing stream splitting via a technology like FatPipe > > uses. Anyone have this in production usage? Or something similar? > > > > Cisco has offered some ways to split via CEF, but most DSL carriers do > > not have this turned on / available. > > > > > > > > Thank you, > > > > Bill > > > > Network dude > > > > > From LarrySheldon at cox.net Thu Apr 15 18:22:06 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 15 Apr 2010 18:22:06 -0500 Subject: getting the hint In-Reply-To: <4BC79BEF.8090409@dcrocker.net> References: <1E8B940C5E21014AB8BE70B975D40EDB03957DE9@bert.HiberniaAtlantic.local> <10DEA485-EC47-4D6C-8A2B-7BF3AB6BB5B0@gmail.com> <4BC79BEF.8090409@dcrocker.net> Message-ID: <4BC79F9E.5060702@cox.net> On 4/15/2010 18:06, Dave CROCKER wrote: > > The only response that works -- and even this is not guaranteed -- is shunning. > > Drop the message. Do not respond. Ever. And for the love of Pete, when somebody (as I have) makes a mistake and does his bidding, tell the miscreant VIA PRIVATE EMAIL or a note tied to a brick, but do not prate incessantly about it on the list. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From dmbogo at gmail.com Thu Apr 15 19:00:02 2010 From: dmbogo at gmail.com (Dennis Mbogo) Date: Thu, 15 Apr 2010 19:00:02 -0500 Subject: Tracking down reverse for ip In-Reply-To: <91522911795E174F97E7EF8B792A1031228A4C@ltiserver.LTI.local> References: <91522911795E174F97E7EF8B792A1031228A4C@ltiserver.LTI.local> Message-ID: Wow! Surely, with all the mentioned Certs, you should know how to dig. Darn, you can even get this info by just using web sites. On Thu, Apr 15, 2010 at 3:07 PM, Dennis Burgess wrote: > I have a customer that has an IP of 12.43.95.126. Currently, I can not > get any reverse on this IP. > > > > What is the best way to find out the responciable servers for this? > Thanx in advance. > > > > ----------------------------------------------------------- > Dennis Burgess, CCNA, Mikrotik Certified Trainer, MTCNA, MTCRE, MTCWE, > MTCTCE, MTCUME > Link Technologies, Inc -- Mikrotik & WISP Support Services > Office: 314-735-0270 Website: http://www.linktechs.net > > LIVE On-Line Mikrotik Training > - Author of "Learn RouterOS" > > > > From nonobvious at gmail.com Thu Apr 15 19:50:03 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Thu, 15 Apr 2010 17:50:03 -0700 Subject: DSL "aggregation".... NO In-Reply-To: <26CF6BC367161D4BAFC39B6ED6F885F3021901CC@TNEXPRD.hottopic.com> References: <26CF6BC367161D4BAFC39B6ED6F885F3021901CC@TNEXPRD.hottopic.com> Message-ID: On Thu, Apr 15, 2010 at 2:05 PM, Bill Lewis wrote: > Group, > > Since I'm told that DSL aggregation / mux is currently not possible, we > are looking at doing stream splitting via a technology like FatPipe > uses. Anyone have this in production usage? Or something similar? It depends very much on what your traffic looks like, and what you're trying to accomplish. If you're trying to build a pipe from Point A to Point B, and are really picky about how balanced it is (in spite of it being ADSL), then maybe you need something fancy on each end, whether that's FatPipe or Fancy BSD Tricks. If you're mainly fetching web traffic from the public Internet, then all you really need to do is spread out your queries between the DSL lines, using NAT to make sure each query goes back to the DSL that sent it, and that'll be close enough. If you're trying to balance inbound re ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From nonobvious at gmail.com Thu Apr 15 19:50:51 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Thu, 15 Apr 2010 17:50:51 -0700 Subject: DSL "aggregation".... NO In-Reply-To: References: <26CF6BC367161D4BAFC39B6ED6F885F3021901CC@TNEXPRD.hottopic.com> Message-ID: Hmm, fat fingered that. > If you're trying to balance inbound re If you're trying to balance inbound requests, use a DNS load balancer. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From jeff at ocjtech.us Thu Apr 15 21:22:58 2010 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 15 Apr 2010 21:22:58 -0500 Subject: watchmy.net? Message-ID: Can anyone log into watchmy.net and manage their account? Our network has changed so I need to get in and change my settings so that I stop getting bogus alerts. Unfortunately there seem to be some PHP coding errors so I can't log into the site. I've mailed bgp at watchmy.net (once on 1/14 and once on 3/25) but I've received no response, so I'm reduced to bothering everyone here. -- Jeff Ollie From mysidia at gmail.com Fri Apr 16 00:52:31 2010 From: mysidia at gmail.com (James Hess) Date: Fri, 16 Apr 2010 00:52:31 -0500 Subject: Tracking down reverse for ip In-Reply-To: <1271365159.13545.243.camel@petrie> References: <91522911795E174F97E7EF8B792A1031228A4C@ltiserver.LTI.local> <1271365159.13545.243.camel@petrie> Message-ID: On Thu, Apr 15, 2010 at 3:59 PM, William Pitcock wrote: > For someone who is a CCNA, Mikrotik Certified Whatever, etc, etc, etc, > you really should know how to use dig(1). Certifications usually only suggest certain skills or knowledge they were designed to validate, and sometimes might fail even at that; dig(1) or detailed DNS knowledge is not scoped within either of those certs, as far as I know.. There are probably many CCNA and MTCNA holders who have not so much as seen a Unix/Linux shell prompt, and maybe only saw a DOS/Windows command prompt once or twice, so the only shell command known is 'ping'. [snip snip-] > On Thu, 2010-04-15 at 15:07 -0500, Dennis Burgess wrote: >> I have a customer that has an IP of 12.43.95.126. Currently, I can not >> get any reverse on this IP. >> What is the best way to find out the responciable servers for this? There are a number of ways to further research an IP address. Your first stop should be normal WHOIS on the IP, either from your favorite command line, or a web-based service such as DNSTools, DNSStuff, or Robtex as in http://www.robtex.com/ip/12.43.95.126.html#shared #whois If no success.... then check the DNS system to determine what nameservers (if any) are delegated for the IP address' reverse DNS, finally check prefix whois, RADB, or various services to lookup the AS associated with world BGP announcements for the address. Asking OPs mailing lists to help identify responsible party should be very last resort, after all normal avenues are exhausted. -- -J From patrick at ianai.net Fri Apr 16 01:24:16 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 16 Apr 2010 02:24:16 -0400 Subject: Please do not respond to Dean and CC the NANOG list In-Reply-To: References: <1E8B940C5E21014AB8BE70B975D40EDB03957DE9@bert.HiberniaAtlantic.local> Message-ID: On Apr 15, 2010, at 4:26 PM, Jeremy Parr wrote: [SNIP - stuff from dean at av8.com] > Can someone remove this guy form the Nanog list please? He cannot post. The only reason you see his drivel is because people who are not banned "reply-all" and CC the list. Which I have posted asking people to stop doing several times. Please notice the subject of this very thread. -- TTFN, patrick From joly at punkcast.com Fri Apr 16 02:20:59 2010 From: joly at punkcast.com (Joly MacFie) Date: Fri, 16 Apr 2010 03:20:59 -0400 Subject: ISOC ISP Column: IPv6 penetration reaches 5% Message-ID: In the April 2010 edition of Geoff Huston's ISOC ISP Column he reports that the extent of full end-to-end IPv6 capability in today?s Internet is now at a level of 5% of all end systems. This number is now at a level where IPv6 deployment is now passing from mere statistical interest to mainstream commercial importance. http://isoc.org/wp/ispcolumn/?p=254 -- --------------------------------------------------------------- Joly MacFie 917 442 8665 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com --------------------------------------------------------------- From tvarriale at comcast.net Fri Apr 16 09:29:09 2010 From: tvarriale at comcast.net (Tony Varriale) Date: Fri, 16 Apr 2010 09:29:09 -0500 Subject: Router for Metro Ethernet References: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> Message-ID: <73D0FF09E78149C0AFF6BAFFA558B2E7@flamdt01> >---- Original Message ----- >From: "Bill Stewart" >To: "Tony Varriale" >Cc: >Sent: Wednesday, April 14, 2010 10:22 AM >Subject: Re: Router for Metro Ethernet > > >That's the spec sheet, and that's for straight forwarding. >If you want to do much of anything else at all with the router, >Cisco has another web page that says they only recommend 45Mbps on the >3845 and something like half that on the 3825. >It's especially an issue if you need to do traffic-shaping, which you >usually do for MetroE. That's the marketing sheet so you continue to purchase up. But, notice what I said in my original post about CPU. There's only so much of it. So, adjust appropriately for whatever feature you turn on. tv From chris at rseng.net Fri Apr 16 09:37:34 2010 From: chris at rseng.net (Chris Patterson) Date: Fri, 16 Apr 2010 10:37:34 -0400 Subject: Sprint Link in Saint Louis Message-ID: <04B1EEF1066C14469399096371CC9174CDAAFC67DC@RSSBS08.rseng.net> We are getting multiple reports of packet loss in Sprint Network in Saint Louis which appears to be affecting some of our VPNs. Anyone seeing similar issues? Internet Health Report not showing recent issues. Chris Patterson, CCNA Support Manager Rapid Systems From wllmjbs at gmail.com Fri Apr 16 10:25:23 2010 From: wllmjbs at gmail.com (William Jobs) Date: Fri, 16 Apr 2010 18:25:23 +0300 Subject: CX4 to XFP Message-ID: Hi, I need to connect a router and a server over 10G. The router has a XFP interface and the server has a CX4 interface. Has anyone else undertaken a similar setup? What were the difficulties you encountered especially in terms of reduced throughput, packet loss etc. Any recommended media converters? I would appreciate any insight as to how I would go about getting this done? Thanks. From swmike at swm.pp.se Fri Apr 16 10:35:57 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 16 Apr 2010 17:35:57 +0200 (CEST) Subject: CX4 to XFP In-Reply-To: References: Message-ID: On Fri, 16 Apr 2010, William Jobs wrote: > Has anyone else undertaken a similar setup? What were the difficulties you > encountered especially in terms of reduced throughput, packet loss etc. Any > recommended media converters? Why media converter? There are CX4 XFPs as far as I can google... -- Mikael Abrahamsson email: swmike at swm.pp.se From joelja at bogus.com Fri Apr 16 10:48:51 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 16 Apr 2010 08:48:51 -0700 Subject: CX4 to XFP In-Reply-To: References: Message-ID: <4BC886E3.3080006@bogus.com> On 04/16/2010 08:35 AM, Mikael Abrahamsson wrote: > On Fri, 16 Apr 2010, William Jobs wrote: > >> Has anyone else undertaken a similar setup? What were the difficulties >> you >> encountered especially in terms of reduced throughput, packet loss >> etc. Any >> recommended media converters? > > Why media converter? There are CX4 XFPs as far as I can google... the cx4 interface is xaui 4x3Gb/s, as is xenpack. xfp is xfi 1 x 10Gb/s so connecting the two requires a serdes device. From giulianocm at uol.com.br Fri Apr 16 10:52:40 2010 From: giulianocm at uol.com.br (GIULIANO (UOL)) Date: Fri, 16 Apr 2010 12:52:40 -0300 Subject: JUNIPER M7i CFLOW Sampling for L2 Vlans Message-ID: <4BC887C8.7090709@uol.com.br> People, Good afternoon, We have a curious situation in a client's environment. It has a M7i router with 2 IQ2E (4 GE) PICs. It wants one of its PICs plugged into a L2 switch (802.1Q Trunk Mode) and the another one plugged (via 1 giga of 4 ports only) to another L2 switch. M7i / \ S1 S2 Both Giga ports are simpled configured like: nterfaces { ge-0/0/0 { vlan-tagging; nterfaces { ge-0/1/0 { vlan-tagging; L2 Trunk Ethernet only without L3 configuration. It is possible to get flow information about the encapsulated vlans (10,20,30,40, etc) inside the trunk traffic ? ... without configuring ip (4 or 6) or creating vlan interfaces ? It is possible to get cflow working in a L2 way ? Does anyone has configured it before using JUNIPER ? Can you send or point to me some samples of configuration ? Thanks a lot, Giuliano From swmike at swm.pp.se Fri Apr 16 10:53:31 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 16 Apr 2010 17:53:31 +0200 (CEST) Subject: CX4 to XFP In-Reply-To: <4BC886E3.3080006@bogus.com> References: <4BC886E3.3080006@bogus.com> Message-ID: On Fri, 16 Apr 2010, Joel Jaeggli wrote: > > > On 04/16/2010 08:35 AM, Mikael Abrahamsson wrote: >> On Fri, 16 Apr 2010, William Jobs wrote: >> >>> Has anyone else undertaken a similar setup? What were the difficulties >>> you >>> encountered especially in terms of reduced throughput, packet loss >>> etc. Any >>> recommended media converters? >> >> Why media converter? There are CX4 XFPs as far as I can google... > > the cx4 interface is xaui 4x3Gb/s, as is xenpack. xfp is xfi 1 x 10Gb/s > so connecting the two requires a serdes device. http://www.small-tree.com/XFP_CX4_p/xfp-cx4.htm "The XFP-CX4 copper transceiver module provides cost effective and reliable transport of 10 Gigabit Ethernet LAN data over distances of up to 15 meters. Transparently to the user, the module transfers the 10GbE data stream over four full-duplex 3.125 GigaBaud channels over a single parallel copper cable. The product offers the ability to scale bandwidth in 10 Gigabit increments, and directly with the industry standard MDI electrical socket." I guess this one does that? -- Mikael Abrahamsson email: swmike at swm.pp.se From lowen at pari.edu Fri Apr 16 10:54:18 2010 From: lowen at pari.edu (Lamar Owen) Date: Fri, 16 Apr 2010 11:54:18 -0400 Subject: Tracking down reverse for ip In-Reply-To: <1271365159.13545.243.camel@petrie> References: <91522911795E174F97E7EF8B792A1031228A4C@ltiserver.LTI.local> Message-ID: <201004161154.18920.lowen@pari.edu> On Thursday 15 April 2010 04:59:19 pm William Pitcock wrote: > For someone who is a CCNA, Mikrotik Certified Whatever, etc, etc, etc, > you really should know how to use dig(1). Which IOS or RouterOS has that command? Now, if the list included RHCE.... As James said, certifications are pretty narrowly targeted instruments; knowing how to set up the cisco IOS featureset of the day or deal with all the things you need to get those certs does not in any way touch real-world DNS issues. At least if I were hiring someone, and they give me a list of certifications like the above, I wouldn't assume any knowledge past what the training materials of the week have in them; any other knowledge would be gravy. You might be surprised how many network professionals have never had need to use whois or dig, and may not even know they exist, but be a whiz at MPLS, IPv6, QoS, etc things. From joelja at bogus.com Fri Apr 16 11:00:32 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 16 Apr 2010 09:00:32 -0700 Subject: CX4 to XFP In-Reply-To: References: <4BC886E3.3080006@bogus.com> Message-ID: <4BC889A0.8010909@bogus.com> On 04/16/2010 08:53 AM, Mikael Abrahamsson wrote: > On Fri, 16 Apr 2010, Joel Jaeggli wrote: > >> >> >> On 04/16/2010 08:35 AM, Mikael Abrahamsson wrote: >>> On Fri, 16 Apr 2010, William Jobs wrote: >>> >>>> Has anyone else undertaken a similar setup? What were the difficulties >>>> you >>>> encountered especially in terms of reduced throughput, packet loss >>>> etc. Any >>>> recommended media converters? >>> >>> Why media converter? There are CX4 XFPs as far as I can google... >> >> the cx4 interface is xaui 4x3Gb/s, as is xenpack. xfp is xfi 1 x 10Gb/s >> so connecting the two requires a serdes device. > > http://www.small-tree.com/XFP_CX4_p/xfp-cx4.htm > > "The XFP-CX4 copper transceiver module provides cost effective and > reliable transport of 10 Gigabit Ethernet LAN data over distances of up > to 15 meters. Transparently to the user, the module transfers the 10GbE > data stream over four full-duplex 3.125 GigaBaud channels over a single > parallel copper cable. The product offers the ability to scale bandwidth > in 10 Gigabit increments, and directly with the industry standard MDI > electrical socket." > > I guess this one does that? yes... so does converting it from xaui to optical. Not objecting to the characterization of the existance of xfp/cx4 connections, only clarifying what such a device does. From nick at foobar.org Fri Apr 16 11:03:48 2010 From: nick at foobar.org (Nick Hilliard) Date: Fri, 16 Apr 2010 17:03:48 +0100 Subject: CX4 to XFP In-Reply-To: <4BC886E3.3080006@bogus.com> References: <4BC886E3.3080006@bogus.com> Message-ID: <4BC88A64.2040402@foobar.org> On 16/04/2010 16:48, Joel Jaeggli wrote: > the cx4 interface is xaui 4x3Gb/s, as is xenpack. xfp is xfi 1 x 10Gb/s > so connecting the two requires a serdes device. you're mixing up interfaces here. This is certainly true of the electrical interface between transceiver and transceiver port. However, the client side interface is standard CX4, so any CX4 device should work fine, including XFP CX4 (which - unlike most XFPs - will contain a serdes). Nick From khomyakov.andrey at gmail.com Fri Apr 16 11:04:51 2010 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Fri, 16 Apr 2010 12:04:51 -0400 Subject: Router for Metro Ethernet In-Reply-To: <73D0FF09E78149C0AFF6BAFFA558B2E7@flamdt01> References: <017265BF3B9640499754DD48777C3D20685A19F1BC@MBX9.EXCHPROD.USA.NET> <73D0FF09E78149C0AFF6BAFFA558B2E7@flamdt01> Message-ID: I'd like to see the actual benchmarks. Something similar to routerperformance.pdf spreadsheet, but something more recent. Seems like those resources are alone available for partners. I've been following this thread, but no one has pointed out any documentation yet. Just speculation and personal experiences. Here is what Kapela sent me http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerperformance.pdf And I also found http://www.cisco.com/web/partners/downloads/765/tools/quickreference/switchperformance.pdf But coincidentally, I'm trying to spec out some gear to terminate 100Mbps metro eth and am wondering how a 4503 with a Sup6 will do (i have that on shelf) or a 4900m with QoS enabled and so on. Or do I need to actually get a proper router for that. I can't find any info on that. Does anyone have any resources that you use to make these decisions? Andrey -- Andrey Khomyakov [khomyakov.andrey at gmail.com] From lowen at pari.edu Fri Apr 16 11:08:34 2010 From: lowen at pari.edu (Lamar Owen) Date: Fri, 16 Apr 2010 12:08:34 -0400 Subject: DSL "aggregation".... NO In-Reply-To: <26CF6BC367161D4BAFC39B6ED6F885F3021901CC@TNEXPRD.hottopic.com> References: <26CF6BC367161D4BAFC39B6ED6F885F3021901CC@TNEXPRD.hottopic.com> Message-ID: <201004161208.34969.lowen@pari.edu> On Thursday 15 April 2010 05:05:05 pm Bill Lewis wrote: > Since I'm told that DSL aggregation / mux is currently not possible, we > are looking at doing stream splitting via a technology like FatPipe > uses. Anyone have this in production usage? Or something similar? No IMA over DSL? (IMA = Inverse Multiplexing over ATM). Used IMA over T1 before on an 8510..... From ctracy at es.net Fri Apr 16 11:12:12 2010 From: ctracy at es.net (Chris Tracy) Date: Fri, 16 Apr 2010 12:12:12 -0400 Subject: JUNIPER M7i CFLOW Sampling for L2 Vlans In-Reply-To: <4BC887C8.7090709@uol.com.br> References: <4BC887C8.7090709@uol.com.br> Message-ID: > It is possible to get cflow working in a L2 way ? Hi Giuliano, The short answer is, unfortunately, no. NetFlow v5 does not have any fields for Layer 2 information: http://netflow.caligare.com/netflow_v5.htm Although NetFlow v9 does have such fields, you (a) only get NetFlow v9 functionality on a Juniper if you have a Services PIC installed and (b) are limited by the NetFlow v9 templates that JUNOS implements. See the section titled "Fields Included in Each Template Type" for a description of each NetFlow v9 template at http://www.juniper.net/techpubs/en_US/junos9.5/information-products/topic-collections/config-guide-services/services-configuring-flow-aggregation-to-use-version-9-flow-templates.html. Juniper supports sFlow (which would give you L2 info) on their EX switches, but not on their routers. Perhaps when/if IPFIX support comes along, you might be able to get what you are looking for. You could use port mirroring or an optical tap with various open-source tools running on a Unix host to do the kind of monitoring you are looking for. Cheers, -Chris On Apr 16, 2010, at 11:52 AM, GIULIANO (UOL) wrote: > People, > > Good afternoon, > > We have a curious situation in a client's environment. > > It has a M7i router with 2 IQ2E (4 GE) PICs. > > It wants one of its PICs plugged into a L2 switch (802.1Q Trunk Mode) > and the another one plugged (via 1 giga of 4 ports only) to another L2 > switch. > > > M7i > / \ > S1 S2 > > > Both Giga ports are simpled configured like: > > nterfaces { > ge-0/0/0 { > vlan-tagging; > > nterfaces { > ge-0/1/0 { > vlan-tagging; > > > L2 Trunk Ethernet only without L3 configuration. > > It is possible to get flow information about the encapsulated vlans > (10,20,30,40, etc) inside the trunk traffic ? ... without configuring ip > (4 or 6) or creating vlan interfaces ? > > It is possible to get cflow working in a L2 way ? > > Does anyone has configured it before using JUNIPER ? Can you send or > point to me some samples of configuration ? > > Thanks a lot, > > Giuliano > > > > > > -- Chris Tracy Energy Sciences Network (ESnet) Lawrence Berkeley National Laboratory From pl+list at pmacct.net Fri Apr 16 13:09:21 2010 From: pl+list at pmacct.net (Paolo Lucente) Date: Fri, 16 Apr 2010 18:09:21 +0000 Subject: JUNIPER M7i CFLOW Sampling for L2 Vlans In-Reply-To: References: <4BC887C8.7090709@uol.com.br> Message-ID: <20100416180921.GA804@moussaka.pmacct.net> Besides the Juniper specifics on which i do agree. The fact that NetFlow v5 doesn't carry L2 information doesn't per-se imply it can't be theorically applied to L2 interfaces and report on upper layers - making it fair, on a multi-layer thing. Which is the underlying issue here. Cheers, Paolo On Fri, Apr 16, 2010 at 12:12:12PM -0400, Chris Tracy wrote: > > It is possible to get cflow working in a L2 way ? > > Hi Giuliano, > > The short answer is, unfortunately, no. > > NetFlow v5 does not have any fields for Layer 2 information: http://netflow.caligare.com/netflow_v5.htm > > Although NetFlow v9 does have such fields, you (a) only get NetFlow v9 functionality on a Juniper if you have a Services PIC installed and (b) are limited by the NetFlow v9 templates that JUNOS implements. See the section titled "Fields Included in Each Template Type" for a description of each NetFlow v9 template at http://www.juniper.net/techpubs/en_US/junos9.5/information-products/topic-collections/config-guide-services/services-configuring-flow-aggregation-to-use-version-9-flow-templates.html. > > Juniper supports sFlow (which would give you L2 info) on their EX switches, but not on their routers. Perhaps when/if IPFIX support comes along, you might be able to get what you are looking for. > > You could use port mirroring or an optical tap with various open-source tools running on a Unix host to do the kind of monitoring you are looking for. > > Cheers, > -Chris > > > On Apr 16, 2010, at 11:52 AM, GIULIANO (UOL) wrote: > > > People, > > > > Good afternoon, > > > > We have a curious situation in a client's environment. > > > > It has a M7i router with 2 IQ2E (4 GE) PICs. > > > > It wants one of its PICs plugged into a L2 switch (802.1Q Trunk Mode) > > and the another one plugged (via 1 giga of 4 ports only) to another L2 > > switch. > > > > > > M7i > > / \ > > S1 S2 > > > > > > Both Giga ports are simpled configured like: > > > > nterfaces { > > ge-0/0/0 { > > vlan-tagging; > > > > nterfaces { > > ge-0/1/0 { > > vlan-tagging; > > > > > > L2 Trunk Ethernet only without L3 configuration. > > > > It is possible to get flow information about the encapsulated vlans > > (10,20,30,40, etc) inside the trunk traffic ? ... without configuring ip > > (4 or 6) or creating vlan interfaces ? > > > > It is possible to get cflow working in a L2 way ? > > > > Does anyone has configured it before using JUNIPER ? Can you send or > > point to me some samples of configuration ? > > > > Thanks a lot, > > > > Giuliano > > > > > > > > > > > > > > -- > Chris Tracy > Energy Sciences Network (ESnet) > Lawrence Berkeley National Laboratory > > > > > From cscora at apnic.net Fri Apr 16 13:10:56 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 17 Apr 2010 04:10:56 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201004161810.o3GIAuc7025125@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. 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 17 Apr, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 318575 Prefixes after maximum aggregation: 147127 Deaggregation factor: 2.17 Unique aggregates announced to Internet: 154828 Total ASes present in the Internet Routing Table: 33808 Prefixes per ASN: 9.42 Origin-only ASes present in the Internet Routing Table: 29345 Origin ASes announcing only one prefix: 14328 Transit ASes present in the Internet Routing Table: 4463 Transit-only ASes present in the Internet Routing Table: 103 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (32374) 19 Prefixes from unregistered ASNs in the Routing Table: 554 Unregistered ASNs in the Routing Table: 131 Number of 32-bit ASNs allocated by the RIRs: 519 Prefixes from 32-bit ASNs in the Routing Table: 571 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 212 Number of addresses announced to Internet: 2229015040 Equivalent to 132 /8s, 220 /16s and 18 /24s Percentage of available address space announced: 60.1 Percentage of allocated address space announced: 66.1 Percentage of available address space allocated: 90.9 Percentage of address space in use by end-sites: 82.2 Total number of prefixes smaller than registry allocations: 152695 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 76197 Total APNIC prefixes after maximum aggregation: 26400 APNIC Deaggregation factor: 2.89 Prefixes being announced from the APNIC address blocks: 73044 Unique aggregates announced from the APNIC address blocks: 32021 APNIC Region origin ASes present in the Internet Routing Table: 3996 APNIC Prefixes per ASN: 18.28 APNIC Region origin ASes announcing only one prefix: 1098 APNIC Region transit ASes present in the Internet Routing Table: 620 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 507789376 Equivalent to 30 /8s, 68 /16s and 64 /24s Percentage of available APNIC address space announced: 75.7 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: 133500 Total ARIN prefixes after maximum aggregation: 68798 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 106421 Unique aggregates announced from the ARIN address blocks: 40586 ARIN Region origin ASes present in the Internet Routing Table: 13635 ARIN Prefixes per ASN: 7.80 ARIN Region origin ASes announcing only one prefix: 5274 ARIN Region transit ASes present in the Internet Routing Table: 1356 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 725464096 Equivalent to 43 /8s, 61 /16s and 180 /24s Percentage of available ARIN address space announced: 61.8 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: 73035 Total RIPE prefixes after maximum aggregation: 42605 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 65990 Unique aggregates announced from the RIPE address blocks: 43438 RIPE Region origin ASes present in the Internet Routing Table: 14368 RIPE Prefixes per ASN: 4.59 RIPE Region origin ASes announcing only one prefix: 7437 RIPE Region transit ASes present in the Internet Routing Table: 2143 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 421255840 Equivalent to 25 /8s, 27 /16s and 218 /24s Percentage of available RIPE address space announced: 78.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, 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, 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: 28349 Total LACNIC prefixes after maximum aggregation: 6735 LACNIC Deaggregation factor: 4.21 Prefixes being announced from the LACNIC address blocks: 26715 Unique aggregates announced from the LACNIC address blocks: 13783 LACNIC Region origin ASes present in the Internet Routing Table: 1274 LACNIC Prefixes per ASN: 20.97 LACNIC Region origin ASes announcing only one prefix: 415 LACNIC Region transit ASes present in the Internet Routing Table: 222 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 24 Number of LACNIC addresses announced to Internet: 72463104 Equivalent to 4 /8s, 81 /16s and 179 /24s Percentage of available LACNIC address space announced: 72.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6488 Total AfriNIC prefixes after maximum aggregation: 1782 AfriNIC Deaggregation factor: 3.64 Prefixes being announced from the AfriNIC address blocks: 4825 Unique aggregates announced from the AfriNIC address blocks: 1517 AfriNIC Region origin ASes present in the Internet Routing Table: 354 AfriNIC Prefixes per ASN: 13.63 AfriNIC Region origin ASes announcing only one prefix: 104 AfriNIC Region transit ASes present in the Internet Routing Table: 78 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC addresses announced to Internet: 14019840 Equivalent to 0 /8s, 213 /16s and 237 /24s Percentage of available AfriNIC address space announced: 41.8 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 1843 8406 479 Korea Telecom (KIX) 17488 1312 136 127 Hathway IP Over Cable Interne 4755 1300 290 147 TATA Communications formerly 7545 1111 202 106 TPG Internet Pty Ltd 4134 1030 20395 398 CHINANET-BACKBONE 17974 1007 281 18 PT TELEKOMUNIKASI INDONESIA 9583 985 72 485 Sify Limited 24560 879 303 168 Bharti Airtel Ltd., Telemedia 4808 844 1587 215 CNCGROUP IP network: China169 17908 844 193 55 Tata Communications 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 4006 3838 296 bellsouth.net, inc. 4323 3825 1099 398 Time Warner Telecom 1785 1752 699 133 PaeTec Communications, Inc. 7018 1559 5740 990 AT&T WorldNet Services 20115 1523 1500 658 Charter Communications 2386 1331 619 934 AT&T Data Communications Serv 3356 1229 10960 430 Level 3 Communications, LLC 6478 1195 248 166 AT&T Worldnet Services 11492 1150 222 14 Cable One 22773 1141 2605 71 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 35805 614 56 6 United Telecom of Georgia 3292 447 1899 389 TDC Tele Danmark 30890 434 99 202 Evolva Telecom 702 421 1870 332 UUNET - Commercial IP service 8551 401 356 37 Bezeq International 8866 398 117 18 Bulgarian Telecommunication C 3301 364 1413 319 TeliaNet Sweden 3320 362 7072 315 Deutsche Telekom AG 3215 348 3238 104 France Telecom Transpac 12479 329 576 5 Uni2 Autonomous System 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 1542 2964 241 UniNet S.A. de C.V. 10620 1035 239 157 TVCABLE BOGOTA 28573 917 735 89 NET Servicos de Comunicao S.A 7303 701 362 103 Telecom Argentina Stet-France 22047 545 310 15 VTR PUNTO NET S.A. 6503 540 171 211 AVANTEL, S.A. 18881 536 268 11 Global Village Telecom 7738 477 922 30 Telecomunicacoes da Bahia S.A 3816 458 195 70 Empresa Nacional de Telecomun 14117 453 30 13 Telefonica del Sur S.A. 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 750 189 9 TEDATA 24863 712 144 41 LINKdotNET AS number 36992 545 112 161 Etisalat MISR 3741 273 852 232 The Internet Solution 33776 262 14 11 Starcomms Nigeria Limited 2018 215 230 111 Tertiary Education Network 6713 176 167 12 Itissalat Al-MAGHRIB 29571 172 19 9 Ci Telecom Autonomous system 24835 147 78 10 RAYA Telecom - Egypt 29975 133 506 14 Vodacom 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 4006 3838 296 bellsouth.net, inc. 4323 3825 1099 398 Time Warner Telecom 4766 1843 8406 479 Korea Telecom (KIX) 1785 1752 699 133 PaeTec Communications, Inc. 7018 1559 5740 990 AT&T WorldNet Services 8151 1542 2964 241 UniNet S.A. de C.V. 20115 1523 1500 658 Charter Communications 2386 1331 619 934 AT&T Data Communications Serv 17488 1312 136 127 Hathway IP Over Cable Interne 4755 1300 290 147 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3825 3427 Time Warner Telecom 1785 1752 1619 PaeTec Communications, Inc. 4766 1843 1364 Korea Telecom (KIX) 8151 1542 1301 UniNet S.A. de C.V. 17488 1312 1185 Hathway IP Over Cable Interne 4755 1300 1153 TATA Communications formerly 11492 1150 1136 Cable One 22773 1141 1070 Cox Communications, Inc. 18566 1059 1049 Covad Communications 6478 1195 1029 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 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 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 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.0.0.0/8 38639 NTT Communications Corporatio 41.190.64.0/22 28683 Office des Postes et telecomm 41.202.96.0/19 29571 Ci Telecom Autonomous system 41.220.144.0/20 36918 ORASCOM TELECOM ALGERIE VSAT 41.220.159.0/24 36918 ORASCOM TELECOM ALGERIE VSAT 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 26452 Local Communications Networks 41.223.196.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:66 /12:191 /13:392 /14:680 /15:1246 /16:11038 /17:5219 /18:8886 /19:18277 /20:22438 /21:22449 /22:29284 /23:28907 /24:166443 /25:986 /26:1227 /27:626 /28:140 /29:9 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2573 4006 bellsouth.net, inc. 4323 2340 3825 Time Warner Telecom 4766 1479 1843 Korea Telecom (KIX) 1785 1214 1752 PaeTec Communications, Inc. 17488 1063 1312 Hathway IP Over Cable Interne 11492 1061 1150 Cable One 18566 1040 1059 Covad Communications 10620 944 1035 TVCABLE BOGOTA 7018 936 1559 AT&T WorldNet Services 7011 838 1114 Citizens Utilities Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:257 12:1999 13:10 15:23 16:3 17:8 20:25 24:1415 27:28 32:48 33:12 38:656 40:99 41:1872 44:3 46:1 47:25 52:6 55:6 56:2 57:24 58:710 59:561 60:433 61:1126 62:1008 63:1973 64:3833 65:2361 66:4179 67:1792 68:1052 69:2819 70:709 71:238 72:1857 73:2 74:2251 75:246 76:308 77:841 78:606 79:392 80:983 81:779 82:456 83:452 84:690 85:1035 86:378 87:698 88:327 89:1555 90:85 91:2718 92:459 93:1103 94:1388 95:584 96:235 97:305 98:549 99:26 109:453 110:301 111:472 112:246 113:267 114:388 115:615 116:1025 117:627 118:406 119:923 120:148 121:847 122:1415 123:862 124:1105 125:1281 128:208 129:204 130:160 131:560 132:246 133:17 134:196 135:44 136:223 137:167 138:253 139:94 140:480 141:136 142:374 143:383 144:471 145:52 146:428 147:169 148:585 149:286 150:152 151:172 152:274 153:170 154:2 155:328 156:187 157:324 158:107 159:366 160:315 161:178 162:269 163:169 164:400 165:529 166:511 167:405 168:802 169:158 170:734 171:50 172:1 173:643 174:652 175:71 178:46 180:403 181:9 182:33 183:247 184:34 186:355 187:295 188:1229 189:720 190:3634 192:5735 193:4661 194:3362 195:2794 196:1167 198:3555 199:3421 200:5303 201:1519 202:7928 203:8314 204:4056 205:2334 206:2522 207:3040 208:3935 209:3470 210:2509 211:1220 212:1700 213:1680 214:596 215:67 216:4579 217:1534 218:494 219:418 220:1104 221:382 222:316 End of report From franck at genius.com Fri Apr 16 13:28:41 2010 From: franck at genius.com (Franck Martin) Date: Sat, 17 Apr 2010 06:28:41 +1200 (MAGST) Subject: Weekly Routing Table Report In-Reply-To: <201004161810.o3GIAuc7025125@thyme.apnic.net> Message-ID: <324717.543.1271442518336.JavaMail.franck@franck-martins-macbook-pro.local> Would it not be time, to have the IPv6 equivalent of this table report? 5% of the Internet is IPv6, that's an interesting threshold that was just passed. ----- Original Message ----- From: "Routing Analysis Role Account" To: apops at apops.net, nanog at nanog.org, routing-wg at ripe.net, afnog at afnog.org, ausnog at ausnog.net, sanog at sanog.org Sent: Saturday, 17 April, 2010 6:10:56 AM Subject: Weekly Routing Table Report This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-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 17 Apr, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- From jmamodio at gmail.com Fri Apr 16 15:50:19 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 16 Apr 2010 15:50:19 -0500 Subject: Weekly Routing Table Report In-Reply-To: <324717.543.1271442518336.JavaMail.franck@franck-martins-macbook-pro.local> References: <201004161810.o3GIAuc7025125@thyme.apnic.net> <324717.543.1271442518336.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Fri, Apr 16, 2010 at 1:28 PM, Franck Martin wrote: > Would it not be time, to have the IPv6 equivalent of this table report? +1 It wold be nice to see how things gradually change as the 5% becomes larger. Cheers Jorge From zaid at zaidali.com Fri Apr 16 15:59:14 2010 From: zaid at zaidali.com (Zaid Ali) Date: Fri, 16 Apr 2010 13:59:14 -0700 Subject: Weekly Routing Table Report In-Reply-To: <324717.543.1271442518336.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On 4/16/10 11:28 AM, "Franck Martin" wrote: > Would it not be time, to have the IPv6 equivalent of this table report? > > 5% of the Internet is IPv6, that's an interesting threshold that was just > passed. I think that time has come :) Zaid From cidr-report at potaroo.net Fri Apr 16 17:00:05 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 16 Apr 2010 22:00:05 GMT Subject: BGP Update Report Message-ID: <201004162200.o3GM051R034470@wattle.apnic.net> BGP Update Report Interval: 08-Apr-10 -to- 15-Apr-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23724 35122 3.4% 2.6 -- CHINANET-IDC-BJ-AP IDC, China Telecommunications Corporation 2 - AS9829 16311 1.6% 32.6 -- BSNL-NIB National Internet Backbone 3 - AS28477 11441 1.1% 1271.2 -- Universidad Autonoma del Esstado de Morelos 4 - AS14522 11367 1.1% 61.4 -- Satnet 5 - AS17974 10727 1.0% 11.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 6 - AS33475 10232 1.0% 43.5 -- RSN-1 - RockSolid Network, Inc. 7 - AS25620 9049 0.9% 74.8 -- COTAS LTDA. 8 - AS12479 8447 0.8% 444.6 -- UNI2-AS Uni2 - Lince telecomunicaciones 9 - AS26025 8391 0.8% 8391.0 -- COC - City of Calgary 10 - AS16569 8211 0.8% 8211.0 -- ASN-CITY-OF-CALGARY - City of Calgary 11 - AS35805 8071 0.8% 13.1 -- UTG-AS United Telecom AS 12 - AS17672 6886 0.7% 62.6 -- CHINATELECOM-HE-AS-AP asn for Hebei Provincial Net of CT 13 - AS19647 6310 0.6% 394.4 -- HPOD20001 - Hewlett-Packard Operation Division 14 - AS45899 6241 0.6% 26.9 -- VNPT-AS-VN VNPT Corp 15 - AS33776 5905 0.6% 22.6 -- STARCOMMS-ASN 16 - AS18747 5870 0.6% 24.1 -- IFX-NW - IFX Communication Ventures, Inc. 17 - AS7545 5583 0.5% 4.9 -- TPG-INTERNET-AP TPG Internet Pty Ltd 18 - AS14420 5425 0.5% 14.4 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 19 - AS4847 5173 0.5% 16.3 -- CNIX-AP China Networks Inter-Exchange 20 - AS10620 4982 0.5% 5.8 -- Telmex Colombia S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS26025 8391 0.8% 8391.0 -- COC - City of Calgary 2 - AS16569 8211 0.8% 8211.0 -- ASN-CITY-OF-CALGARY - City of Calgary 3 - AS5691 2796 0.3% 2796.0 -- MITRE-AS-5 - The MITRE Corporation 4 - AS28477 11441 1.1% 1271.2 -- Universidad Autonoma del Esstado de Morelos 5 - AS45670 760 0.1% 760.0 -- SOFTCRYLICNET1-IN #160,North Usman Road, Third Floor 6 - AS3397 671 0.1% 671.0 -- DAVINCI - Davinci Broadband Inc. 7 - AS28052 565 0.1% 565.0 -- Arte Radiotelevisivo Argentino 8 - AS44086 556 0.1% 556.0 -- YELLIS-AS YELLIS Services 9 - AS42842 1487 0.1% 495.7 -- HELIOS-TV-AS Helios TV Ltd. 10 - AS38890 4763 0.5% 476.3 -- CITS-KITINET-AS-PH Internet Service Provider /IDC 11 - AS27027 446 0.0% 446.0 -- ANBELL ASN-ANBELL 12 - AS12479 8447 0.8% 444.6 -- UNI2-AS Uni2 - Lince telecomunicaciones 13 - AS10445 2444 0.2% 407.3 -- HTG - Huntleigh Telcom 14 - AS19647 6310 0.6% 394.4 -- HPOD20001 - Hewlett-Packard Operation Division 15 - AS11613 370 0.0% 370.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 16 - AS16120 739 0.1% 369.5 -- UMFT 17 - AS20036 1470 0.1% 367.5 -- MICRO-R-D - Micro R & D 18 - AS11032 345 0.0% 345.0 -- UQ - Universite du Quebec 19 - AS9145 282 0.0% 282.0 -- EWETEL EWE TEL GmbH 20 - AS17767 263 0.0% 263.0 -- TECHNO-BD-AS TechnoBD AS for local peering and transit. Chittagong TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 200.13.36.0/24 11393 1.0% AS28477 -- Universidad Autonoma del Esstado de Morelos 2 - 208.98.231.0/24 8391 0.7% AS26025 -- COC - City of Calgary 3 - 208.98.230.0/24 8211 0.7% AS16569 -- ASN-CITY-OF-CALGARY - City of Calgary 4 - 206.184.16.0/24 2873 0.2% AS174 -- COGENT Cogent/PSI 5 - 192.12.120.0/24 2796 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 6 - 85.60.194.0/23 2665 0.2% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 7 - 85.60.192.0/23 2425 0.2% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 8 - 143.138.107.0/24 2050 0.2% AS747 -- TAEGU-AS - Headquarters, USAISC 9 - 85.204.64.0/23 1953 0.2% AS6746 -- ASTRAL UPC Romania Srl, Romania 10 - 196.44.176.0/20 1639 0.1% AS31856 -- CABSAS 11 - 219.148.128.0/20 1629 0.1% AS17672 -- CHINATELECOM-HE-AS-AP asn for Hebei Provincial Net of CT 12 - 219.148.144.0/20 1629 0.1% AS17672 -- CHINATELECOM-HE-AS-AP asn for Hebei Provincial Net of CT 13 - 222.222.0.0/16 1629 0.1% AS17672 -- CHINATELECOM-HE-AS-AP asn for Hebei Provincial Net of CT 14 - 222.223.0.0/16 1628 0.1% AS17672 -- CHINATELECOM-HE-AS-AP asn for Hebei Provincial Net of CT 15 - 85.60.208.0/21 1344 0.1% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 16 - 85.60.208.0/22 1340 0.1% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 17 - 180.233.225.0/24 1320 0.1% AS38680 -- CMBHK-AS-KR CMB 18 - 90.150.0.0/24 1260 0.1% AS35400 -- MFIST Interregoinal Organization Network Technologies 19 - 41.205.160.0/20 1088 0.1% AS33776 -- STARCOMMS-ASN 20 - 124.254.32.0/19 974 0.1% AS4847 -- CNIX-AP China Networks Inter-Exchange 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 Apr 16 17:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 16 Apr 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201004162200.o3GM00AO034443@wattle.apnic.net> This report has been generated at Fri Apr 16 21:11:37 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 09-04-10 319885 197244 10-04-10 320153 197325 11-04-10 320354 197329 12-04-10 320343 197187 13-04-10 320093 197504 14-04-10 320819 197034 15-04-10 320344 197768 16-04-10 320934 198073 AS Summary 34163 Number of ASes in routing system 14569 Number of ASes announcing only one prefix 4412 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 97134080 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'). --- 16Apr10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 321751 198575 123176 38.3% All ASes AS6389 4005 301 3704 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4412 1366 3046 69.0% TWTC - tw telecom holdings, inc. AS4766 1843 493 1350 73.3% KIXS-AS-KR Korea Telecom AS22773 1141 76 1065 93.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 1059 33 1026 96.9% COVAD - Covad Communications Co. AS17488 1312 334 978 74.5% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1544 632 912 59.1% Uninet S.A. de C.V. AS7545 1129 225 904 80.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS10620 1035 161 874 84.4% Telmex Colombia S.A. AS19262 1090 247 843 77.3% VZGNI-TRANSIT - Verizon Internet Services Inc. AS4755 1300 465 835 64.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS6478 1195 390 805 67.4% ATT-INTERNET3 - AT&T WorldNet Services AS5668 808 199 609 75.4% AS-5668 - CenturyTel Internet Holdings, Inc. AS24560 878 273 605 68.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4804 678 84 594 87.6% MPX-AS Microplex PTY LTD AS4808 844 254 590 69.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7303 701 111 590 84.2% Telecom Argentina S.A. AS17908 844 259 585 69.3% TCISL Tata Communications AS35805 614 39 575 93.6% UTG-AS United Telecom AS AS1785 1752 1179 573 32.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS7018 1559 992 567 36.4% ATT-INTERNET4 - AT&T WorldNet Services AS18101 669 111 558 83.4% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS8452 887 332 555 62.6% TEDATA TEDATA AS3356 1230 704 526 42.8% LEVEL3 Level 3 Communications AS4780 673 173 500 74.3% SEEDNET Digital United Inc. AS22047 545 48 497 91.2% VTR BANDA ANCHA S.A. AS17676 573 85 488 85.2% GIGAINFRA Softbank BB Corp. AS9443 555 74 481 86.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7011 1115 666 449 40.3% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS11492 1150 702 448 39.0% CABLEONE - CABLE ONE, INC. Total 37140 11008 26132 70.4% Top 30 total Possible Bogus Routes 14.0.0.0/8 AS38639 HANABI NTT Communications Corporation 41.190.64.0/22 AS28683 BENINTELECOM 41.202.96.0/19 AS29571 CITelecom-AS 41.220.144.0/20 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 41.220.159.0/24 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 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 AS26452 BRING-AS - BringCom, Inc. 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.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales Telesat S.A. 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 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 78.41.80.0/24 AS29158 DE-IP69 Tux-Service 78.41.81.0/24 AS29158 DE-IP69 Tux-Service 78.41.82.0/24 AS29158 DE-IP69 Tux-Service 78.41.83.0/24 AS29158 DE-IP69 Tux-Service 78.41.84.0/24 AS29158 DE-IP69 Tux-Service 78.41.86.0/24 AS29158 DE-IP69 Tux-Service 78.41.87.0/24 AS29158 DE-IP69 Tux-Service 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 80.250.32.0/22 AS21452 SKANNET-IBADAN SKANNET IP Network 80.250.32.0/23 AS21452 SKANNET-IBADAN SKANNET IP Network 80.250.34.0/23 AS21452 SKANNET-IBADAN SKANNET IP Network 110.34.40.0/22 AS24399 ABN-PEERING-AS-AP Asia Broadcast Networks Peering 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. 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 119.42.144.0/21 AS45753 NETSEC-HK Unit 1205-1207 119.42.144.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.145.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.146.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.147.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.148.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.149.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.150.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.151.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.160.200.0/23 AS45122 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 178.18.128.0/20 AS25459 NEDZONE-AS NedZone Internet BV 181.82.15.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.16.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.17.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 181.82.18.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 181.82.45.0/24 AS38414 GOESH-AS-KR Gyeonggi siheung office of education 181.82.46.0/24 AS38414 GOESH-AS-KR Gyeonggi siheung office of education 181.82.47.0/24 AS38414 GOESH-AS-KR Gyeonggi siheung office of education 181.82.101.0/24 AS9706 PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 181.82.102.0/24 AS9706 PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 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.45.0/24 AS2905 TICSA-ASN 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.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS 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.29.40.0/22 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 196.32.96.0/20 AS33787 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.254.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 AS33052 VZUNET - Verizon Data Services 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.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 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 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.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - 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.52.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company 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.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.77.138.0/23 AS24487 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.89.8.0/22 AS6648 BAYAN-TELECOMMUNICATIONS Bayan Telecommunications, Inc. 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.166.166.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 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.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.179.154.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.124.96.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.124.100.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.124.104.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.215.52.0/22 AS18101 RIL-IDC Reliance Infocom Ltd Internet Data Centre, 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.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 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.66.152.0/24 AS18499 208.66.153.0/24 AS18499 208.66.154.0/24 AS18499 208.66.155.0/24 AS18499 208.66.156.0/24 AS18499 208.66.157.0/24 AS18499 208.66.158.0/24 AS18499 208.66.159.0/24 AS18499 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.177.160.0/24 AS18499 209.177.161.0/24 AS18499 209.177.162.0/24 AS18499 209.177.163.0/24 AS18499 209.177.164.0/24 AS18499 209.177.165.0/24 AS18499 209.177.166.0/24 AS18499 209.177.167.0/24 AS18499 209.177.168.0/24 AS18499 209.177.169.0/24 AS18499 209.177.170.0/24 AS18499 209.177.171.0/24 AS18499 209.177.172.0/24 AS18499 209.177.173.0/24 AS18499 209.177.174.0/24 AS18499 209.177.175.0/24 AS18499 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.144.240.0/23 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.243.0/24 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.244.0/22 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, 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 223.0.0.0/8 AS38639 HANABI NTT Communications Corporation 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 mike-nanog at tiedyenetworks.com Fri Apr 16 17:25:33 2010 From: mike-nanog at tiedyenetworks.com (Mike) Date: Fri, 16 Apr 2010 15:25:33 -0700 Subject: Senderbase is offbase, need some help Message-ID: <4BC8E3DD.6050806@tiedyenetworks.com> Gang, I've tried to get the attention of senderbase, which is claiming activity from my address space which is in fact either un-routed or within dynamic subscriber blocks that have outbound smtp filtering in effect. Unfortunately, senderbase refuses to acknowledge the problem in their database nor back up their claims with any evidence to the contrary other than these ips are listed in their database and that's that. I realise this may not strictly be the domain of nanog but I would think that quality of services such like senderbase, as measured in both false positives as well as their abillity to act on them, would be, since many here use and depend on these services. I don't understand how or why senderbase would list unrouted address space and further give me grief over the reporting of it "Unless the daily volume magnitude shows something > 1, I would not be too worried", but accuracy counts and you won't have my business unless you can demonstrate some. Mike- From lazlor at lotaris.org Fri Apr 16 18:58:15 2010 From: lazlor at lotaris.org (Allen Smith) Date: Fri, 16 Apr 2010 17:58:15 -0600 Subject: Need ATT Internet 2nd tier support Message-ID: <4BC8F997.2040905@lotaris.org> [My apologies for spamming the list] Seeing crazyness within AT&T network. Tier one circuit people are of no help as circuits appear fine. I've talked to a number of Tier 1 techs today. The 138ms at hot 5 must be a cross country bounce, but I am going from boi to sjc through seattle. Sporadically all traffic stops at hop 4 for 10-30 seconds. 3 12.239.24.129 (12.239.24.129) 2 ms 1 ms 1 ms 4 12.248.224.205 (12.248.224.205) 11 ms 11 ms 11 ms 5 cr2.st6wa.ip.att.net (12.122.111.98) [MPLS: Label 16868 Exp 0] 139 ms 139 ms 138 ms 6 cr2.ptdor.ip.att.net (12.122.30.149) [MPLS: Label 21452 Exp 0] More labels 138 ms More labels 138 ms More labels 139 ms 7 cr1.ptdor.ip.att.net (12.122.30.141) [MPLS: Label 21324 Exp 0] More labels 139 ms More labels 139 ms More labels 138 ms 8 cr1.sffca.ip.att.net (12.122.30.146) [MPLS: Label 0 Exp 0] More labels 139 ms More labels 138 ms More labels 139 ms 9 cr81.sj2ca.ip.att.net (12.122.1.118) More labels 138 ms More labels 138 ms More labels 143 ms 10 gar9.sffca.ip.att.net (12.122.110.25) 143 ms 137 ms 137 ms 11 12.90.69.58 (12.90.69.58) 276 ms 271 ms 270 ms Can anyone from AT&Ts core router group please help? Thanks, -Allen From scott at doc.net.au Sat Apr 17 00:28:04 2010 From: scott at doc.net.au (Scott Howard) Date: Fri, 16 Apr 2010 22:28:04 -0700 Subject: Tracking down reverse for ip In-Reply-To: References: <91522911795E174F97E7EF8B792A1031228A4C@ltiserver.LTI.local> <1271365159.13545.243.camel@petrie> Message-ID: On Thu, Apr 15, 2010 at 10:52 PM, James Hess wrote: > On Thu, Apr 15, 2010 at 3:59 PM, William Pitcock > wrote: > > For someone who is a CCNA, Mikrotik Certified Whatever, etc, etc, etc, > > you really should know how to use dig(1). > > Certifications usually only suggest certain skills or knowledge they > were designed to validate, and sometimes might fail even at that; > dig(1) or detailed DNS knowledge is not scoped within either of those > certs, as far as I know.. > Whilst that's almost certainly right, I had a lot of trouble finding a google search that _didn't_ return something relevant as it's first hit (such as ARIN's whois, or one of several guides on how to use dig/etc for reverse DNS). Of course, they don't teach google in any certification I've come across either, but... Scott From vixie at isc.org Sat Apr 17 01:53:50 2010 From: vixie at isc.org (Paul Vixie) Date: Sat, 17 Apr 2010 06:53:50 +0000 Subject: getting the hint In-Reply-To: <4BC79F9E.5060702@cox.net> (Larry Sheldon's message of "Thu, 15 Apr 2010 18:22:06 -0500") References: <1E8B940C5E21014AB8BE70B975D40EDB03957DE9@bert.HiberniaAtlantic.local> <10DEA485-EC47-4D6C-8A2B-7BF3AB6BB5B0@gmail.com> <4BC79BEF.8090409@dcrocker.net> <4BC79F9E.5060702@cox.net> Message-ID: Larry Sheldon writes: >> The only response that works -- and even this is not guaranteed -- is >> shunning. >> >> Drop the message. Do not respond. Ever. > > And for the love of Pete, when somebody (as I have) makes a mistake and > does his bidding, tell the miscreant VIA PRIVATE EMAIL or a note tied to > a brick, but do not prate incessantly about it on the list. +1. -- Paul Vixie KI6YSY From jeroen at mompl.net Sat Apr 17 04:19:31 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Sat, 17 Apr 2010 02:19:31 -0700 Subject: OT: old farts recollecting -- Re: ASR1002 In-Reply-To: <1263923324.10985.4.camel@ub-g-d2> References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <201001191550193802132@gmail.com> <1263909572.18086.40.camel@ub-g-d2> <20100119160001.GA30743@reptiles.org> <1263923324.10985.4.camel@ub-g-d2> Message-ID: <4BC97D23.6070308@mompl.net> gordon b slater wrote: > On Tue, 2010-01-19 at 11:00 -0500, Jim Mercer wrote: >> for days now, i've been trying to remember a quotation, which i vaguely seem >> "the telephone, once commonly available in cities, ...." >> ring a bell for anyone? >> > Maybe it was a Gopher thing? > > This newfangled Googly-thing finds nothing - it'll never catch on. (rant, sorry) Ever noticed how a call to a cellphone in the next town sounds consistently horrible, yet a landline call to "farawayistan" sounds like it's coming from next door? Damn 3kbps vocoders... Regards, Jeroen (who still makes frequent landline-2-landline calls to "farawayistan" and is not yet an old fart(?)) From jim at reptiles.org Sat Apr 17 12:22:51 2010 From: jim at reptiles.org (Jim Mercer) Date: Sat, 17 Apr 2010 13:22:51 -0400 Subject: .cn / china registrars in US/canada ? Message-ID: <20100417172251.GA99018@reptiles.org> i am looking for a referral to a registrar who can get me a .cn domain, without registering it on my behalf then extorting me. i saw a notice that CNNIC suspended non-chinese registrars, but i haven't found anything telling me they have recinded that. can anyone give me clarification? thanx. -- Jim Mercer jim at reptiles.org +92 336 520-4504 "I'm Prime Minister of Canada, I live here and I'm going to take a leak." - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, "Who are you and where are you going?" From sethm at rollernet.us Sat Apr 17 12:37:35 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 17 Apr 2010 10:37:35 -0700 Subject: .cn / china registrars in US/canada ? In-Reply-To: <20100417172251.GA99018@reptiles.org> References: <20100417172251.GA99018@reptiles.org> Message-ID: <4BC9F1DF.4090207@rollernet.us> On 4/17/2010 10:22, Jim Mercer wrote: > > i am looking for a referral to a registrar who can get me a .cn domain, > without registering it on my behalf then extorting me. > > i saw a notice that CNNIC suspended non-chinese registrars, but i haven't > found anything telling me they have recinded that. > As far as I last heard, they haven't. ~Seth From lou at metron.com Sat Apr 17 13:31:24 2010 From: lou at metron.com (Lou Katz) Date: Sat, 17 Apr 2010 11:31:24 -0700 Subject: .cn / china registrars in US/canada ? In-Reply-To: <20100417172251.GA99018@reptiles.org> References: <20100417172251.GA99018@reptiles.org> Message-ID: <20100417183124.GA44682@metron.com> On Sat, Apr 17, 2010 at 01:22:51PM -0400, Jim Mercer wrote: > > i am looking for a referral to a registrar who can get me a .cn domain, > without registering it on my behalf then extorting me. > > i saw a notice that CNNIC suspended non-chinese registrars, but i haven't > found anything telling me they have recinded that. As an OpenSRS/Tucows reseller, I know that the PRC recently introduced some stringent regulations, and many, if not all registrars outside of China no longer will accept new registrations (though they can continue to maintain existing ones). > > can anyone give me clarification? > > thanx. > > -- > Jim Mercer jim at reptiles.org +92 336 520-4504 > "I'm Prime Minister of Canada, I live here and I'm going to take a leak." > - Lester Pearson in 1967, during a meeting between himself and > President Lyndon Johnson, whose Secret Service detail had taken over > Pearson's cottage retreat. At one point, a Johnson guard asked > Pearson, "Who are you and where are you going?" -- -=[L]=- If guns are outlawed, how will conservatives win any arguments? From bbillon-ml at splio.fr Sat Apr 17 13:44:49 2010 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Sat, 17 Apr 2010 20:44:49 +0200 Subject: .cn / china registrars in US/canada ? In-Reply-To: <20100417172251.GA99018@reptiles.org> References: <20100417172251.GA99018@reptiles.org> Message-ID: <4BCA01A1.5020506@splio.fr> > i saw a notice that CNNIC suspended non-chinese registrars, but i haven't > found anything telling me they have recinded that. > Where did you see that? From what I saw, registration is now limited to companies (not individuals anymore) providing business licences. As Lou said previously, registrars are allowed to maintain existing domains, at least for now. Official .cn registrars list is available there: http://www.cnnic.cn/html/Dir/2007/06/25/4671.htm I have some domains registrered by cnnames, though. From fergdawgster at gmail.com Sat Apr 17 13:53:08 2010 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sat, 17 Apr 2010 11:53:08 -0700 Subject: .cn / china registrars in US/canada ? In-Reply-To: <4BCA01A1.5020506@splio.fr> References: <20100417172251.GA99018@reptiles.org> <4BCA01A1.5020506@splio.fr> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Apr 17, 2010 at 11:44 AM, Benjamin Billon wrote: > >> i saw a notice that CNNIC suspended non-chinese registrars, but i >> haven't found anything telling me they have recinded that. >> > > Where did you see that? It was originally announced here: http://www.cnnic.net.cn/html/Dir/2009/12/12/5750.htm See also: http://krebsonsecurity.com/2010/03/spam-site-registrations-flee-china-for-r ussia/ FYI, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLygOOq1pz9mNUZTMRAj7DAKCIZzeGspJL+/Dozak+p1VFiJTu1gCgjUt4 z/bpggSpEwq6SkpOgOmr0zs= =qGA2 -----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 fw at deneb.enyo.de Sat Apr 17 14:40:29 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 17 Apr 2010 21:40:29 +0200 Subject: Senderbase is offbase, need some help In-Reply-To: <4BC8E3DD.6050806@tiedyenetworks.com> (Mike's message of "Fri, 16 Apr 2010 15:25:33 -0700") References: <4BC8E3DD.6050806@tiedyenetworks.com> Message-ID: <87ljclq34i.fsf@mid.deneb.enyo.de> * Mike: > I've tried to get the attention of senderbase, which is claiming > activity from my address space which is in fact either un-routed or > within dynamic subscriber blocks that have outbound smtp filtering in > effect. Could you share technical details on your filters, please? If you only filter incoming TCP packets from your customers with destination port 25, these filters might well be insufficient. From johnl at iecc.com Sat Apr 17 15:29:05 2010 From: johnl at iecc.com (John Levine) Date: 17 Apr 2010 20:29:05 -0000 Subject: Senderbase is offbase, need some help In-Reply-To: <4BC8E3DD.6050806@tiedyenetworks.com> Message-ID: <20100417202905.5412.qmail@simone.iecc.com> > I've tried to get the attention of senderbase, which is claiming >activity from my address space which is in fact either un-routed or >within dynamic subscriber blocks that have outbound smtp filtering in >effect. Unfortunately, senderbase refuses to acknowledge the problem in >their database nor back up their claims with any evidence to the >contrary other than these ips are listed in their database and that's >that. I realise this may not strictly be the domain of nanog but I would >think that quality of services such like senderbase, as measured in both >false positives as well as their abillity to act on them, would be, >since many here use and depend on these services. I don't understand how >or why senderbase would list unrouted address space and further give me >grief over the reporting of it "Unless the daily volume magnitude shows >something > 1, I would not be too worried", but accuracy counts and you >won't have my business unless you can demonstrate some. > >Mike- > From bill at herrin.us Sat Apr 17 15:45:14 2010 From: bill at herrin.us (William Herrin) Date: Sat, 17 Apr 2010 16:45:14 -0400 Subject: Senderbase is offbase, need some help In-Reply-To: <4BC8E3DD.6050806@tiedyenetworks.com> References: <4BC8E3DD.6050806@tiedyenetworks.com> Message-ID: On Fri, Apr 16, 2010 at 6:25 PM, Mike wrote: > ? I've tried to get the attention of senderbase, which is claiming activity > from my address space which is in fact either un-routed or within dynamic > subscriber blocks that have outbound smtp filtering in effect. Interesting; I see similar results for my address space. Two addresses, one of which hasn't been attached to a machine for a decade and the other a virtual IP on a web server where the particular IP never emits connections. Magnitude's only "0.48" for both but still, they shouldn't even appear. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jlewis at lewis.org Sat Apr 17 18:07:04 2010 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 17 Apr 2010 19:07:04 -0400 (EDT) Subject: Senderbase is offbase, need some help In-Reply-To: References: <4BC8E3DD.6050806@tiedyenetworks.com> Message-ID: On Sat, 17 Apr 2010, William Herrin wrote: > On Fri, Apr 16, 2010 at 6:25 PM, Mike wrote: >> ? I've tried to get the attention of senderbase, which is claiming activity >> from my address space which is in fact either un-routed or within dynamic >> subscriber blocks that have outbound smtp filtering in effect. > > Interesting; I see similar results for my address space. Two > addresses, one of which hasn't been attached to a machine for a decade > and the other a virtual IP on a web server where the particular IP > never emits connections. Magnitude's only "0.48" for both but still, > they shouldn't even appear. I suspect a bug in their system. I checked a handful of unrouted blocks from our address space and eventually hit a /24 from which senderbase lists an IP with magnitude 0.48, but the space hasn't been routed for 13 months. They say they saw something from it on 2010-04-06...which I'd say is highly unlikely. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From brunner at nic-naa.net Sat Apr 17 18:16:20 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sat, 17 Apr 2010 19:16:20 -0400 Subject: .cn / china registrars in US/canada ? In-Reply-To: <20100417172251.GA99018@reptiles.org> References: <20100417172251.GA99018@reptiles.org> Message-ID: <4BCA4144.8090004@nic-naa.net> Jim, As Lou and Fergie have pointed out, there was a significant policy change at CNNIC in late December. I'm going to guess from "get me a .cn domain, without registering it on my behalf then extorting me" that (a) you'd like to register a .cn domain _and_ (b) you are not a resident of China (more likely Canada), and (c) you'd like a non-flake registrar. You could contact CORE, we are an accredited overseas registrar, and we've several members in the US and Canada. Oblig disclaimer: I'm the CTO of CORE, and operate a CORE member located in Maine. Eric From bbot at bbot.org Sat Apr 17 18:23:14 2010 From: bbot at bbot.org (bbot) Date: Sat, 17 Apr 2010 16:23:14 -0700 Subject: Qwest routing problem? Message-ID: Anyone seeing high latency/packet loss on Seattle - East coast routes? --- dansdata.com ping statistics --- 31 packets transmitted, 17 received, 45% packet loss, time 38699ms rtt min/avg/max/mdev = 52.529/87.246/324.823/67.644 ms --- bbot.org ping statistics --- 26 packets transmitted, 20 received, +3 duplicates, 23% packet loss, time 69782ms rtt min/avg/max/mdev = 184.529/747.047/3904.728/847.058 ms, pipe 4 --- TelArin.TelLaerad.net ping statistics --- 54 packets transmitted, 44 received, +6 duplicates, 18% packet loss, time 70755ms rtt min/avg/max/mdev = 97.490/101.655/122.734/5.594 ms Traceroute seems to be suggesting that the problem router is in Denver. From mysidia at gmail.com Sat Apr 17 18:26:52 2010 From: mysidia at gmail.com (James Hess) Date: Sat, 17 Apr 2010 18:26:52 -0500 Subject: OT: old farts recollecting -- Re: ASR1002 In-Reply-To: <28119.1263999124@localhost> References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <201001191550193802132@gmail.com> <1263909572.18086.40.camel@ub-g-d2> <20100119160001.GA30743@reptiles.org> <1263923324.10985.4.camel@ub-g-d2> <18a5e7cb1001191742sa77d955u188f3d282faaf2c8@mail.gmail.com> <1263976252.1183.20.camel@ub-g-d2> <20100120083534.GA63987@reptiles.org> <202705b1001200601r5bbedc2fl6578926cde45ae0c@mail.gmail.com> <28119.1263999124@localhost> Message-ID: On Wed, Jan 20, 2010 at 9:52 AM, wrote: > On Wed, 20 Jan 2010 08:01:50 CST, Jorge Amodio said: >> Ohh yeah, now we can send sort of a telegram with multiple fonts and >> colors almost from anywhere... > At least it doesn't do BLINK ;) Oh SMS/MMS do a few things that make blink tags look utterly benign... http://www.dreamfabric.com/sms/alert.html May be possible to send as a flash message that immediately displays blinking, and that depending on phone, the recipient doesn't get any option to control or save, e.g. forced to read before doing anything else, no history or storage of message text once read. But mail readers with javascript and animated GIFs still have them beat overall. E-Mail readers / text message readers epidemically trust the sender too much sometimes, thinking the recipient would rather be annoyed by more rich content (or pwned) than disappointed that rich content shows as plain text. -- -J From jimtempl at att.net Sun Apr 18 01:35:11 2010 From: jimtempl at att.net (Jim Templin) Date: Sat, 17 Apr 2010 23:35:11 -0700 Subject: OT: old farts recollecting -- Re: ASR1002 In-Reply-To: References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <201001191550193802132@gmail.com> <1263909572.18086.40.camel@ub-g-d2> <20100119160001.GA30743@reptiles.org> <1263923324.10985.4.camel@ub-g-d2> <18a5e7cb1001191742sa77d955u188f3d282faaf2c8@mail.gmail.com> <1263976252.1183.20.camel@ub-g-d2> <20100120083534.GA63987@reptiles.org> <202705b1001200601r5bbedc2fl6578926cde45ae0c@mail.gmail.com> <28119.1263999124@localhost> Message-ID: <000001cadec1$4c20e8c0$e462ba40$@net> > James Hess [mailto:mysidia at gmail.com] > Saturday, April 17, 2010 4:27 PM > > Oh SMS/MMS do a few things that make blink tags look utterly > benign... > http://www.dreamfabric.com/sms/alert.html > > May be possible to send as a flash message that immediately displays > blinking, and that depending on phone, the recipient doesn't get any > option to control or save, e.g. forced to read before doing anything > else, no history or storage of message text once read. > > But mail readers with javascript and animated GIFs still have them beat > overall. > > E-Mail readers / text message readers epidemically trust the sender > too much sometimes, thinking the recipient would rather be annoyed by > more rich content (or pwned) than disappointed that rich content shows > as plain text. > > -- > -J Useful adjunct to your junc. http://www.gsmfavorites.com/documents/sms/packetformat -- Jim From tkapela at gmail.com Sun Apr 18 06:59:00 2010 From: tkapela at gmail.com (Anton Kapela) Date: Sun, 18 Apr 2010 07:59:00 -0400 Subject: DSL "aggregation".... NO In-Reply-To: References: <26CF6BC367161D4BAFC39B6ED6F885F3021901CC@TNEXPRD.hottopic.com> Message-ID: On Apr 15, 2010, at 5:39 PM, Jack Carrozzo wrote: > You can balance over DSL by putting different L2TPv3 tunnels over each > physical device and agg it at someplace with real connections and > such. It's possible to do it with GRE or OpenVPN too, but much less > classy. As Jack points out, "aggregating" xDSL links via l2tpv3 is possible. I'd like to suggest you consider this for a few other reasons, and mention that you needn't use v3 -- in fact, l2tp as implemented by Cisco IOS VPDN guts will transport layer-2 PPP in IP (or UDP+IP) without fuss. Here's a few reasons why you should consider l2 tunnel abstractions over your existing IP access: a) l2tp + vpdn permits the use of MLPPP over IP -- which means, you get *packet sequencing* and packet ordering, for free, because this is what ML does when added to PPP. b) with ML, you also get packet fragmentation support (i.e. split a single user 1500 byte packet into halves, each transported over l2tp tunnel sessions to the upstream/off-network box) -- this removes the need for l2tp endpoints to process fragments, at least when you have both DSLs (and 2 link members) up. c) even if you were not using fragmentation + mlppp, the "inside" IP packet's DF field is not copied into the PPP header (it can't be), and so outer lt2p packet does not get its DF set either. Fragmentation would be confounded by an inner IP packet of a full MTU size + DF set, and thus, it is not supported. Failing this, you can slum it with ECMP 0/0 route over both DSL links + NAT, or OER-type junk. This example doesn't suck and is easily adapted to "dialer" or other interfaces: http://www.blindhog.net/cisco-dual-internet-connections-without-bgp/ Same thing, restated in a more cisco-y way: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_configuration_example09186a00808d2b72.shtml Finally, a great full-on OER (i.e. connection aware multi-egress point polling + FIB adjustment) example, which maybe more in line with what you want or expect your "dual dsl edge router" to provide: http://www.netcraftsmen.net/resources/archived-articles/468.html -Tk From gordslater at ieee.org Sun Apr 18 12:15:18 2010 From: gordslater at ieee.org (gordon b slater) Date: Sun, 18 Apr 2010 18:15:18 +0100 Subject: Senderbase is offbase, need some help In-Reply-To: References: <4BC8E3DD.6050806@tiedyenetworks.com> Message-ID: <1271610918.29944.8.camel@ub-g-d2> On Sat, 2010-04-17 at 16:45 -0400, William Herrin wrote: > Interesting; I see similar results for my address space. Two > addresses, one of which hasn't been attached to a machine for a decade > and the other a virtual IP on a web server where the particular IP > never emits connections. Magnitude's only "0.48" for both but still, > they shouldn't even appear. Yep, same here, at two seperate sites. It's in the "reserved for extreme emergencies" zone at the top of each assigned block. As per house practice it is tcpdumped 24/7, and has been for the last 4 years. Zero traffic from it at the perimiter. Go figure. Gord -- Order of Magnitude delayed due to lack of stock, please call Despatch From mpetach at netflight.com Sun Apr 18 16:02:27 2010 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 18 Apr 2010 14:02:27 -0700 Subject: Senderbase is offbase, need some help In-Reply-To: <1271610918.29944.8.camel@ub-g-d2> References: <4BC8E3DD.6050806@tiedyenetworks.com> <1271610918.29944.8.camel@ub-g-d2> Message-ID: On Sun, Apr 18, 2010 at 10:15 AM, gordon b slater wrote: > On Sat, 2010-04-17 at 16:45 -0400, William Herrin wrote: > >> Interesting; I see similar results for my address space. Two >> addresses, one of which hasn't been attached to a machine for a decade >> and the other a virtual IP on a web server where the particular IP >> never emits connections. Magnitude's only "0.48" for both but still, >> they shouldn't even appear. > > Yep, same here, at two seperate sites. It's in the "reserved for extreme > emergencies" zone at the top of each assigned block. As per house > practice it is tcpdumped 24/7, and has been for the last 4 years. Zero > traffic from it at the perimiter. > > Go figure. > > Gord Have you checked cyclops and other BGP announcement tracking systems to see if it might have been a short-lived whack-a-mole short prefix hijack (pop up, announce block, send burst of spam, remove announcement, disappear again)? Matt From franck at genius.com Sun Apr 18 19:08:23 2010 From: franck at genius.com (Franck Martin) Date: Mon, 19 Apr 2010 12:08:23 +1200 (MAGST) Subject: Rate of growth on IPv6 not fast enough? Message-ID: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> I'm looking at http://www.cidr-report.org/cgi-bin/plota?file=%2Fvar%2Fdata%2Fbgp%2Fv6%2Fas2.0%2Fbgp-as-count.txt&descr=Unique+ASes&ylabel=Unique+ASes&range=Full&StartDate=&EndDate=&yrange=Auto&ymin=&ymax=&Width=1&Height=1&with=Step&color=auto&logscale=log I see the rate of grow is logarithmically linear since 2007 (well a bit better than that). And doing guess-o-matic extrapolation, it will take another 3 years before we reach 10,000 ASN advertising IPv6 networks. That will be 33% of ASN. With the impending running out of IPv4 starting next year, seems to me we are not going to make it in an orderly fashion? Anybody has better projections? What's the plan? From randy at psg.com Sun Apr 18 19:17:19 2010 From: randy at psg.com (Randy Bush) Date: Mon, 19 Apr 2010 09:17:19 +0900 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> References: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: > And doing guess-o-matic extrapolation, it will take another 3 years > before we reach 10,000 ASN advertising IPv6 networks. That will be 33% > of ASN. With the impending running out of IPv4 starting next year, > seems to me we are not going to make it in an orderly fashion? hint: those asns have ipv4 From LarrySheldon at cox.net Sun Apr 18 19:42:49 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 18 Apr 2010 19:42:49 -0500 Subject: Senderbase is offbase, need some help In-Reply-To: References: <4BC8E3DD.6050806@tiedyenetworks.com> <1271610918.29944.8.camel@ub-g-d2> Message-ID: <4BCBA709.2090205@cox.net> On 4/18/2010 16:02, Matthew Petach wrote: > On Sun, Apr 18, 2010 at 10:15 AM, gordon b slater wrote: >> On Sat, 2010-04-17 at 16:45 -0400, William Herrin wrote: >> >>> Interesting; I see similar results for my address space. Two >>> addresses, one of which hasn't been attached to a machine for a decade >>> and the other a virtual IP on a web server where the particular IP >>> never emits connections. Magnitude's only "0.48" for both but still, >>> they shouldn't even appear. >> >> Yep, same here, at two seperate sites. It's in the "reserved for extreme >> emergencies" zone at the top of each assigned block. As per house >> practice it is tcpdumped 24/7, and has been for the last 4 years. Zero >> traffic from it at the perimiter. >> >> Go figure. >> >> Gord > > Have you checked cyclops and other BGP announcement tracking systems > to see if it might have been a short-lived whack-a-mole short prefix hijack > (pop up, announce block, send burst of spam, remove announcement, disappear > again)? Maybe I'm just tired and cranky or too old to understand.....if the addresses in question never send traffic, who cares? And if senderbase is so bad, why use it? -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From franck at genius.com Sun Apr 18 19:45:21 2010 From: franck at genius.com (Franck Martin) Date: Mon, 19 Apr 2010 12:45:21 +1200 (MAGST) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: Message-ID: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> Sure the internet will not die... But by the time we run out of IPv4 to allocate, the IPv6 network will not have completed to dual stack the current IPv4 network. So what will happen? ----- Original Message ----- From: "Randy Bush" To: "Franck Martin" Cc: nanog at nanog.org Sent: Monday, 19 April, 2010 12:17:19 PM Subject: Re: Rate of growth on IPv6 not fast enough? > And doing guess-o-matic extrapolation, it will take another 3 years > before we reach 10,000 ASN advertising IPv6 networks. That will be 33% > of ASN. With the impending running out of IPv4 starting next year, > seems to me we are not going to make it in an orderly fashion? hint: those asns have ipv4 From brett at the-watsons.org Sun Apr 18 19:53:16 2010 From: brett at the-watsons.org (Brett Watson) Date: Sun, 18 Apr 2010 17:53:16 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Apr 18, 2010, at 5:17 PM, Randy Bush wrote: >> And doing guess-o-matic extrapolation, it will take another 3 years >> before we reach 10,000 ASN advertising IPv6 networks. That will be 33% >> of ASN. With the impending running out of IPv4 starting next year, >> seems to me we are not going to make it in an orderly fashion? > > hint: those asns have ipv4 > And... contrary to Chicken Little, the sky is not falling. From bill at herrin.us Sun Apr 18 20:11:38 2010 From: bill at herrin.us (William Herrin) Date: Sun, 18 Apr 2010 21:11:38 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Sun, Apr 18, 2010 at 8:45 PM, Franck Martin wrote: > Sure the internet will not die... > > But by the time we run out of IPv4 to allocate, the IPv6 network >will not have completed to dual stack the current IPv4 network. >So what will happen? Hi Franck, Zero-sum game. Deploying a new IPv4 address will require removing one from some other function. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jlewis at lewis.org Sun Apr 18 20:19:28 2010 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 18 Apr 2010 21:19:28 -0400 (EDT) Subject: Senderbase is offbase, need some help In-Reply-To: <4BCBA709.2090205@cox.net> References: <4BC8E3DD.6050806@tiedyenetworks.com> <1271610918.29944.8.camel@ub-g-d2> <4BCBA709.2090205@cox.net> Message-ID: On Sun, 18 Apr 2010, Larry Sheldon wrote: >> Have you checked cyclops and other BGP announcement tracking systems >> to see if it might have been a short-lived whack-a-mole short prefix hijack >> (pop up, announce block, send burst of spam, remove announcement, disappear >> again)? > > > Maybe I'm just tired and cranky or too old to understand.....if the > addresses in question never send traffic, who cares? He's suggesting that maybe mail came from those IPs while someone else was using them without your knowledge. Given the available info, I think its far more likely senderbase has some glich causing bogus 0.48 scores for IPs that really haven't sent anything in recent history. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From randy at psg.com Sun Apr 18 20:21:06 2010 From: randy at psg.com (Randy Bush) Date: Mon, 19 Apr 2010 10:21:06 +0900 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: > But by the time we run out of IPv4 to allocate, the IPv6 network will > not have completed to dual stack the current IPv4 network. So what > will happen? as dual-stack requires as many ipv4 addresses as there are ipv6 interfaces, this question is rubbish From randy at psg.com Sun Apr 18 20:22:51 2010 From: randy at psg.com (Randy Bush) Date: Mon, 19 Apr 2010 10:22:51 +0900 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: >> hint: those asns have ipv4 > And... contrary to Chicken Little, the sky is not falling. then what are these diamonds on the soles of my shoes? From patrick at zill.net Sun Apr 18 20:28:01 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Sun, 18 Apr 2010 21:28:01 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4BCBB1A1.1020805@zill.net> Franck Martin wrote: > Sure the internet will not die... > > But by the time we run out of IPv4 to allocate, the IPv6 network will not have completed to dual stack the current IPv4 network. So what will happen? > Reality is that as soon as SSL web servers and SSL-capable web browsers have support for name-based virtual hosts, the number of IPv4 addresses required will drop. Right now, you need 1 IP address for 1 SSL site; SNI spec of SSL gets rid of that. --Patrick From patrick at ianai.net Sun Apr 18 20:36:18 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 18 Apr 2010 21:36:18 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCBB1A1.1020805@zill.net> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> Message-ID: <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> Sent from my iPhone, please excuse any errors. On Apr 18, 2010, at 21:28, Patrick Giagnocavo wrote: > Franck Martin wrote: >> Sure the internet will not die... >> >> But by the time we run out of IPv4 to allocate, the IPv6 network >> will not have completed to dual stack the current IPv4 network. So >> what will happen? >> > > Reality is that as soon as SSL web servers and SSL-capable web > browsers > have support for name-based virtual hosts, the number of IPv4 > addresses > required will drop. Right now, you need 1 IP address for 1 SSL site; > SNI spec of SSL gets rid of that. Agreed. When do you expect Windows XP & earlier versions to be a small enough segment of the userbase that businesses will consider DoS'ing those customers? My guess is when the cost of additional v4 addresses is higher than the profit generated by those customers. Put another way: Not until it is too late. And we still have the "way less than 4 billion possible addresses, but way more than 4 billion hosts" problem. -- TTFN, patrick From bicknell at ufp.org Sun Apr 18 20:52:07 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 18 Apr 2010 18:52:07 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> References: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <20100419015207.GA9789@ussenterprise.ufp.org> In a message written on Mon, Apr 19, 2010 at 12:08:23PM +1200, Franck Martin wrote: > And doing guess-o-matic extrapolation, it will take another 3 years before we reach 10,000 ASN advertising IPv6 networks. That will be 33% of ASN. With the impending running out of IPv4 starting next year, seems to me we are not going to make it in an orderly fashion? Which impending run out? IANA exhaustion occurs before RIR exhaustion; RIR exhaustion occurs before ISP exhaustion. ISP exhaustion occurs before end user exhaustion. [Ok peanut gallery, yes, there are 100 exceptions, work with me here.] So if you're looking at the data of IANA exhaustion and thinking an end user won't be able to turn on a new laptop and get an address, well no, that's wrong. Also note that some RIR's have an extremely slow burn rate, and their regions may have addresses for years to come. There has also been no real effort by ISP's or end users to squeeze internal allocations. ISP's who did "buy a T1 and get a /24" years ago may revisit that business model and in fact find many of those customers are using 3 IP's, an external mail server, a web server, and a NAT box. Right sizing those returns a lot of space to the useful pool. > Anybody has better projections? What's the plan? While I don't think the we're as far ahead as we would like, I caution against taking the last few years of IPv6 numbers and "guestimating". We've had an unusually long period of early adopter time which dominates all current data. Also, plain linear and exponential models don't fit well as adoption curves are in fact S curves. While you can get linear and exponential models that look similar to the first curve on the S, it's no the same thing statistically. The sky is not falling, but a lot of people need to step it up if we're going to have any safety margin. -- 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 dave.nanog at alfordmedia.com Sun Apr 18 20:55:59 2010 From: dave.nanog at alfordmedia.com (Dave Pooser) Date: Sun, 18 Apr 2010 20:55:59 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCBB1A1.1020805@zill.net> Message-ID: On 4/18/10 8:28 PM, "Patrick Giagnocavo" wrote: > Reality is that as soon as SSL web servers and SSL-capable web browsers > have support for name-based virtual hosts, the number of IPv4 addresses > required will drop. And if Internet history teaches us one thing, it's that end users replace outdated browsers at the drop of a hat, right? -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com From bogstad at pobox.com Sun Apr 18 20:58:47 2010 From: bogstad at pobox.com (Bill Bogstad) Date: Sun, 18 Apr 2010 21:58:47 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCBB1A1.1020805@zill.net> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> Message-ID: On Sun, Apr 18, 2010 at 9:28 PM, Patrick Giagnocavo wrote: > Franck Martin wrote: >> Sure the internet will not die... >> >> But by the time we run out of IPv4 to allocate, the IPv6 network will not have completed to dual stack the current IPv4 network. So what will happen? >> > > Reality is that as soon as SSL web servers and SSL-capable web browsers > have support for name-based virtual hosts, the number of IPv4 addresses > required will drop. ?Right now, you need 1 IP address for 1 SSL site; > SNI spec of SSL gets rid of that. And at what percentage of deployment of IPv6 will we see people decide that they no longer need to support IPv4 access to their web site? (Oh, sorry you were talking about SNI. My bad. :-) Personally, I think it is basically the same question and should have similar answers. Some people seemed to think that the number is 100%. From what I can tell about SNI, WIndows XP clients not using Firefox or Opera are never going to get it. I think Windows XP is down to just over 50% which is way more then IPv6 deployment numbers at this point. We may find that the same people who don't have IPv6 will also be running Windows XP and Internet Explorer. So the choice will be to either switch to SNI or switch to IPv6 and lose access to the same customers in either case. From joelja at bogus.com Sun Apr 18 21:52:05 2010 From: joelja at bogus.com (joel jaeggli) Date: Sun, 18 Apr 2010 19:52:05 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCBB1A1.1020805@zill.net> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> Message-ID: <4BCBC555.7020701@bogus.com> On 4/18/2010 6:28 PM, Patrick Giagnocavo wrote: > Franck Martin wrote: >> Sure the internet will not die... >> >> But by the time we run out of IPv4 to allocate, the IPv6 network will not have completed to dual stack the current IPv4 network. So what will happen? >> > > Reality is that as soon as SSL web servers and SSL-capable web browsers > have support for name-based virtual hosts, the number of IPv4 addresses > required will drop. Right now, you need 1 IP address for 1 SSL site; > SNI spec of SSL gets rid of that. my load balancer needs 16 ips for every million simultaneous connections, so does yours. > --Patrick > From adrian at creative.net.au Sun Apr 18 21:59:57 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Mon, 19 Apr 2010 10:59:57 +0800 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCBC555.7020701@bogus.com> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <4BCBC555.7020701@bogus.com> Message-ID: <20100419025957.GE17577@skywalker.creative.net.au> On Sun, Apr 18, 2010, joel jaeggli wrote: > my load balancer needs 16 ips for every million simultaneous > connections, so does yours. Only because it hasn't broken the spec further. :) adrian From patrick at zill.net Sun Apr 18 22:00:18 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Sun, 18 Apr 2010 23:00:18 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCBC555.7020701@bogus.com> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <4BCBC555.7020701@bogus.com> Message-ID: <4BCBC742.1010104@zill.net> joel jaeggli wrote: > On 4/18/2010 6:28 PM, Patrick Giagnocavo wrote: >> Reality is that as soon as SSL web servers and SSL-capable web browsers >> have support for name-based virtual hosts, the number of IPv4 addresses >> required will drop. Right now, you need 1 IP address for 1 SSL site; >> SNI spec of SSL gets rid of that. > > my load balancer needs 16 ips for every million simultaneous > connections, so does yours. That is an accurate statement but sort of a side issue. I would hazard a guess that ~95% of publicly reachable (i.e. non-SSL-VPN) SSL certificate using servers would never see that amount of traffic. I am talking about the 5 or 10 IPv4 IPs you get with a $99/month dedicated server, so that you can setup 5 or 10 different clients with a shopping cart - Amazon and other large e-tailers have the ability to buy/work around any shortage or bottleneck. Cordially --Patrick From swmike at swm.pp.se Sun Apr 18 23:56:43 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 19 Apr 2010 06:56:43 +0200 (CEST) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> References: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Mon, 19 Apr 2010, Franck Martin wrote: > Anybody has better projections? What's the plan? My guess is that end user access will be more and more NAT444:ed (CGN) while at the same time end users will get more and more IPv6 access (of all types), and over a period of time more and more of the p2p traffic (VoIP, file transfers etc) will move to IPv6 because it'll stop working over IPv4. When enough users have IPv6 access the server-based content will be made reachable over v6 as well. The transition will take at least 5 years, I guess in 2015 we'll be perhaps halfway there. -- Mikael Abrahamsson email: swmike at swm.pp.se From joelja at bogus.com Mon Apr 19 00:22:25 2010 From: joelja at bogus.com (joel jaeggli) Date: Sun, 18 Apr 2010 22:22:25 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4BCBE891.4010206@bogus.com> On 4/18/2010 9:56 PM, Mikael Abrahamsson wrote: > On Mon, 19 Apr 2010, Franck Martin wrote: > >> Anybody has better projections? What's the plan? > > My guess is that end user access will be more and more NAT444:ed (CGN) > while at the same time end users will get more and more IPv6 access (of > all types), and over a period of time more and more of the p2p traffic > (VoIP, file transfers etc) will move to IPv6 because it'll stop working > over IPv4. When enough users have IPv6 access the server-based content > will be made reachable over v6 as well. > > The transition will take at least 5 years, I guess in 2015 we'll be > perhaps halfway there. Just because the curve doesn't look steep enough now doesn't mean it won't in two years. Human behavior is hard to model and panic hasn't set in yet. The nutjobs are for example not headed for the hills yet. http://www.time.com/time/magazine/article/0,9171,990020-1,00.html From Chris.Campbell at nebulassolutions.com Mon Apr 19 05:16:56 2010 From: Chris.Campbell at nebulassolutions.com (Chris Campbell) Date: Mon, 19 Apr 2010 11:16:56 +0100 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCBC555.7020701@bogus.com> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <4BCBC555.7020701@bogus.com> Message-ID: On 19 Apr 2010, at 03:52, joel jaeggli wrote: > On 4/18/2010 6:28 PM, Patrick Giagnocavo wrote: >> Franck Martin wrote: >>> Sure the internet will not die... >>> >>> But by the time we run out of IPv4 to allocate, the IPv6 network will not have completed to dual stack the current IPv4 network. So what will happen? >>> >> >> Reality is that as soon as SSL web servers and SSL-capable web browsers >> have support for name-based virtual hosts, the number of IPv4 addresses >> required will drop. Right now, you need 1 IP address for 1 SSL site; >> SNI spec of SSL gets rid of that. > > my load balancer needs 16 ips for every million simultaneous > connections, so does yours. > I'm pretty sure that's not the case for inbound connections... http://vegan.net/pipermail/lb-l/2008-June/000871.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3953 bytes Desc: not available URL: From fw at deneb.enyo.de Mon Apr 19 05:42:04 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 19 Apr 2010 12:42:04 +0200 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: (William Herrin's message of "Sun, 18 Apr 2010 21:11:38 -0400") References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <87ljcjk9kz.fsf@mid.deneb.enyo.de> * William Herrin: > On Sun, Apr 18, 2010 at 8:45 PM, Franck Martin wrote: >> Sure the internet will not die... >> >> But by the time we run out of IPv4 to allocate, the IPv6 network >>will not have completed to dual stack the current IPv4 network. >>So what will happen? > Zero-sum game. Deploying a new IPv4 address will require removing one > from some other function. Not true. Many LIRs have traditionally avoided reclaiming unused address space from (ex-)customers because it was cheaper to use fresh addresses. From fw at deneb.enyo.de Mon Apr 19 05:54:24 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 19 Apr 2010 12:54:24 +0200 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> (Patrick W. Gilmore's message of "Sun, 18 Apr 2010 21:36:18 -0400") References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> Message-ID: <87hbn7k90f.fsf@mid.deneb.enyo.de> * Patrick W. Gilmore: >> Reality is that as soon as SSL web servers and SSL-capable web >> browsers have support for name-based virtual hosts, the number of >> IPv4 addresses required will drop. Right now, you need 1 IP >> address for 1 SSL site; SNI spec of SSL gets rid of that. > > Agreed. > > When do you expect Windows XP & earlier versions to be a small enough > segment of the userbase that businesses will consider DoS'ing those > customers? My guess is when the cost of additional v4 addresses is > higher than the profit generated by those customers. > > Put another way: Not until it is too late. I'm not so sure. Name-based virtual hosting for plain HTTP was introduced when Windows NT 4.0 was still in wide use. It originally came with Internet Explorer 2.0, which did not send the Host: header in HTTP requests. Anyway, I think the TLS thing is a bit of a red herring. It might be a popular justification for IP space at the formal level, but real-world requirements are a bit more nuanced. FTP and SSH/SFTP do not support name-based virtual hosting, so if you're a web hoster and structured things around "one IPv4 address per customer", then there might be another obstacle to collapsing everything on a single IPv4 address. It's also difficult to attribute DoS attackers at sub-HTTP layers to a customer if everything is on a single IPv4 address, making mitigation a bit harder. From swmike at swm.pp.se Mon Apr 19 06:05:54 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 19 Apr 2010 13:05:54 +0200 (CEST) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCBE891.4010206@bogus.com> References: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBE891.4010206@bogus.com> Message-ID: On Sun, 18 Apr 2010, joel jaeggli wrote: > Just because the curve doesn't look steep enough now doesn't mean it won't in > two years. Human behavior is hard to model and panic hasn't set in yet. It's just that I'm in Thailand right now and I am bitter about how lousy the Internet works here, and I have a hard time seeing any development of high quality end user IPv6 connectivity here anytime soon. That's why my "halfway there" is coming from. I hope I'm wrong, and it might help if residential equipment gets IPv6 capability because a lot of the Internet equipment here seems to be of that calibre (probably because of price point). -- Mikael Abrahamsson email: swmike at swm.pp.se From martin.rushworth at sohonet.co.uk Mon Apr 19 06:09:35 2010 From: martin.rushworth at sohonet.co.uk (Martin Rushworth) Date: Mon, 19 Apr 2010 12:09:35 +0100 Subject: Earthlink Email Issues with new ARIN range Message-ID: <0900C6A3-C4FE-470D-B78D-7766C25F2001@sohonet.co.uk> Hi, can someone that handles Earthlink blacklist/zombie settings please contact me off-list? we have a recently allocated ARIN /20 range, and all our clients allocated out of this are having issues emailing earthlink email accounts, our other ARIN ranges are fine. No luck through any other channels. thanks Martin From owen at delong.com Mon Apr 19 06:28:04 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 19 Apr 2010 04:28:04 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <4BCBC555.7020701@bogus.com> Message-ID: <3D2992ED-4551-46F3-A5AD-4C1A2BC54298@delong.com> On Apr 19, 2010, at 3:16 AM, Chris Campbell wrote: > > On 19 Apr 2010, at 03:52, joel jaeggli wrote: > >> On 4/18/2010 6:28 PM, Patrick Giagnocavo wrote: >>> Franck Martin wrote: >>>> Sure the internet will not die... >>>> >>>> But by the time we run out of IPv4 to allocate, the IPv6 network will not have completed to dual stack the current IPv4 network. So what will happen? >>>> >>> >>> Reality is that as soon as SSL web servers and SSL-capable web browsers >>> have support for name-based virtual hosts, the number of IPv4 addresses >>> required will drop. Right now, you need 1 IP address for 1 SSL site; >>> SNI spec of SSL gets rid of that. >> >> my load balancer needs 16 ips for every million simultaneous >> connections, so does yours. >> > > I'm pretty sure that's not the case for inbound connections... > > http://vegan.net/pipermail/lb-l/2008-June/000871.html > Depends on which side of the loadbalancer you're talking about and how it is configured. Owen From robert at ufl.edu Mon Apr 19 06:44:22 2010 From: robert at ufl.edu (Robert D. Scott) Date: Mon, 19 Apr 2010 07:44:22 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <3D2992ED-4551-46F3-A5AD-4C1A2BC54298@delong.com> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <4BCBC555.7020701@bogus.com> <3D2992ED-4551-46F3-A5AD-4C1A2BC54298@delong.com> Message-ID: <029d01cadfb5$a7c10580$f7431080$@edu> -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, April 19, 2010 7:28 AM To: Chris Campbell Cc: nanog at nanog.org Subject: Re: Rate of growth on IPv6 not fast enough? On Apr 19, 2010, at 3:16 AM, Chris Campbell wrote: > > On 19 Apr 2010, at 03:52, joel jaeggli wrote: > >> On 4/18/2010 6:28 PM, Patrick Giagnocavo wrote: >>> Franck Martin wrote: >>>> Sure the internet will not die... >>>> >>>> But by the time we run out of IPv4 to allocate, the IPv6 network will not have completed to dual stack the current IPv4 network. So what will happen? >>>> >>> >>> Reality is that as soon as SSL web servers and SSL-capable web browsers >>> have support for name-based virtual hosts, the number of IPv4 addresses >>> required will drop. Right now, you need 1 IP address for 1 SSL site; >>> SNI spec of SSL gets rid of that. >> >> my load balancer needs 16 ips for every million simultaneous >> connections, so does yours. >> > > I'm pretty sure that's not the case for inbound connections... > > http://vegan.net/pipermail/lb-l/2008-June/000871.html > Depends on which side of the loadbalancer you're talking about and how it is configured. Owen Sounds like he is talking about a source NAT pool. If the box will support a million simultaneous PATS, it takes 16 addresses to make a PAT pool of that size. But if you are routing in the data center they can be private, as only the real servers will see them. If you had a need to do 1 arm across the Internet a single NAT pool would provide service for a large number of VIPS. These are featuress of an ACE. From patrick at ianai.net Mon Apr 19 08:00:10 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 19 Apr 2010 09:00:10 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <87hbn7k90f.fsf@mid.deneb.enyo.de> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> Message-ID: <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> On Apr 19, 2010, at 6:54 AM, Florian Weimer wrote: > * Patrick W. Gilmore: > >>> Reality is that as soon as SSL web servers and SSL-capable web >>> browsers have support for name-based virtual hosts, the number of >>> IPv4 addresses required will drop. Right now, you need 1 IP >>> address for 1 SSL site; SNI spec of SSL gets rid of that. >> >> Agreed. >> >> When do you expect Windows XP & earlier versions to be a small enough >> segment of the userbase that businesses will consider DoS'ing those >> customers? My guess is when the cost of additional v4 addresses is >> higher than the profit generated by those customers. >> >> Put another way: Not until it is too late. > > I'm not so sure. Name-based virtual hosting for plain HTTP was > introduced when Windows NT 4.0 was still in wide use. It originally > came with Internet Explorer 2.0, which did not send the Host: header > in HTTP requests. NT4 was never heavily adopted by users. Also, not nearly as many billions were being sold on e-commerce sites. > Anyway, I think the TLS thing is a bit of a red herring. It might be > a popular justification for IP space at the formal level, but > real-world requirements are a bit more nuanced. FTP and SSH/SFTP do > not support name-based virtual hosting, so if you're a web hoster and > structured things around "one IPv4 address per customer", then there > might be another obstacle to collapsing everything on a single IPv4 > address. It's also difficult to attribute DoS attackers at sub-HTTP > layers to a customer if everything is on a single IPv4 address, making > mitigation a bit harder. Since the vast majority of non-SSL HTTP is served off shared IP addresses, I would have to disagree. Also, it is trivial to dump FTP/SSH sessions into the correct directory on a shared backend system. So SSL does seem to me to be the big problem with the hosting side of the house. But end of day, we do agree. I do not see the growth in certs being the limiting factor here. There are far more users than websites, so even if we could wave a magic wand and get back all HTTP/SSL IP addresses, we would still have a large problem. -- TTFN, patrick From fw at deneb.enyo.de Mon Apr 19 08:50:41 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 19 Apr 2010 15:50:41 +0200 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> (Patrick W. Gilmore's message of "Mon, 19 Apr 2010 09:00:10 -0400") References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> Message-ID: <87zl0z8sb2.fsf@mid.deneb.enyo.de> * Patrick W. Gilmore: >> I'm not so sure. Name-based virtual hosting for plain HTTP was >> introduced when Windows NT 4.0 was still in wide use. It originally >> came with Internet Explorer 2.0, which did not send the Host: header >> in HTTP requests. > > NT4 was never heavily adopted by users. It was fairly popular on corporate desktops, until 2005 or so. You really don't want to know details. > Also, not nearly as many billions were being sold on e-commerce > sites. We're talking pretty much recent history here, closer to 2005 than to 2000. Here are some statistics from a popular IT web site in Germany, from mid-2006: They report a 2.5% market share. Of course, these clients weren't running Internet Explorer 2.0 anymore, and this offers a clue what will happen if SNI is a desirable feature in browsers. 8-) From owen at delong.com Mon Apr 19 08:59:58 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 19 Apr 2010 06:59:58 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <87zl0z8sb2.fsf@mid.deneb.enyo.de> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> Message-ID: <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> On Apr 19, 2010, at 6:50 AM, Florian Weimer wrote: > * Patrick W. Gilmore: > >>> I'm not so sure. Name-based virtual hosting for plain HTTP was >>> introduced when Windows NT 4.0 was still in wide use. It originally >>> came with Internet Explorer 2.0, which did not send the Host: header >>> in HTTP requests. >> >> NT4 was never heavily adopted by users. > > It was fairly popular on corporate desktops, until 2005 or so. You > really don't want to know details. > >> Also, not nearly as many billions were being sold on e-commerce >> sites. > > We're talking pretty much recent history here, closer to 2005 than to > 2000. Here are some statistics from a popular IT web site in Germany, > from mid-2006: > > > > They report a 2.5% market share. Of course, these clients weren't > running Internet Explorer 2.0 anymore, and this offers a clue what > will happen if SNI is a desirable feature in browsers. 8-) I had an interesting discussion with someone from Registration Services at ARIN today. The big requests for IP space (the 11 organizations that hold 75% of all ARIN issued space) do not come from the server side... They come from the eye-ball ISPs. The only /8 issued by ARIN to an ISP, for example, was issued to a cable ISP. With this in mind, I don't think there's much to be gained here. Optimizing the utilization of less than 25% of the address space in the face of the consumption rate on the 75% side simply cannot yield a meaningful result. It really is akin to rearranging the deck chairs on the Titanic. Owen From patrick at zill.net Mon Apr 19 09:14:43 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Mon, 19 Apr 2010 10:14:43 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> Message-ID: <4BCC6553.4060202@zill.net> Owen DeLong wrote: > > I had an interesting discussion with someone from Registration Services at ARIN today. > > The big requests for IP space (the 11 organizations that hold 75% of all ARIN issued > space) do not come from the server side... They come from the eye-ball ISPs. The only > /8 issued by ARIN to an ISP, for example, was issued to a cable ISP. > > With this in mind, I don't think there's much to be gained here. Optimizing the utilization > of less than 25% of the address space in the face of the consumption rate on the 75% > side simply cannot yield a meaningful result. It really is akin to rearranging the deck > chairs on the Titanic. The eyeball ISPs will find it trivial to NAT should they ever need to do so however, something servers cannot do - you are looking at numbers, not operational considerations. --Patrick From patrick at ianai.net Mon Apr 19 09:22:53 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 19 Apr 2010 10:22:53 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCC6553.4060202@zill.net> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> Message-ID: On Apr 19, 2010, at 10:14 AM, Patrick Giagnocavo wrote: > Owen DeLong wrote: >> >> I had an interesting discussion with someone from Registration Services at ARIN today. >> >> The big requests for IP space (the 11 organizations that hold 75% of all ARIN issued >> space) do not come from the server side... They come from the eye-ball ISPs. The only >> /8 issued by ARIN to an ISP, for example, was issued to a cable ISP. >> >> With this in mind, I don't think there's much to be gained here. Optimizing the utilization >> of less than 25% of the address space in the face of the consumption rate on the 75% >> side simply cannot yield a meaningful result. It really is akin to rearranging the deck >> chairs on the Titanic. > > The eyeball ISPs will find it trivial to NAT should they ever need to do > so however, something servers cannot do - you are looking at numbers, > not operational considerations. You and I have vastly different definitions of "trivial". -- TTFN, patrick From owen at delong.com Mon Apr 19 09:22:58 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 19 Apr 2010 07:22:58 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCC6553.4060202@zill.net> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> Message-ID: On Apr 19, 2010, at 7:14 AM, Patrick Giagnocavo wrote: > Owen DeLong wrote: >> >> I had an interesting discussion with someone from Registration Services at ARIN today. >> >> The big requests for IP space (the 11 organizations that hold 75% of all ARIN issued >> space) do not come from the server side... They come from the eye-ball ISPs. The only >> /8 issued by ARIN to an ISP, for example, was issued to a cable ISP. >> >> With this in mind, I don't think there's much to be gained here. Optimizing the utilization >> of less than 25% of the address space in the face of the consumption rate on the 75% >> side simply cannot yield a meaningful result. It really is akin to rearranging the deck >> chairs on the Titanic. > > The eyeball ISPs will find it trivial to NAT should they ever need to do > so however, something servers cannot do - you are looking at numbers, > not operational considerations. > > --Patrick I'm looking at both, and, frankly, LSN (large scale NAT) is not as trivial as you think. I actually talk to and work with some of these very large providers on a regular basis. None of them is looking forward to deploying LSN with anything but dread. The support issues, user experience, CALEA problems, and other issues with LSN are huge. None of them that I am aware of are considering using lSN to free up addresses to hand over to hosting providers. Owen From dave.nanog at alfordmedia.com Mon Apr 19 09:24:43 2010 From: dave.nanog at alfordmedia.com (Dave Pooser) Date: Mon, 19 Apr 2010 09:24:43 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCC6553.4060202@zill.net> Message-ID: On 4/19/10 9:14 AM, "Patrick Giagnocavo" wrote: > The eyeball ISPs will find it trivial to NAT should they ever need to do > so however, something servers cannot do - you are looking at numbers, > not operational considerations. Personally, I'm just waiting to see which eyeball ISP is the first to react to looming IPv4 exhaustion by (NAT | IPv6 && 6to4)ing their client ranges and using the freed up /9 to offer colo/hosting services at very competitive (compared to desperately scrambling to find a /29 at your IPv4-exhausted ISP) pricing. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com From bicknell at ufp.org Mon Apr 19 09:31:18 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 19 Apr 2010 07:31:18 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCBE891.4010206@bogus.com> References: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBE891.4010206@bogus.com> Message-ID: <20100419143118.GA77881@ussenterprise.ufp.org> In a message written on Sun, Apr 18, 2010 at 10:22:25PM -0700, joel jaeggli wrote: > Just because the curve doesn't look steep enough now doesn't mean it > won't in two years. Human behavior is hard to model and panic hasn't set > in yet. There is also an aspect of this transition I don't think we've seen before (in networking). A large percentage of end users are on technologies (cable modem, dsl, even dial up) who's configuration is entirely driven out of a provisioning database. Once the backbone is rolled out, the nameservers, dhcp, and configuration servers dual-stacked many ISP's could enable IPv6 for all of their customers overnight with only a few keystrokes. Now they won't literally do it that way to save their support folks, but if the need arises they will be able to push the button quite quickly. I suspect the middle part of this S curve is going to be much, much steeper than anyone is predicting right now. -- 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 nick at foobar.org Mon Apr 19 09:39:16 2010 From: nick at foobar.org (Nick Hilliard) Date: Mon, 19 Apr 2010 16:39:16 +0200 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCC6553.4060202@zill.net> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> Message-ID: <4BCC6B14.3000108@foobar.org> On 19/04/2010 16:14, Patrick Giagnocavo wrote: > The eyeball ISPs will find it trivial to NAT should they ever need to do > so [...] Patrick, Having made this bold claim, have you ever actually tried to run a natted eyeball network? The last two natted eyeball networks I worked with could never figure out which aspect of NAT hurt more: the technical side or the business side. Nick From patrick at zill.net Mon Apr 19 09:51:48 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Mon, 19 Apr 2010 10:51:48 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCC6B14.3000108@foobar.org> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC6B14.3000108@foobar.org> Message-ID: <4BCC6E04.5060405@zill.net> Nick Hilliard wrote: > On 19/04/2010 16:14, Patrick Giagnocavo wrote: >> The eyeball ISPs will find it trivial to NAT should they ever need to do >> so [...] > > Patrick, > > Having made this bold claim, have you ever actually tried to run a natted > eyeball network? The last two natted eyeball networks I worked with could > never figure out which aspect of NAT hurt more: the technical side or the > business side. > > Nick > I apologize for a lack of clarity, in that what I meant was: "NAT for eyeball ISPs is technically possible and feasible if needed (since IP addresses are centrally managed by one company); NAT for servers (in the sense of dedicated/colocated systems run by different people/companies) is almost technically impossible and not feasible due to customer training needed and the coordination that would be required." I meant "trivial" FSVO "possible" - sorry. --Patrick From fw at deneb.enyo.de Mon Apr 19 09:51:52 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 19 Apr 2010 16:51:52 +0200 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCC6B14.3000108@foobar.org> (Nick Hilliard's message of "Mon, 19 Apr 2010 16:39:16 +0200") References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC6B14.3000108@foobar.org> Message-ID: <871veb4hrr.fsf@mid.deneb.enyo.de> * Nick Hilliard: > On 19/04/2010 16:14, Patrick Giagnocavo wrote: >> The eyeball ISPs will find it trivial to NAT should they ever need to do >> so [...] > Having made this bold claim, have you ever actually tried to run a natted > eyeball network? The last two natted eyeball networks I worked with could > never figure out which aspect of NAT hurt more: the technical side or the > business side. I'm pretty sure the acceptance of NAT varies regionally. I think there's a large ISP in Italy which has been doing NAT since the 90s. So it's not just the mobile domain. It can be tricky to introduce a new NATted product and compete with established players which do not NAT, though. From jabley at hopcount.ca Mon Apr 19 10:00:27 2010 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 19 Apr 2010 11:00:27 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <871veb4hrr.fsf@mid.deneb.enyo.de> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC6B14.3000108@foobar.org> <871veb4hrr.fsf@mid.deneb.enyo.de> Message-ID: On 2010-04-19, at 10:51, Florian Weimer wrote: > * Nick Hilliard: > >> On 19/04/2010 16:14, Patrick Giagnocavo wrote: >>> The eyeball ISPs will find it trivial to NAT should they ever need to do >>> so [...] > >> Having made this bold claim, have you ever actually tried to run a natted >> eyeball network? The last two natted eyeball networks I worked with could >> never figure out which aspect of NAT hurt more: the technical side or the >> business side. > > I'm pretty sure the acceptance of NAT varies regionally. I think > there's a large ISP in Italy which has been doing NAT since the 90s. > So it's not just the mobile domain. I haven't been a customer of an ISP in New Zealand for a long time now, but people there tell me that there is an expectation of NAT when you sign up for DSL service. Nobody normally expects to be handed a globally-unique v4 address. Joe From jgreco at ns.sol.net Mon Apr 19 10:01:25 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 19 Apr 2010 10:01:25 -0500 (CDT) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <871veb4hrr.fsf@mid.deneb.enyo.de> from "Florian Weimer" at Apr 19, 2010 04:51:52 PM Message-ID: <201004191501.o3JF1P3x084685@aurora.sol.net> > * Nick Hilliard: > > > On 19/04/2010 16:14, Patrick Giagnocavo wrote: > >> The eyeball ISPs will find it trivial to NAT should they ever need to do > >> so [...] > > > Having made this bold claim, have you ever actually tried to run a natted > > eyeball network? The last two natted eyeball networks I worked with could > > never figure out which aspect of NAT hurt more: the technical side or the > > business side. > > I'm pretty sure the acceptance of NAT varies regionally. I think > there's a large ISP in Italy which has been doing NAT since the 90s. > So it's not just the mobile domain. > > It can be tricky to introduce a new NATted product and compete with > established players which do not NAT, though. It's another opportunity to monetize things. Give people the option of a "real" IP address for $5 extra a month in case they actually need it for gaming, etc., and default Grandma's average everyday connection to NAT. The eyeball ISP's definitely have the easier end of things. ... 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 robert at timetraveller.org Mon Apr 19 10:08:06 2010 From: robert at timetraveller.org (Robert Brockway) Date: Mon, 19 Apr 2010 11:08:06 -0400 (EDT) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> Message-ID: On Mon, 19 Apr 2010, Owen DeLong wrote: > I'm looking at both, and, frankly, LSN (large scale NAT) is not as > trivial as you think. I actually talk to and work with some of these > very large providers on a regular basis. None of them is looking forward > to deploying LSN with anything but dread. The support issues, user > experience, CALEA problems, and other issues with LSN are huge. None of > them that I am aware of are considering using lSN to free up addresses > to hand over to hosting providers. Well said. I've been pondering LSN lately. I think people have haven't been involved in large scale service changes or migrations can't appreciate just how many unanticipated edge cases can appear and blindside a project. I expect that deploying IPv6 will be far less problematic than deploying LSN for a large ISP. Rob -- Email: robert at timetraveller.org IRC: Solver Web: http://www.practicalsysadmin.com Open Source: The revolution that silently changed the world From sthaug at nethelp.no Mon Apr 19 10:19:23 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Mon, 19 Apr 2010 17:19:23 +0200 (CEST) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100419143118.GA77881@ussenterprise.ufp.org> References: <4BCBE891.4010206@bogus.com> <20100419143118.GA77881@ussenterprise.ufp.org> Message-ID: <20100419.171923.74738974.sthaug@nethelp.no> > There is also an aspect of this transition I don't think we've seen > before (in networking). A large percentage of end users are on > technologies (cable modem, dsl, even dial up) who's configuration > is entirely driven out of a provisioning database. > > Once the backbone is rolled out, the nameservers, dhcp, and > configuration servers dual-stacked many ISP's could enable IPv6 for > all of their customers overnight with only a few keystrokes. *If* the whole IPv6 config can be driven from the same database. For the time being, DHCPv6 cannot deliver a default gateway to customers (and there is a religious faction within the IPv6 community which seem to want to prevent this at all costs). As long as we have the dependency on RA for default gateways, what you suggest is considerably more difficult. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From nick at foobar.org Mon Apr 19 10:20:41 2010 From: nick at foobar.org (Nick Hilliard) Date: Mon, 19 Apr 2010 17:20:41 +0200 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <871veb4hrr.fsf@mid.deneb.enyo.de> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC6B14.3000108@foobar.org> <871veb4hrr.fsf@mid.deneb.enyo.de> Message-ID: <4BCC74C9.9090303@foobar.org> On 19/04/2010 16:51, Florian Weimer wrote: > I'm pretty sure the acceptance of NAT varies regionally. I think > there's a large ISP in Italy which has been doing NAT since the 90s. to my knowledge, if we're talking about the same organisation, this large ISP is moving away from NAT, or already has done so. Sure, you can NAT eyeballs, but it hurts like hell. Nick From jgreco at ns.sol.net Mon Apr 19 10:23:46 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 19 Apr 2010 10:23:46 -0500 (CDT) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCC74C9.9090303@foobar.org> from "Nick Hilliard" at Apr 19, 2010 05:20:41 PM Message-ID: <201004191523.o3JFNko9085371@aurora.sol.net> > On 19/04/2010 16:51, Florian Weimer wrote: > > I'm pretty sure the acceptance of NAT varies regionally. I think > > there's a large ISP in Italy which has been doing NAT since the 90s. > > to my knowledge, if we're talking about the same organisation, this large > ISP is moving away from NAT, or already has done so. > > Sure, you can NAT eyeballs, but it hurts like hell. Which hurts more ... NATting eyeballs, or blinding them entirely? Eventually we'll run out. Then we get to pick. ... 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 frnkblk at iname.com Mon Apr 19 11:10:59 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Mon, 19 Apr 2010 11:10:59 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100419143118.GA77881@ussenterprise.ufp.org> References: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBE891.4010206@bogus.com> <20100419143118.GA77881@ussenterprise.ufp.org> Message-ID: Don't forget the home gateway aspect -- it's a huge gaping hole in the IPv6 deployment strategy for ISPs. And don't talk to me about Apple's Airport Extreme. ISPs want (once the volume of IETF IPv6-related drafts has settled down) for every router at Wal-mart to include IPv6 support. If they start right now and presume that home gateways/routers are replaced every 3 to 5 years, it will be several years before they've covered even 50% of the homes. Frank -----Original Message----- From: Leo Bicknell [mailto:bicknell at ufp.org] Sent: Monday, April 19, 2010 9:31 AM To: nanog at nanog.org Subject: Re: Rate of growth on IPv6 not fast enough? In a message written on Sun, Apr 18, 2010 at 10:22:25PM -0700, joel jaeggli wrote: > Just because the curve doesn't look steep enough now doesn't mean it > won't in two years. Human behavior is hard to model and panic hasn't set > in yet. There is also an aspect of this transition I don't think we've seen before (in networking). A large percentage of end users are on technologies (cable modem, dsl, even dial up) who's configuration is entirely driven out of a provisioning database. Once the backbone is rolled out, the nameservers, dhcp, and configuration servers dual-stacked many ISP's could enable IPv6 for all of their customers overnight with only a few keystrokes. Now they won't literally do it that way to save their support folks, but if the need arises they will be able to push the button quite quickly. I suspect the middle part of this S curve is going to be much, much steeper than anyone is predicting right now. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From bogstad at pobox.com Mon Apr 19 11:58:43 2010 From: bogstad at pobox.com (Bill Bogstad) Date: Mon, 19 Apr 2010 12:58:43 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBE891.4010206@bogus.com> <20100419143118.GA77881@ussenterprise.ufp.org> Message-ID: On Mon, Apr 19, 2010 at 12:10 PM, Frank Bulk - iName.com wrote: > Don't forget the home gateway aspect -- it's a huge gaping hole in the IPv6 > deployment strategy for ISPs. ?And don't talk to me about Apple's Airport > Extreme. ?ISPs want (once the volume of IETF IPv6-related drafts has settled > down) for every router at Wal-mart to include IPv6 support. ?If they start > right now and presume that home gateways/routers are replaced every 3 to 5 > years, it will be several years before they've covered even 50% of the > homes. Alternatively, they could commission the vendors to release firmware upgrades with IPv6 support for the most common older devices. Given that many of them are Linux based and the code already exists, this isn't likely to be technically difficult. The customer support costs, however, of convincing people to actually install the new firmware is another story. A consortium of ISPs could collectively work with the biggest OEMs/vendors to get this done if they wanted to do so. Start by commissioning IPv6 support into all new hardware. I would think that given the razor thin margins in home gateways/routers extra money coming in for simply turning on code which already exists would be attractive to at least some of them. Come up with some kind of logo for the program "IPv6 READY!". Make it a bandwagon thing so that vendors who aren't part of the program look behind the times. Offer some kind of cheap to implement network service to customers which can only be accessed via IPv6 to create user demand. Many people have said that the reason that no one is doing IPv6 is that there is nothing in it for the end users, so change that. Bill Bogstad From kloch at kl.net Mon Apr 19 12:12:33 2010 From: kloch at kl.net (Kevin Loch) Date: Mon, 19 Apr 2010 13:12:33 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100419.171923.74738974.sthaug@nethelp.no> References: <4BCBE891.4010206@bogus.com> <20100419143118.GA77881@ussenterprise.ufp.org> <20100419.171923.74738974.sthaug@nethelp.no> Message-ID: <4BCC8F01.7060506@kl.net> sthaug at nethelp.no wrote: > *If* the whole IPv6 config can be driven from the same database. For > the time being, DHCPv6 cannot deliver a default gateway to customers > (and there is a religious faction within the IPv6 community which > seem to want to prevent this at all costs). s/IPv6/IETF/ I don't know of anyone outside of the IETF promoting the insanity of a DHCP server not having the option of giving out a gateway address. - Kevin From mohacsi at niif.hu Mon Apr 19 12:14:12 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 19 Apr 2010 19:14:12 +0200 (CEST) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBE891.4010206@bogus.com> <20100419143118.GA77881@ussenterprise.ufp.org> Message-ID: On Mon, 19 Apr 2010, Bill Bogstad wrote: > On Mon, Apr 19, 2010 at 12:10 PM, Frank Bulk - iName.com > wrote: >> Don't forget the home gateway aspect -- it's a huge gaping hole in the IPv6 >> deployment strategy for ISPs. ?And don't talk to me about Apple's Airport >> Extreme. ?ISPs want (once the volume of IETF IPv6-related drafts has settled >> down) for every router at Wal-mart to include IPv6 support. ?If they start >> right now and presume that home gateways/routers are replaced every 3 to 5 >> years, it will be several years before they've covered even 50% of the >> homes. > > Alternatively, they could commission the vendors to release firmware > upgrades with IPv6 support for the most common older devices. Given > that many of them are Linux based and the code already exists, this > isn't likely to be technically difficult. Yes it is. Most of the home gateways are are manufactured : develop, produce and forget life-cycle. The development codebase, is not existing anymore. The developers are moved to another company.... You barely have support for low-end home gateways after a year of first shipment. In the first year some bugfixing.... Adding new features, like ipv6 is not acceptable/feasible to the manufacturers.... > The customer support costs, however, of convincing people to actually > install the new firmware is another story. A consortium of ISPs could > collectively work with the biggest OEMs/vendors to get this done if they > wanted to do so. > This might be done for new devices, but not for old ones. > Start by commissioning IPv6 support into all new hardware. I would > think that given the razor thin margins in home gateways/routers extra > money coming in for simply turning on code which already exists would > be attractive to at least some of them. Come up with some kind of > logo for the program "IPv6 READY!". Don't count much on "IPv6 READY!" logo. IPv6 READY usually means, there are some IPv6 support in the device, but it might not work on your particular environment....: no IPv6 on PPPoE, no DHCPv6 support, no IPv6 setting are possible on webinterface.... > Make it a bandwagon thing so that vendors who aren't part of the > program look behind the times. Offer some kind of cheap to implement > network service to customers which can only be accessed via IPv6 to > create user demand. Many people have said that the reason that no one > is doing IPv6 is that there is nothing in it for the end users, so > change that. I fully support you..... Best Regards, Janos Mohacsi From chort at smtps.net Mon Apr 19 12:18:19 2010 From: chort at smtps.net (Brian Keefer) Date: Mon, 19 Apr 2010 10:18:19 -0700 Subject: Comcast IPv6 trials Message-ID: Check your inboxes :) -- bk From CTran at qds-i.com Mon Apr 19 12:22:15 2010 From: CTran at qds-i.com (Chi Tran) Date: Mon, 19 Apr 2010 10:22:15 -0700 Subject: unsubscribe Message-ID: One of our co-workers has left the company so we have been forwarding his emails to our main support email and we're getting a lot of nanog's posts. Can you unsubscribe either rmains at nacio.com or rmains at qds-i.com? Thank you. ____________________________ Chi Tran Quadrant Support ctran at qds-i.com [cid:image001.jpg at 01CADFAA.2EB049E0] Quadrant Data Systems, Inc. 100 Wood Hollow Drive Suite 150 Novato, CA 94945 www.qds-i.com CONFIDENTIALITY NOTICE: The information contained in this e-mail, or attached hereto, is intended only for the use of the individual or entity to which it is addressed, and may be privileged, confidential, or may be prohibited from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivery to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or its attachments, is strictly prohibited. If you have received this e-mail in error, please notify the author immediately and delete this communication in a manner that permanently removes it from any computer/digital media in your possession. Thank you. -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 22026 bytes Desc: image001.jpg URL: From Bryan at bryanfields.net Mon Apr 19 12:22:31 2010 From: Bryan at bryanfields.net (Bryan Fields) Date: Mon, 19 Apr 2010 13:22:31 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCC6553.4060202@zill.net> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> Message-ID: <4BCC9157.9040507@bryanfields.net> On 4/19/2010 10:14, Patrick Giagnocavo wrote: > The eyeball ISPs will find it trivial to NAT should they ever need to do > so however, something servers cannot do - you are looking at numbers, > not operational considerations. LSN is not trivial. Here is some unverified calculations I did on the problem of scaling nat. Right now I'm using 42 translation entries in my nat table. Each entry takes up 312 bytes of FIB memory, which is ~12.7 Kib of data in the FIB. Mutiply this by 250k users and we have 3,124,237 KiB of FIB entries, or 3.1 GiB. This is not running any PtP programs or really hitting the network, I'm just browsing the web and typing this email to you. If we look a the total number of translations for 250k users we see 10.5M entries. As TCP/UDP only has 65,536 ports and about 1025 of them are unusable, this leaves 64,511 ports to work with per IP. Divided out we need 163 public IP's min just to nat the number of users on a single PDSN pool, assuming we have a 1/2 loading thats 326 public IP's for one pool. Now things get fun when I turn on my torrent program, average number of translations is at 3500 per person (during a virus outbreak or other network event), we'll need a pool of 27k public IP's and 254 GiB of ram to store the NAT tables. This would be a /17 of IP space just to NAT 250k private users! This is why nat does not scale. NAT breaks other IP protocols which don't use TCP or UDP, and even breaks common protocols like TCP based FTP unless the NAT device has special support for FTP to do deep packet inspection and track the FTP sessions. Now suppose some one finds out that 250k people are behind a LSN box. All they have to do is write a virus that opens up tons of connections and it will DDOS the entire providers nat device. Jjust think, a single user could get the entire user base blocked from 4chan! -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From mohacsi at niif.hu Mon Apr 19 12:26:38 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 19 Apr 2010 19:26:38 +0200 (CEST) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCC8F01.7060506@kl.net> References: <4BCBE891.4010206@bogus.com> <20100419143118.GA77881@ussenterprise.ufp.org> <20100419.171923.74738974.sthaug@nethelp.no> <4BCC8F01.7060506@kl.net> Message-ID: Dear all, I think there is some discussion and work at IETF to define solutions..... http://datatracker.ietf.org/doc/draft-dec-dhcpv6-route-option/ or http://tools.ietf.org/id/draft-droms-dhc-dhcpv6-default-router-00.txt Describe valid engineering reqs to have a drafted at IETF, and you will find supporters... Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Mon, 19 Apr 2010, Kevin Loch wrote: > sthaug at nethelp.no wrote: > >> *If* the whole IPv6 config can be driven from the same database. For >> the time being, DHCPv6 cannot deliver a default gateway to customers >> (and there is a religious faction within the IPv6 community which >> seem to want to prevent this at all costs). > > s/IPv6/IETF/ > > I don't know of anyone outside of the IETF promoting the insanity > of a DHCP server not having the option of giving out a gateway address. > > - Kevin > > From smb at cs.columbia.edu Mon Apr 19 12:26:59 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 19 Apr 2010 13:26:59 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCC9157.9040507@bryanfields.net> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC9157.9040507@bryanfields.net> Message-ID: On Apr 19, 2010, at 1:22 31PM, Bryan Fields wrote: > On 4/19/2010 10:14, Patrick Giagnocavo wrote: >> The eyeball ISPs will find it trivial to NAT should they ever need to do >> so however, something servers cannot do - you are looking at numbers, >> not operational considerations. > > LSN is not trivial. > Also remember the abuse/blacklist/CALEA problem with NAT -- you have to log every connection by port number, and hope that the complaints you get mention source port. --Steve Bellovin, http://www.cs.columbia.edu/~smb From owen at delong.com Mon Apr 19 12:34:30 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 19 Apr 2010 10:34:30 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <201004191523.o3JFNko9085371@aurora.sol.net> References: <201004191523.o3JFNko9085371@aurora.sol.net> Message-ID: <20FCDD09-A4BC-41B5-AFCF-D9203C83DA58@delong.com> On Apr 19, 2010, at 8:23 AM, Joe Greco wrote: >> On 19/04/2010 16:51, Florian Weimer wrote: >>> I'm pretty sure the acceptance of NAT varies regionally. I think >>> there's a large ISP in Italy which has been doing NAT since the 90s. >> >> to my knowledge, if we're talking about the same organisation, this large >> ISP is moving away from NAT, or already has done so. >> >> Sure, you can NAT eyeballs, but it hurts like hell. > > Which hurts more ... NATting eyeballs, or blinding them entirely? > > Eventually we'll run out. Then we get to pick. > IPv6 is not blinding them entirely. Owen From drc at virtualized.org Mon Apr 19 12:40:51 2010 From: drc at virtualized.org (David Conrad) Date: Mon, 19 Apr 2010 10:40:51 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCC9157.9040507@bryanfields.net> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC9157.9040507@bryanfields.net> Message-ID: <7F37FB2F-177E-458E-9F3F-1229495F8C7C@virtualized.org> Bryan, On Apr 19, 2010, at 10:22 AM, Bryan Fields wrote: > Here is some unverified calculations I did on the problem of scaling nat. > > Right now I'm using 42 translation entries in my nat table. Each entry takes > up 312 bytes of FIB memory, which is ~12.7 Kib of data in the FIB. Mutiply > this by 250k users and we have 3,124,237 KiB of FIB entries, or 3.1 GiB. This > is not running any PtP programs or really hitting the network, I'm just > browsing the web and typing this email to you. This is really interesting data. What hardware is this on? Thanks, -drc From bogstad at pobox.com Mon Apr 19 12:45:09 2010 From: bogstad at pobox.com (Bill Bogstad) Date: Mon, 19 Apr 2010 13:45:09 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBE891.4010206@bogus.com> <20100419143118.GA77881@ussenterprise.ufp.org> Message-ID: On Mon, Apr 19, 2010 at 1:14 PM, Mohacsi Janos wrote: > > > > On Mon, 19 Apr 2010, Bill Bogstad wrote: > >> On Mon, Apr 19, 2010 at 12:10 PM, Frank Bulk - iName.com >> wrote: >>> >>> Don't forget the home gateway aspect -- it's a huge gaping hole in the >>> IPv6 >>> deployment strategy for ISPs. ?And don't talk to me about Apple's Airport >>> Extreme. ?ISPs want (once the volume of IETF IPv6-related drafts has >>> settled >>> down) for every router at Wal-mart to include IPv6 support. ?If they >>> start >>> right now and presume that home gateways/routers are replaced every 3 to >>> 5 >>> years, it will be several years before they've covered even 50% of the >>> homes. >> >> Alternatively, they could commission the vendors to release firmware >> upgrades with IPv6 support for the most common older devices. ? Given >> that many of them are Linux based and the code already exists, this >> isn't likely to be technically difficult. > > Yes it is. Most of the home gateways are are manufactured : develop, produce > and forget life-cycle. The development codebase, is not existing anymore. > The developers are moved to another company.... You barely have support for > low-end home gateways after a year of first shipment. In the first year some > bugfixing.... That's because they aren't getting paid for maintaining old firmware (razor thin margins). At least in the case of Linux based units, GPL enforcement has for the most part required them to keep better track of their codebase. As a result, I think this is more feasible then you do. Still it WOULD be easier to just work on getting all new equipment IPv6 capable. Both cable and cellphone companies already commission custom firmware for their settop boxes and cell phones, I see no reason that ISPs couldn't do the same. > >> Start by commissioning IPv6 support into all new hardware. ? I would >> think that given the razor thin margins in home gateways/routers extra >> money coming in for simply turning on code which already exists would >> be attractive to at least some of them. ?Come up with some kind of >> logo for the program "IPv6 READY!". > > Don't count much on "IPv6 READY!" logo. IPv6 READY usually means, there are > some IPv6 support in the device, but it might not work on your particular > environment....: no IPv6 on PPPoE, no DHCPv6 support, no IPv6 setting are > possible on webinterface.... That's why you make it a trademarked logo and you have licensing requirements that specify what must be included in order for them to use the logo on their marketing materials. The consortium decides what is needed to make IPv6 work for them and enforces it via logo licensing. Frankly if the protocols out of the IETF for things like DHCP/default routes don't make sense, the consortium can simply specify something else. I'm pretty sure that if the spec comes with a sufficiently large check attached the OEMs will implement whatever you want in the firmware. Bill Bogstad From Bryan at bryanfields.net Mon Apr 19 12:51:48 2010 From: Bryan at bryanfields.net (Bryan Fields) Date: Mon, 19 Apr 2010 13:51:48 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <7F37FB2F-177E-458E-9F3F-1229495F8C7C@virtualized.org> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC9157.9040507@bryanfields.net> <7F37FB2F-177E-458E-9F3F-1229495F8C7C@virtualized.org> Message-ID: <4BCC9834.2030501@bryanfields.net> On 4/19/2010 13:40, David Conrad wrote: > Bryan, > > On Apr 19, 2010, at 10:22 AM, Bryan Fields wrote: >> Here is some unverified calculations I did on the problem of scaling nat. >> >> Right now I'm using 42 translation entries in my nat table. Each entry takes >> up 312 bytes of FIB memory, which is ~12.7 Kib of data in the FIB. Mutiply >> this by 250k users and we have 3,124,237 KiB of FIB entries, or 3.1 GiB. This >> is not running any PtP programs or really hitting the network, I'm just >> browsing the web and typing this email to you. > > This is really interesting data. What hardware is this on? Cisco. I've not had an engineer look at it, but it's based on this FAQ: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_q_and_a_item09186a00800e523b.shtml Q. How many concurrent NAT sessions are supported in Cisco IOS NAT? A. The NAT session limit is bounded by the amount of available DRAM in the router. Each NAT translation consumes about 312 bytes in DRAM. As a result, 10,000 translations (more than would generally be handled on a single router) consume about 3 MB. Therefore, typical routing hardware has more than enough memory to support thousands of NAT translations. Anyone from the vendors want to speak up and maybe poke some holes in my math? I'd actually love to be wrong about the amount of memory for this, but suspect I'm close :( -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From simon.perreault at viagenie.ca Mon Apr 19 13:06:31 2010 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Mon, 19 Apr 2010 14:06:31 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCC9157.9040507@bryanfields.net> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC9157.9040507@bryanfields.net> Message-ID: <4BCC9BA7.3080702@viagenie.ca> On 2010-04-19 13:22, Bryan Fields wrote: > If we look a the total number of translations for 250k users we see 10.5M > entries. As TCP/UDP only has 65,536 ports and about 1025 of them are > unusable, this leaves 64,511 ports to work with per IP. Divided out we need > 163 public IP's min just to nat the number of users on a single PDSN pool, > assuming we have a 1/2 loading thats 326 public IP's for one pool. This is true only if you use endpoint-independent mapping. With address-dependent mapping (e.g. pf) or address- and port-dependent mapping (e.g. Linux) scaling is much better. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From bicknell at ufp.org Mon Apr 19 13:07:19 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 19 Apr 2010 11:07:19 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCC9157.9040507@bryanfields.net> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC9157.9040507@bryanfields.net> Message-ID: <20100419180719.GB97473@ussenterprise.ufp.org> In a message written on Mon, Apr 19, 2010 at 01:22:31PM -0400, Bryan Fields wrote: > Right now I'm using 42 translation entries in my nat table. Each entry takes > up 312 bytes of FIB memory, which is ~12.7 Kib of data in the FIB. Mutiply > this by 250k users and we have 3,124,237 KiB of FIB entries, or 3.1 GiB. This > is not running any PtP programs or really hitting the network, I'm just > browsing the web and typing this email to you. [snip] > Now things get fun when I turn on my torrent program, average > number of translations is at 3500 per person (during a virus outbreak or other > network event), we'll need a pool of 27k public IP's and 254 GiB of ram to > store the NAT tables. This would be a /17 of IP space just to NAT 250k > private users! There are a few problems with your data.... I know of no platform that does hardware NAT. Rather, NAT is a CPU function. While this is another interesting scaling issue, it means this data is not going in the FIB (hardware forwarding database), but rather is stored in a CPU accessible database. It's not that you need 3.1G/254G of memory in the FIB (which would be expensive) but rather that you need it in relatively cheap DRAM. Even if use your larger memory number of 254G that's only $10-15k of RAM cost these days, hardly a deal breaker. The FIB would hold only one entry for the /17 (or similar) pointing it to the CPU. Secondly, you're playing to both extremes. Yes, the point to point user will use 3500 entries and grandma checking e-mail may use 42 entries. Not everyone will run a point to point client, and not everyone will be grandma. Using an average is a much better first start. I suspect though the percentage of users using a point to point client is small though, and thus drives the average number even lower. So, 3500 + 42 / 2 = 1751 entries on average per person. 250,000 users * 1751 entries * 312 bytes/entry = ~136G of data. 250,000 users * 1751 entries / 64000 ports/IP = 6939 IP's. So a /19 provides headroom. 10 servers, each with 16G of RAM (160G total) could do the job with headroom. Not all users will be active at the same time, so 100k per user probably translates into a 1Mbps/sec rate, given the old 10:1 rule on end users. 250,000 users * 100,000 bytes/sec = ~186Gigabits/sec. Humm, 10 servers won't do that (18Gbps/sec per server of NAT, no way!). 40 servers though would be 4.65Gbps per box, which with 10GE seems reasonable. But that also means each one only needs 1/4th the RAM from above. In summary, to NAT 250,000 users: 40 servers, each with: CPU capable of NATing 4.65Gbps 4-8Gb of memory 2x10GE interfaces A /19 of address space. I think a server like that could be had for $10k each, easy. So 400k of servers, depreciated over 3 years, divided by 250,000 users: $0.53 per user per YEAR. Or, $0.04 per month per user. Even selling $20 packages ISP's should be able to absorb four cents per user. NAT scales just fine. I find that quite unfortunate, personally, but I don't think there's a problem with the technology or economics. -- 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 joelja at bogus.com Mon Apr 19 13:14:25 2010 From: joelja at bogus.com (joel jaeggli) Date: Mon, 19 Apr 2010 11:14:25 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <7F37FB2F-177E-458E-9F3F-1229495F8C7C@virtualized.org> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC9157.9040507@bryanfields.net> <7F37FB2F-177E-458E-9F3F-1229495F8C7C@virtualized.org> Message-ID: <4BCC9D81.4090103@bogus.com> On 4/19/2010 10:40 AM, David Conrad wrote: > Bryan, > > On Apr 19, 2010, at 10:22 AM, Bryan Fields wrote: >> Here is some unverified calculations I did on the problem of scaling nat. >> >> Right now I'm using 42 translation entries in my nat table. Each entry takes >> up 312 bytes of FIB memory, which is ~12.7 Kib of data in the FIB. Mutiply >> this by 250k users and we have 3,124,237 KiB of FIB entries, or 3.1 GiB. This >> is not running any PtP programs or really hitting the network, I'm just >> browsing the web and typing this email to you. > > This is really interesting data. What hardware is this on? most firewall vendors can give you this information for their products. it tends to manifest itself in documented connection table size limits. For devices using A PF derivative for example it's right around a kilobyte per entry.... platforms based on 32 bit memory architecture have a hard 4GB limit for that size of those datastructures. > Thanks, > -drc > > From johnl at iecc.com Mon Apr 19 13:40:13 2010 From: johnl at iecc.com (John Levine) Date: 19 Apr 2010 18:40:13 -0000 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <871veb4hrr.fsf@mid.deneb.enyo.de> Message-ID: <20100419184013.55182.qmail@joyce.lan> >> Having made this bold claim, have you ever actually tried to run a natted >> eyeball network? The last two natted eyeball networks I worked with could >> never figure out which aspect of NAT hurt more: the technical side or the >> business side. My small telco-owned ISP NATs all of its DSL users, but you can get your own IP on request. They have about 5000 users and I think they said I was the eighth to ask for a private IP. I have to say that it took several months to realize I was behind a NAT, and that only because "my" IP showed up in the CBL blacklist of botted machines, and after great household excitement trying to deworm all the laptops, I poked around in the router and noticed that the other end of the hop to the DSLAM was numbered in 172.16. space, and it turned out the botted machine was one of my neighbors sharing the IP. Based on that experience I'd say that there is some cost to putting your consumer customers behind a NAT, but probably not as much cost as buying IP space on the rapidly developing open market. R's, John From nanog at myzionetworks.com Mon Apr 19 15:10:59 2010 From: nanog at myzionetworks.com (Todd) Date: Mon, 19 Apr 2010 16:10:59 -0400 Subject: Earthlink Email Issues with new ARIN range In-Reply-To: <0900C6A3-C4FE-470D-B78D-7766C25F2001@sohonet.co.uk> References: <0900C6A3-C4FE-470D-B78D-7766C25F2001@sohonet.co.uk> Message-ID: <020101cadffc$6ebcf3b0$4c36db10$@myzionetworks.com> We've had this exact issue with Earthlink and have no absolutely no luck working with Earthlink to resolve it. If you make any progress, please let me know how you did it. Thanks, Todd -----Original Message----- From: Martin Rushworth [mailto:martin.rushworth at sohonet.co.uk] Sent: Monday, April 19, 2010 7:10 AM To: nanog at nanog.org Subject: Earthlink Email Issues with new ARIN range Hi, can someone that handles Earthlink blacklist/zombie settings please contact me off-list? we have a recently allocated ARIN /20 range, and all our clients allocated out of this are having issues emailing earthlink email accounts, our other ARIN ranges are fine. No luck through any other channels. thanks Martin From mirotrem at gmail.com Mon Apr 19 15:12:07 2010 From: mirotrem at gmail.com (Chadwick Sorrell) Date: Mon, 19 Apr 2010 16:12:07 -0400 Subject: Niksun Probe Message-ID: Hello Nanog, Looking for information on a Niksun probe, http://www.niksun.com/. Anyone have any experience, good or bad with them? Thanks! From sethm at rollernet.us Mon Apr 19 15:13:39 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 19 Apr 2010 13:13:39 -0700 Subject: Earthlink Email Issues with new ARIN range In-Reply-To: <0900C6A3-C4FE-470D-B78D-7766C25F2001@sohonet.co.uk> References: <0900C6A3-C4FE-470D-B78D-7766C25F2001@sohonet.co.uk> Message-ID: <4BCCB973.2060500@rollernet.us> On 4/19/2010 04:09, Martin Rushworth wrote: > Hi, > > can someone that handles Earthlink blacklist/zombie settings please contact me off-list? > > we have a recently allocated ARIN /20 range, and all our clients allocated out of this are having issues emailing earthlink email accounts, our other ARIN ranges are fine. No luck through any other channels. > Have you tried asking mailop or spam-l ? ~Seth From andyring at inebraska.com Mon Apr 19 15:20:09 2010 From: andyring at inebraska.com (Andy Ringsmuth) Date: Mon, 19 Apr 2010 15:20:09 -0500 Subject: Anyone from CSX Transportation on this list? Message-ID: Mail from my company, which is under contract with CSX's Corporate Communications department (and has been for several years) to publish division and shop newsletters for the CSXT railroad system, began bouncing earlier this afternoon. Was hoping there might be someone from CSXT on this list who could contact me off-list. ---- Andy Ringsmuth andy at newslink.com News Link ? Manager Technology 1845 S. 11th St., Lincoln, NE 68502 (402) 475-6397 (402) 304-0083 cellular From leen at consolejunkie.net Mon Apr 19 15:20:24 2010 From: leen at consolejunkie.net (Leen Besselink) Date: Mon, 19 Apr 2010 22:20:24 +0200 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBE891.4010206@bogus.com> <20100419143118.GA77881@ussenterprise.ufp.org> Message-ID: <4BCCBB08.5040206@consolejunkie.net> On 04/19/2010 07:45 PM, Bill Bogstad wrote: > On Mon, Apr 19, 2010 at 1:14 PM, Mohacsi Janos wrote: > >> >> >> On Mon, 19 Apr 2010, Bill Bogstad wrote: >> >> >>> On Mon, Apr 19, 2010 at 12:10 PM, Frank Bulk - iName.com >>> wrote: >>> >>>> Don't forget the home gateway aspect -- it's a huge gaping hole in the >>>> IPv6 >>>> deployment strategy for ISPs. And don't talk to me about Apple's Airport >>>> Extreme. ISPs want (once the volume of IETF IPv6-related drafts has >>>> settled >>>> down) for every router at Wal-mart to include IPv6 support. If they >>>> start >>>> right now and presume that home gateways/routers are replaced every 3 to >>>> 5 >>>> years, it will be several years before they've covered even 50% of the >>>> homes. >>>> >>> Alternatively, they could commission the vendors to release firmware >>> upgrades with IPv6 support for the most common older devices. Given >>> that many of them are Linux based and the code already exists, this >>> isn't likely to be technically difficult. >>> >> Yes it is. Most of the home gateways are are manufactured : develop, produce >> and forget life-cycle. The development codebase, is not existing anymore. >> The developers are moved to another company.... You barely have support for >> low-end home gateways after a year of first shipment. In the first year some >> bugfixing.... >> > That's because they aren't getting paid for maintaining old firmware > (razor thin margins). At least in the case of Linux based units, GPL > enforcement has for the most part required them to keep better track > of their codebase. As a result, I think this is more feasible then > you do. Still it WOULD be easier to just work on getting all new > equipment IPv6 capable. Both cable and cellphone companies already > commission custom firmware for their settop boxes and cell phones, I > see no reason that ISPs couldn't do the same. > > I actually think the razor thin margins make it less likely. If I'm not mistaken, one of the reasons firmware updates are not available from a number of vendors/products, is because the small boxes don't have enough ROM and/or RAM. The ROM is to small to hold an extra stack (or other features) and/or the RAM is to small to handle the connection tracking for the larger addresses. Because people want a stateful firewall, right ? >> >>> Start by commissioning IPv6 support into all new hardware. I would >>> think that given the razor thin margins in home gateways/routers extra >>> money coming in for simply turning on code which already exists would >>> be attractive to at least some of them. Come up with some kind of >>> logo for the program "IPv6 READY!". >>> >> Don't count much on "IPv6 READY!" logo. IPv6 READY usually means, there are >> some IPv6 support in the device, but it might not work on your particular >> environment....: no IPv6 on PPPoE, no DHCPv6 support, no IPv6 setting are >> possible on webinterface.... >> > That's why you make it a trademarked logo and you have licensing > requirements that > specify what must be included in order for them to use the logo on > their marketing materials. The consortium decides what is needed to > make IPv6 work for them and enforces it via logo licensing. > Frankly if the protocols out of the IETF for things like > DHCP/default routes don't make sense, the consortium can simply > specify something else. I'm pretty sure that if the spec comes with > a sufficiently large check attached the OEMs will implement whatever > you want in the firmware. > > Bill Bogstad > > > From bill at herrin.us Mon Apr 19 15:52:30 2010 From: bill at herrin.us (William Herrin) Date: Mon, 19 Apr 2010 16:52:30 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCC9157.9040507@bryanfields.net> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC9157.9040507@bryanfields.net> Message-ID: On Mon, Apr 19, 2010 at 1:22 PM, Bryan Fields wrote: > On 4/19/2010 10:14, Patrick Giagnocavo wrote: >> The eyeball ISPs will find it trivial to NAT should they ever need to do >> so however, something servers cannot do - you are looking at numbers, >> not operational considerations. > > LSN is not trivial. > > Here is some unverified calculations I did on the problem of scaling nat. > > Right now I'm using 42 translation entries in my nat table. ?Each entry takes > up 312 bytes of FIB memory, which is ~12.7 Kib of data in the FIB. ?Mutiply > this by 250k users and we have 3,124,237 KiB of FIB entries, or 3.1 GiB. ?This > is not running any PtP programs or really hitting the network, I'm just > browsing the web and typing this email to you. Bryan, Is there some reason we believe we need to scale individual NAT systems beyond about 1000 users each in order to have the desired impact on address recapture/reuse? Growing towards 7B people in the world with, let's say, 4 connected client devices each, grouped 1000 per NAT box requires 7B * 4 / 1K = 28M or 1.7 /8's for the eyeball networks before structural overhead. Pushing a carrier NAT process shallow has its own set of complications (and certainly isn't trivial) but raw scalability doesn't look like one of the problems. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jbates at brightok.net Mon Apr 19 15:56:41 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 19 Apr 2010 15:56:41 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCC6553.4060202@zill.net> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> Message-ID: <4BCCC389.7050604@brightok.net> Patrick Giagnocavo wrote: > The eyeball ISPs will find it trivial to NAT should they ever need to do > so however, something servers cannot do - you are looking at numbers, > not operational considerations. I'll recommend this for competitors. Jack From owen at delong.com Mon Apr 19 16:01:03 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 19 Apr 2010 14:01:03 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC9157.9040507@bryanfields.net> Message-ID: <6714C861-5510-4AAC-A1AA-06AADAA71858@delong.com> On Apr 19, 2010, at 1:52 PM, William Herrin wrote: > On Mon, Apr 19, 2010 at 1:22 PM, Bryan Fields wrote: >> On 4/19/2010 10:14, Patrick Giagnocavo wrote: >>> The eyeball ISPs will find it trivial to NAT should they ever need to do >>> so however, something servers cannot do - you are looking at numbers, >>> not operational considerations. >> >> LSN is not trivial. >> >> Here is some unverified calculations I did on the problem of scaling nat. >> >> Right now I'm using 42 translation entries in my nat table. Each entry takes >> up 312 bytes of FIB memory, which is ~12.7 Kib of data in the FIB. Mutiply >> this by 250k users and we have 3,124,237 KiB of FIB entries, or 3.1 GiB. This >> is not running any PtP programs or really hitting the network, I'm just >> browsing the web and typing this email to you. > > Bryan, > > Is there some reason we believe we need to scale individual NAT > systems beyond about 1000 users each in order to have the desired > impact on address recapture/reuse? Growing towards 7B people in the > world with, let's say, 4 connected client devices each, grouped 1000 > per NAT box requires 7B * 4 / 1K = 28M or 1.7 /8's for the eyeball > networks before structural overhead. > > Pushing a carrier NAT process shallow has its own set of complications > (and certainly isn't trivial) but raw scalability doesn't look like > one of the problems. > The hardware cost of supporting LSN is trivial. The management/maintenance costs and the customer experience -> dissatisfaction -> support calls -> employee costs will not be so trivial. These facts make me very glad that my networks will NOT be implementing LSN in any form. Owen From jbates at brightok.net Mon Apr 19 16:09:13 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 19 Apr 2010 16:09:13 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100419180719.GB97473@ussenterprise.ufp.org> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC9157.9040507@bryanfields.net> <20100419180719.GB97473@ussenterprise.ufp.org> Message-ID: <4BCCC679.5090706@brightok.net> Leo Bicknell wrote: > NAT scales just fine. I find that quite unfortunate, personally, > but I don't think there's a problem with the technology or economics. > > My juniper doesn't have the memory you specify, and honestly will crash if everything goes processor based. Replacing hundreds of thousands of dollars of routers? Not feasible. Jack From Joel.Snyder at Opus1.COM Mon Apr 19 16:23:22 2010 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Mon, 19 Apr 2010 14:23:22 -0700 Subject: Niksun Probe In-Reply-To: References: Message-ID: <4BCCC9CA.2000306@opus1.com> > Looking for information on a Niksun probe, http://www.niksun.com/. > Anyone have any experience, good or bad with them? If you're looking at Niksun, you should look at NetWitness and Solera instead. My perception based on their presence in the market is that Niksun is on the way to oblivion, while Solera and NetWitness are the two hot new companies in this space. NetWitness seems to be better on the analysis side, with sucky capture facilities; Solera seems to be a lot better on the capture side of the house, but is less advanced in the analysis. I have also had a briefing from Endace, down in Kiwi-land. They seem to think they are the bees knees when it comes to capture, but have a really confused message about where they are trying to go with that data. Lots of buzzwords, but I don't think they really understand the dimensions of the problem that they are adding. But if you just want capture, Endace might be a good solution. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From nanog at spoofer.com Mon Apr 19 16:54:58 2010 From: nanog at spoofer.com (nanog nanog) Date: Mon, 19 Apr 2010 14:54:58 -0700 Subject: Niksun Probe Message-ID: <20100419145458.53BF4C3@resin18.mta.everyone.net> There is also the INVEA-TECH Flowmon : http://www.invea-tech.com/products-and-services/flowmon/flowmon-overvie w http://www.cert.org/flocon/2009/presentations/Celeda_FlexibleFlow.pdf http://en.wikipedia.org/wiki/FlowMon On 04/19/2010 11:23 PM, Joel M Snyder wrote: > >> Looking for information on a Niksun probe, http://www.niksun.com/. >> Anyone have any experience, good or bad with them? > > If you're looking at Niksun, you should look at NetWitness and Solera instead. > > My perception based on their presence in the market is that Niksun is on the way to oblivion, while Solera and NetWitness are the two hot new companies in this space. NetWitness seems to be better on the analysis side, with sucky capture facilities; Solera seems to be a lot better on the capture side of the house, but is less advanced in the analysis. > > I have also had a briefing from Endace, down in Kiwi-land. They seem to think they are the bees knees when it comes to capture, but have a re ally confused message about where they are trying to go with that data. Lots of buzzwords, but I don't think they really understand the dimensi ons of the problem that they are adding. But if you just want capture, Endace might be a good solution. > > jms > __________________________________________________________________ Get your own *free* email address like this one from www.OwnEmail.com From Bryan at bryanfields.net Mon Apr 19 17:03:20 2010 From: Bryan at bryanfields.net (Bryan Fields) Date: Mon, 19 Apr 2010 18:03:20 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100419180719.GB97473@ussenterprise.ufp.org> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC9157.9040507@bryanfields.net> <20100419180719.GB97473@ussenterprise.ufp.org> Message-ID: <4BCCD328.1030907@bryanfields.net> On 4/19/2010 14:07, Leo Bicknell wrote: > e a few problems with your data.... > > I know of no platform that does hardware NAT. Rather, NAT is a CPU > function. While this is another interesting scaling issue, it means > this data is not going in the FIB (hardware forwarding database), > but rather is stored in a CPU accessible database. > > It's not that you need 3.1G/254G of memory in the FIB (which would > be expensive) but rather that you need it in relatively cheap DRAM. > Even if use your larger memory number of 254G that's only $10-15k > of RAM cost these days, hardly a deal breaker. The FIB would hold > only one entry for the /17 (or similar) pointing it to the CPU. Well thats true of some implementations now, but some others put it in hardware. I'd say to scale you need to have it in hardware. > Secondly, you're playing to both extremes. Yes, the point to point > user will use 3500 entries and grandma checking e-mail may use 42 > entries. Not everyone will run a point to point client, and not > everyone will be grandma. Using an average is a much better first > start. I suspect though the percentage of users using a point to > point client is small though, and thus drives the average number > even lower. Yes, but I was showing what a great DDOS attack method it would be too ;) The numbers were slightly better than something I pulled from my backside to demonstrate why we can't nat an entire PDSN worth of customers. > So, 3500 + 42 / 2 = 1751 entries on average per person. > > 250,000 users * 1751 entries * 312 bytes/entry = ~136G of data. > > 250,000 users * 1751 entries / 64000 ports/IP = 6939 IP's. > > So a /19 provides headroom. 10 servers, each with 16G of RAM > (160G total) could do the job with headroom. Yea, but this is more along the lines of a science experiment at this point. I can't expect a carrier to deploy this, even if it's the best solution. The average carrier is _dumb_ and stupidity takes care of stupidity at these places. They are not going to deploy something unless it's Blue or Green (or purple). > Not all users will be active at the same time, so 100k per user > probably translates into a 1Mbps/sec rate, given the old 10:1 rule on > end users. > > 250,000 users * 100,000 bytes/sec = ~186Gigabits/sec. Humm, > 10 servers won't do that (18Gbps/sec per server of NAT, no way!). > 40 servers though would be 4.65Gbps per box, which with 10GE seems > reasonable. But that also means each one only needs 1/4th the RAM > from above. > > In summary, to NAT 250,000 users: > > 40 servers, each with: > CPU capable of NATing 4.65Gbps > 4-8Gb of memory > 2x10GE interfaces > A /19 of address space. > > I think a server like that could be had for $10k each, easy. So > 400k of servers, depreciated over 3 years, divided by 250,000 users: > $0.53 per user per YEAR. Or, $0.04 per month per user. Even selling > $20 packages ISP's should be able to absorb four cents per user. This is a good example, but I really would like to do some work on testing how much a given nat solution can scale. > NAT scales just fine. I find that quite unfortunate, personally, > but I don't think there's a problem with the technology or economics. It's a damn shame is what it is :( -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Apr 19 17:04:08 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Tue, 20 Apr 2010 07:34:08 +0930 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <201004191501.o3JF1P3x084685@aurora.sol.net> References: <871veb4hrr.fsf@mid.deneb.enyo.de> <201004191501.o3JF1P3x084685@aurora.sol.net> Message-ID: <20100420073408.4d04aad2@opy.nosense.org> On Mon, 19 Apr 2010 10:01:25 -0500 (CDT) Joe Greco wrote: > > * Nick Hilliard: > > > > > On 19/04/2010 16:14, Patrick Giagnocavo wrote: > > >> The eyeball ISPs will find it trivial to NAT should they ever need to do > > >> so [...] > > > > > Having made this bold claim, have you ever actually tried to run a natted > > > eyeball network? The last two natted eyeball networks I worked with could > > > never figure out which aspect of NAT hurt more: the technical side or the > > > business side. > > > > I'm pretty sure the acceptance of NAT varies regionally. I think > > there's a large ISP in Italy which has been doing NAT since the 90s. > > So it's not just the mobile domain. > > > > It can be tricky to introduce a new NATted product and compete with > > established players which do not NAT, though. > > It's another opportunity to monetize things. Give people the option of > a "real" IP address for $5 extra a month in case they actually need it > for gaming, etc., and default Grandma's average everyday connection to > NAT. > That'd be easy if you were just starting up an ISP. What do you do with your existing customer base? If their current service includes a dynamic public IPv4 address, you can't gracefully take it away, without likey violating services T&Cs, government telco regulations etc. So you'll have to go through a formal process of getting agreement with customers to take them away. Or do you have a flag fall day when after that new customers get NATted, but old customers don't? Do you offer a LSN vs non-LSN product at different price points? The price difference must be large enough for people to care about, or better described, bother with it, yet the problem might be that that discount might need to be so large that it doesn't actually cover the costs of providing a service to that customer. Thinking about what sort of discount I'd find attractive enough on roughly what I spend for ADSL Internet access, and putting myself in a customers position, I'd figure it'd be at least 10%. You'd have to state up front why you're offering a cheaper product, and for people to make an informed judgement value, they'll need to understand the problem i.e. the Internet running out of IPv4 addresses and what the consequences of NAT are. Their eyes will probably glaze over at this point, because all they want is "Internet" and don't care how it works, and are probably not going to want to accept restrictions now that might bite them in the future. At a certain point, the risks of going with a cheaper limited service, when you don't understand or fully understand it's restrictions, becomes higher than the price of the full service. IOW, if it's too hard to understand why the LSN service is cheaper, people will just pay the extra 10% - it's less riskier that way. That extra 10% is insurance. > The eyeball ISP's definitely have the easier end of things. > Considering the above issues, I'd think it's the other way around. > ... 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 fw at deneb.enyo.de Mon Apr 19 17:10:50 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 20 Apr 2010 00:10:50 +0200 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100419180719.GB97473@ussenterprise.ufp.org> (Leo Bicknell's message of "Mon, 19 Apr 2010 11:07:19 -0700") References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC9157.9040507@bryanfields.net> <20100419180719.GB97473@ussenterprise.ufp.org> Message-ID: <87zl0zgkk5.fsf@mid.deneb.enyo.de> * Leo Bicknell: > I know of no platform that does hardware NAT. Rather, NAT is a CPU > function. While this is another interesting scaling issue, it means > this data is not going in the FIB (hardware forwarding database), > but rather is stored in a CPU accessible database. If you NAT all traffic, the NAT database needs the same level of efficiency as the FIB. You could probably even join the two (you should check that the corresponding RIB entry is still current, but that can probably be forced to be cheap). From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Apr 19 17:21:57 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Tue, 20 Apr 2010 07:51:57 +0930 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100419.171923.74738974.sthaug@nethelp.no> References: <4BCBE891.4010206@bogus.com> <20100419143118.GA77881@ussenterprise.ufp.org> <20100419.171923.74738974.sthaug@nethelp.no> Message-ID: <20100420075157.3781eec1@opy.nosense.org> On Mon, 19 Apr 2010 17:19:23 +0200 (CEST) sthaug at nethelp.no wrote: > > There is also an aspect of this transition I don't think we've seen > > before (in networking). A large percentage of end users are on > > technologies (cable modem, dsl, even dial up) who's configuration > > is entirely driven out of a provisioning database. > > > > Once the backbone is rolled out, the nameservers, dhcp, and > > configuration servers dual-stacked many ISP's could enable IPv6 for > > all of their customers overnight with only a few keystrokes. > > *If* the whole IPv6 config can be driven from the same database. For > the time being, DHCPv6 cannot deliver a default gateway to customers > (and there is a religious faction within the IPv6 community which > seem to want to prevent this at all costs). > I'm not religious about it, however I don't understand why it's such a problem. My fundamental objection is that if you've got two ways of achieving something, you've got twice as many things that can go wrong. Duplicate functionality drives up capex and opex. I'd have been happy with IPv6 only using DHCPv6. I'd have been happy with IPv6 only using RA type mechanisms (i.e. like IPX and Appletalk). Now that we've got both (because there are valid arguments for each method), at least lets try to keep them as simple as possible, by avoiding duplicating functionality across each of them. Currently the only pure duplication the RDNSS option in RAs. Although I think DNS information can be considered bootstrap information, I do have a fear that the RDNSS option in RAs will become the thin edge of the wedge. > As long as we have the dependency on RA for default gateways, what > you suggest is considerably more difficult. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > From frnkblk at iname.com Mon Apr 19 17:39:41 2010 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 19 Apr 2010 17:39:41 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100420073408.4d04aad2@opy.nosense.org> References: <871veb4hrr.fsf@mid.deneb.enyo.de> <201004191501.o3JF1P3x084685@aurora.sol.net> <20100420073408.4d04aad2@opy.nosense.org> Message-ID: Offering native IPv4 when there's no addresses left will cost the ISP money if there is a market to buy more. LNS infrastructure and the associated indirect support costs will cost the ISP money. I'm not sure which customer base (native IPv4 or LNS) to give discounts to or charge extra for. All the more reason to push forward with dual-stacked IPv6 and hope that I get enough IPv4 addresses to make it through the multi-year transition time. Frank -----Original Message----- From: Mark Smith [mailto:nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org] Sent: Monday, April 19, 2010 5:04 PM To: Joe Greco Cc: NANOG list Subject: Re: Rate of growth on IPv6 not fast enough? On Mon, 19 Apr 2010 10:01:25 -0500 (CDT) Joe Greco wrote: > > * Nick Hilliard: > > > > > On 19/04/2010 16:14, Patrick Giagnocavo wrote: > > >> The eyeball ISPs will find it trivial to NAT should they ever need to do > > >> so [...] > > > > > Having made this bold claim, have you ever actually tried to run a natted > > > eyeball network? The last two natted eyeball networks I worked with could > > > never figure out which aspect of NAT hurt more: the technical side or the > > > business side. > > > > I'm pretty sure the acceptance of NAT varies regionally. I think > > there's a large ISP in Italy which has been doing NAT since the 90s. > > So it's not just the mobile domain. > > > > It can be tricky to introduce a new NATted product and compete with > > established players which do not NAT, though. > > It's another opportunity to monetize things. Give people the option of > a "real" IP address for $5 extra a month in case they actually need it > for gaming, etc., and default Grandma's average everyday connection to > NAT. > That'd be easy if you were just starting up an ISP. What do you do with your existing customer base? If their current service includes a dynamic public IPv4 address, you can't gracefully take it away, without likey violating services T&Cs, government telco regulations etc. So you'll have to go through a formal process of getting agreement with customers to take them away. Or do you have a flag fall day when after that new customers get NATted, but old customers don't? Do you offer a LSN vs non-LSN product at different price points? The price difference must be large enough for people to care about, or better described, bother with it, yet the problem might be that that discount might need to be so large that it doesn't actually cover the costs of providing a service to that customer. Thinking about what sort of discount I'd find attractive enough on roughly what I spend for ADSL Internet access, and putting myself in a customers position, I'd figure it'd be at least 10%. You'd have to state up front why you're offering a cheaper product, and for people to make an informed judgement value, they'll need to understand the problem i.e. the Internet running out of IPv4 addresses and what the consequences of NAT are. Their eyes will probably glaze over at this point, because all they want is "Internet" and don't care how it works, and are probably not going to want to accept restrictions now that might bite them in the future. At a certain point, the risks of going with a cheaper limited service, when you don't understand or fully understand it's restrictions, becomes higher than the price of the full service. IOW, if it's too hard to understand why the LSN service is cheaper, people will just pay the extra 10% - it's less riskier that way. That extra 10% is insurance. > The eyeball ISP's definitely have the easier end of things. > Considering the above issues, I'd think it's the other way around. > ... 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 nanog-post at rsuc.gweep.net Mon Apr 19 17:42:06 2010 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Mon, 19 Apr 2010 18:42:06 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBE891.4010206@bogus.com> <20100419143118.GA77881@ussenterprise.ufp.org> Message-ID: <20100419224206.GA36111@gweep.net> On Mon, Apr 19, 2010 at 12:58:43PM -0400, Bill Bogstad wrote: [snip] > be attractive to at least some of them. Come up with some kind of > logo for the program "IPv6 READY!". Make it a bandwagon thing so > that vendors who aren't part of the program look behind the times. Wheels, they get re-invented: http://www.ipv6ready.org/ Look at the dates in the FAQ, the news and the lack of Phase 3 to get depressed. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From Joel.Snyder at Opus1.COM Mon Apr 19 18:16:57 2010 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Mon, 19 Apr 2010 16:16:57 -0700 Subject: Niksun Probe In-Reply-To: References: Message-ID: <4BCCE469.4000004@opus1.com> > There is also the INVEA-TECH Flowmon : That's a radically different thing. Niksun, NetWitness, Solera are all about capturing lots of packets at very high speed. INVEA-TECH is a NetFlow kind of thing. Totally different; tells you completely different things about your network. If you want flows, there's LOTS of great products for flow monitoring, starting with Cisco and moving your way out through both open source and commercial products. But if you are considering Niksun, then flows are not what you're after. Packets are what you're after. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From nanogf at spoofer.com Mon Apr 19 18:57:54 2010 From: nanogf at spoofer.com (nanogf .) Date: Mon, 19 Apr 2010 16:57:54 -0700 Subject: 10Gbps Packet Capture Cards (was Re: Niksun Probe) Message-ID: <20100419165754.53B870C@resin18.mta.everyone.net> If you consider 10Gbps packet captures cards, there are : -2 OEMS (all the appliances are built around these) a) Napatech NT20E http://www.napatech.com/products/capture_adapters/2x10g_pcie_nt20e.html b) Endace DAG 9.2X2 http://www.endace.com/dag-9.2x2-packet-capture-card.html -3 ODMs a) INVEA-TECH NIFIC http://www.invea-tech.com/products-and-services/nific-appliance b) CESNET MTPP10-V5 http://docs.google.com/viewer?url=http://www.ces.net/project/qosip/hw/mt pp10-v5.pdf c) NTT Advanced Technology PRESTA 10G http://docs.google.com/viewer?url=http://www.internet2.edu/presentations /jt2010feb/20100201-sebayashi.pdf --- Joel.Snyder at Opus1.COM wrote: From: Joel M Snyder To: nanog at spoofer.com, nanog Subject: Re: Niksun Probe Date: Mon, 19 Apr 2010 16:16:57 -0700 > There is also the INVEA-TECH Flowmon : That's a radically different thing. Niksun, NetWitness, Solera are all about capturing lots of packets at very high speed. INVEA-TECH is a NetFlow kind of thing. Totally different; tells you completely different things about your network. If you want flows, there's LOTS of great products for flow monitoring, starting with Cisco and moving your way out through both open source and commercial products. But if you are considering Niksun, then flows are not what you're after. Packets are what you're after. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms _____________________________________________________________ Get your own *free* email address like this one from www.OwnEmail.com From jgreco at ns.sol.net Mon Apr 19 19:08:05 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 19 Apr 2010 19:08:05 -0500 (CDT) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20FCDD09-A4BC-41B5-AFCF-D9203C83DA58@delong.com> from "Owen DeLong" at Apr 19, 2010 10:34:30 AM Message-ID: <201004200008.o3K0852U007029@aurora.sol.net> > On Apr 19, 2010, at 8:23 AM, Joe Greco wrote: > >> On 19/04/2010 16:51, Florian Weimer wrote: > >>> I'm pretty sure the acceptance of NAT varies regionally. I think > >>> there's a large ISP in Italy which has been doing NAT since the 90s. > >> > >> to my knowledge, if we're talking about the same organisation, this large > >> ISP is moving away from NAT, or already has done so. > >> > >> Sure, you can NAT eyeballs, but it hurts like hell. > > > > Which hurts more ... NATting eyeballs, or blinding them entirely? > > > > Eventually we'll run out. Then we get to pick. > > IPv6 is not blinding them entirely. No, IPv6 is clear vision. My _point_ was that NAT'ing eyeballs was better than providing no IPv4 gameplan (i.e. blind). ... 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 jgreco at ns.sol.net Mon Apr 19 19:12:13 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 19 Apr 2010 19:12:13 -0500 (CDT) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCCC389.7050604@brightok.net> from "Jack Bates" at Apr 19, 2010 03:56:41 PM Message-ID: <201004200012.o3K0CDUL007165@aurora.sol.net> > Patrick Giagnocavo wrote: > > The eyeball ISPs will find it trivial to NAT should they ever need to do > > so however, something servers cannot do - you are looking at numbers, > > not operational considerations. > > I'll recommend this for competitors. And what'll you do for your customers when you have no more IPv4 addresses? ... 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 jgreco at ns.sol.net Mon Apr 19 19:22:02 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 19 Apr 2010 19:22:02 -0500 (CDT) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100420073408.4d04aad2@opy.nosense.org> from "Mark Smith" at Apr 20, 2010 07:34:08 AM Message-ID: <201004200022.o3K0M2Ba007459@aurora.sol.net> > On Mon, 19 Apr 2010 10:01:25 -0500 (CDT) > Joe Greco wrote: > > > > * Nick Hilliard: > > > > > > > On 19/04/2010 16:14, Patrick Giagnocavo wrote: > > > >> The eyeball ISPs will find it trivial to NAT should they ever need to do > > > >> so [...] > > > > > > > Having made this bold claim, have you ever actually tried to run a natted > > > > eyeball network? The last two natted eyeball networks I worked with could > > > > never figure out which aspect of NAT hurt more: the technical side or the > > > > business side. > > > > > > I'm pretty sure the acceptance of NAT varies regionally. I think > > > there's a large ISP in Italy which has been doing NAT since the 90s. > > > So it's not just the mobile domain. > > > > > > It can be tricky to introduce a new NATted product and compete with > > > established players which do not NAT, though. > > > > It's another opportunity to monetize things. Give people the option of > > a "real" IP address for $5 extra a month in case they actually need it > > for gaming, etc., and default Grandma's average everyday connection to > > NAT. > > That'd be easy if you were just starting up an ISP. What do you do with > your existing customer base? If their current service includes a > dynamic public IPv4 address, you can't gracefully take it away, without > likey violating services T&Cs, government telco regulations etc. So > you'll have to go through a formal process of getting agreement with > customers to take them away. I haven't seen any such documents or regulations. > Or do you have a flag fall day when after that new customers get NATted, > but old customers don't? Do you offer a LSN vs non-LSN product at > different price points? The price difference must be large enough for people to care about, or better > described, bother with it, yet the problem might be that that discount > might need to be so large that it doesn't actually cover the costs of > providing a service to that customer. Maybe the price difference for existing customers is $0. You put them on NAT, and if they squawk, put them back. Since you don't need to do your whole customer base at once, you can even learn along the way. > Thinking about what sort of discount I'd find attractive enough on > roughly what I spend for ADSL Internet access, and putting myself in a > customers position, I'd figure it'd be at least 10%. You'd have to > state up front why you're offering a cheaper product, and for people to > make an informed judgement value, they'll need to understand the > problem i.e. the Internet running out of IPv4 addresses and what the > consequences of NAT are. Their eyes will probably glaze over at this > point, because all they want is "Internet" and don't care how it works, > and are probably not going to want to accept restrictions now that > might bite them in the future. At a certain point, the risks of going > with a cheaper limited service, when you don't understand or fully > understand it's restrictions, becomes higher than the price of the full > service. IOW, if it's too hard to understand why the LSN service is > cheaper, people will just pay the extra 10% - it's less riskier that > way. That extra 10% is insurance. Many/most people are _already_ behind a NAT gateway. The guy who wrote "The Internet for Dummies" went for a good while behind a carrier NAT without realizing he was. And he's no dummy. Practical experience by network operators who have deployed NAT suggests that it's not ideal, but it's not horrible or impossible. A vast number of people just want to do their stuff and don't really care too much as long as things don't break. So what you need to do is consider what it is most people do, and how much of that would break. For an average household that's browsing the web and checking mail, NAT == not noticeable. And there will be other things, too, that work just fine. ... 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 jnegro at billtrust.com Mon Apr 19 19:32:47 2010 From: jnegro at billtrust.com (Jeffrey Negro) Date: Mon, 19 Apr 2010 20:32:47 -0400 Subject: Juniper firewalls - SSG or SRX Message-ID: Has anyone on Nanog had any hands on experience with the lower end of the new SRX series Junipers? We're looking to purchase two new firewalls, and I'm debating going with SSG series or to make the jump to the SRX line. Any input, especially about the learning curve jumping from ScreenOS to JunOS would be greatly appreciated. Thank you in advance. Jeffrey From Valdis.Kletnieks at vt.edu Mon Apr 19 20:01:10 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 19 Apr 2010 21:01:10 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: Your message of "Mon, 19 Apr 2010 18:42:06 EDT." <20100419224206.GA36111@gweep.net> References: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBE891.4010206@bogus.com> <20100419143118.GA77881@ussenterprise.ufp.org> <20100419224206.GA36111@gweep.net> Message-ID: <7352.1271725270@localhost> On Mon, 19 Apr 2010 18:42:06 EDT, Joe Provo said: > On Mon, Apr 19, 2010 at 12:58:43PM -0400, Bill Bogstad wrote: > [snip] > > be attractive to at least some of them. Come up with some kind of > > logo for the program "IPv6 READY!". Make it a bandwagon thing so > > that vendors who aren't part of the program look behind the times. > > Wheels, they get re-invented: http://www.ipv6ready.org/ How sad. I have IPv6, they don't (at the moment anyhow)... % wget http://www.ipv6ready.org --2010-04-19 20:53:53-- http://www.ipv6ready.org/ Resolving www.ipv6ready.org... 2001:468:603:c001::5, 132.177.125.100 Connecting to www.ipv6ready.org|2001:468:603:c001::5|:80... failed: Connection timed out. Connecting to www.ipv6ready.org|132.177.125.100|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 6381 (6.2K) [text/html] Saving to: ???index.html??? 100%[======================================>] 6,381 --.-K/s in 0.05s 2010-04-19 20:54:14 (122 KB/s) - ???index.html??? saved [6381/6381] % traceroute6 2001:468:603:c001::5 traceroute to 2001:468:603:c001::5 (2001:468:603:c001::5), 30 hops max, 80 byte packets 1 fe80::260:3eff:fe8c:bc99%ppp0 (fe80::260:3eff:fe8c:bc99%ppp0) 56.953 ms 65.618 ms 65.497 ms 2 isb-7301-1.gi0-1.110.cns.ipv6.vt.edu (2001:468:c80:210a::1) 64.179 ms 65.069 ms 65.086 ms 3 isb-6509-2.gi4-15.cns.ipv6.vt.edu (2001:468:c80:f220::1) 196.036 ms 198.903 ms 198.779 ms 4 isb-7606-1.ge1-1.cns.ipv6.vt.edu (2001:468:c80:f221::2) 64.558 ms 64.438 ms 64.315 ms 5 2001:468:cfe:1002::1 (2001:468:cfe:1002::1) 70.066 ms 69.948 ms 69.706 ms 6 2001:468:c00:ffff::1 (2001:468:c00:ffff::1) 69.574 ms 65.763 ms 55.573 ms 7 2001:468:c00:ffee::2 (2001:468:c00:ffee::2) 71.210 ms 71.056 ms 70.934 ms 8 2001:468:ff:906::1 (2001:468:ff:906::1) 75.973 ms 75.855 ms 75.677 ms 9 2001:468:ff:646::1 (2001:468:ff:646::1) 86.494 ms 86.363 ms 86.199 ms 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * -------------- 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 Mon Apr 19 20:16:40 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 20 Apr 2010 01:16:40 +0000 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <7352.1271725270@localhost> References: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBE891.4010206@bogus.com> <20100419143118.GA77881@ussenterprise.ufp.org> <20100419224206.GA36111@gweep.net> <7352.1271725270@localhost> Message-ID: <20100420011640.GA9016@vacation.karoshi.com.> now now... you know better than that. of course they have IPv6... they just don't connect to -your- IPv6 cloud... :) --bill On Mon, Apr 19, 2010 at 09:01:10PM -0400, Valdis.Kletnieks at vt.edu wrote: > On Mon, 19 Apr 2010 18:42:06 EDT, Joe Provo said: > > On Mon, Apr 19, 2010 at 12:58:43PM -0400, Bill Bogstad wrote: > > [snip] > > > be attractive to at least some of them. Come up with some kind of > > > logo for the program "IPv6 READY!". Make it a bandwagon thing so > > > that vendors who aren't part of the program look behind the times. > > > > Wheels, they get re-invented: http://www.ipv6ready.org/ > > How sad. I have IPv6, they don't (at the moment anyhow)... > > % wget http://www.ipv6ready.org > --2010-04-19 20:53:53-- http://www.ipv6ready.org/ > Resolving www.ipv6ready.org... 2001:468:603:c001::5, 132.177.125.100 > Connecting to www.ipv6ready.org|2001:468:603:c001::5|:80... failed: Connection timed out. > Connecting to www.ipv6ready.org|132.177.125.100|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 6381 (6.2K) [text/html] > Saving to: b index.htmlb > > 100%[======================================>] 6,381 --.-K/s in 0.05s > > 2010-04-19 20:54:14 (122 KB/s) - b index.htmlb saved [6381/6381] > > % traceroute6 2001:468:603:c001::5 > traceroute to 2001:468:603:c001::5 (2001:468:603:c001::5), 30 hops max, 80 byte packets > 1 fe80::260:3eff:fe8c:bc99%ppp0 (fe80::260:3eff:fe8c:bc99%ppp0) 56.953 ms 65.618 ms 65.497 ms > 2 isb-7301-1.gi0-1.110.cns.ipv6.vt.edu (2001:468:c80:210a::1) 64.179 ms 65.069 ms 65.086 ms > 3 isb-6509-2.gi4-15.cns.ipv6.vt.edu (2001:468:c80:f220::1) 196.036 ms 198.903 ms 198.779 ms > 4 isb-7606-1.ge1-1.cns.ipv6.vt.edu (2001:468:c80:f221::2) 64.558 ms 64.438 ms 64.315 ms > 5 2001:468:cfe:1002::1 (2001:468:cfe:1002::1) 70.066 ms 69.948 ms 69.706 ms > 6 2001:468:c00:ffff::1 (2001:468:c00:ffff::1) 69.574 ms 65.763 ms 55.573 ms > 7 2001:468:c00:ffee::2 (2001:468:c00:ffee::2) 71.210 ms 71.056 ms 70.934 ms > 8 2001:468:ff:906::1 (2001:468:ff:906::1) 75.973 ms 75.855 ms 75.677 ms > 9 2001:468:ff:646::1 (2001:468:ff:646::1) 86.494 ms 86.363 ms 86.199 ms > 10 * * * > 11 * * * > 12 * * * > 13 * * * > 14 * * * > 15 * * * > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > From mehmet at icann.org Mon Apr 19 20:48:27 2010 From: mehmet at icann.org (Mehmet Akcin) Date: Mon, 19 Apr 2010 18:48:27 -0700 Subject: Juniper firewalls - SSG or SRX In-Reply-To: Message-ID: SRX seems very new and many comment it as unstable, this includes some of Juniper engineers I know in person. SSG though is phasing out. 8months ago while I was looking for these solutions more closely, I had decided to stay with SSG, which was good for next 3-4 years. However I believe probabyl SRX is more reliable now, and moving from ScreenOS to Junos definitely is a learning curve but something that worth in long term. Mehmet On 4/19/10 5:32 PM, "Jeffrey Negro" wrote: > Has anyone on Nanog had any hands on experience with the lower end of the > new SRX series Junipers? We're looking to purchase two new firewalls, and > I'm debating going with SSG series or to make the jump to the SRX line. Any > input, especially about the learning curve jumping from ScreenOS to JunOS > would be greatly appreciated. Thank you in advance. > > Jeffrey From pstewart at nexicomgroup.net Mon Apr 19 20:54:39 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Mon, 19 Apr 2010 21:54:39 -0400 Subject: Juniper firewalls - SSG or SRX In-Reply-To: References: Message-ID: We've had GREAT success with SRX210, SRX240 and SRX650 boxes in the past 3-4 months. There has been some issues I'll admit but they were all fixed either in service releases or actual JunOS upgrades. I believe that most of the issues you hear about were in the 9.x JunOS releases or at least that was my experience... Paul -----Original Message----- From: Mehmet Akcin [mailto:mehmet at icann.org] Sent: April-19-10 9:48 PM To: Jeffrey Negro; nanog at nanog.org Subject: Re: Juniper firewalls - SSG or SRX SRX seems very new and many comment it as unstable, this includes some of Juniper engineers I know in person. SSG though is phasing out. 8months ago while I was looking for these solutions more closely, I had decided to stay with SSG, which was good for next 3-4 years. However I believe probabyl SRX is more reliable now, and moving from ScreenOS to Junos definitely is a learning curve but something that worth in long term. Mehmet On 4/19/10 5:32 PM, "Jeffrey Negro" wrote: > Has anyone on Nanog had any hands on experience with the lower end of the > new SRX series Junipers? We're looking to purchase two new firewalls, and > I'm debating going with SSG series or to make the jump to the SRX line. Any > input, especially about the learning curve jumping from ScreenOS to JunOS > would be greatly appreciated. Thank you in advance. > > Jeffrey From marka at isc.org Mon Apr 19 21:24:57 2010 From: marka at isc.org (Mark Andrews) Date: Tue, 20 Apr 2010 12:24:57 +1000 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: Your message of "Mon, 19 Apr 2010 19:22:02 EST." <201004200022.o3K0M2Ba007459@aurora.sol.net> References: <201004200022.o3K0M2Ba007459@aurora.sol.net> Message-ID: <201004200225.o3K2OwVi070153@drugs.dv.isc.org> In message <201004200022.o3K0M2Ba007459 at aurora.sol.net>, Joe Greco writes: > > That'd be easy if you were just starting up an ISP. What do you do with > > your existing customer base? If their current service includes a > > dynamic public IPv4 address, you can't gracefully take it away, without > > likey violating services T&Cs, government telco regulations etc. So > > you'll have to go through a formal process of getting agreement with > > customers to take them away. > > I haven't seen any such documents or regulations. People purchaced the service on the understanding that they would get a Internet address. A address behind a NAT is not a Internet address, it's a *shared* Internet address which is a very different thing. > Many/most people are _already_ behind a NAT gateway. They are behind NAT44 which they deployed themselves and control the configuration of themselves. They can direct incoming traffic as they see fit. They are NOT restricted to UDP and TCP. NAT444 is a different kettle of fish. There are lots of things that you do with a NAT44 that you can't do with a NAT444. If all you do is browse the web and read email then you won't see the much of a difference. If you do anything more complicated than making outgoing queries you will see the difference. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From patrick at zill.net Mon Apr 19 21:43:59 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Mon, 19 Apr 2010 22:43:59 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <201004200225.o3K2OwVi070153@drugs.dv.isc.org> References: <201004200022.o3K0M2Ba007459@aurora.sol.net> <201004200225.o3K2OwVi070153@drugs.dv.isc.org> Message-ID: <4BCD14EF.8090204@zill.net> Mark Andrews wrote: > In message <201004200022.o3K0M2Ba007459 at aurora.sol.net>, Joe Greco writes: >>> That'd be easy if you were just starting up an ISP. What do you do with >>> your existing customer base? If their current service includes a >>> dynamic public IPv4 address, you can't gracefully take it away, without >>> likey violating services T&Cs, government telco regulations etc. So >>> you'll have to go through a formal process of getting agreement with >>> customers to take them away. >> I haven't seen any such documents or regulations. > > People purchaced the service on the understanding that they would > get a Internet address. A address behind a NAT is not a Internet > address, it's a *shared* Internet address which is a very different > thing. > Given that many ISPs put their sign-up documents, including contracts, on-line, you can no doubt supply a link to such a document that has legal terms that would preclude NATed service, yes? My recollection is only that I would be provided with "Internet service" or "access to the Internet" . No mention of RFC1918 space or other distinguishing information was given. Note in the below blurb no mention of publicly routable addresses... Comcast's contract states: "Comcast will provide you with dynamic Internet protocol ("IP") address(es) as a component of HSI, and these IP address(es) can and do change over time. You will not alter, modify, or tamper with dynamic IP address(es) assigned to you or any other customer. You agree not to use a dynamic domain name server or DNS to associate a host name with the dynamic IP address(es) for any commercial purpose. You also agree not to use any software that provides for static IP address(es) on or in conjunction with any computer(s) or network device connected to HSI. If applicable, Comcast will release and/or recover the dynamic IP address(es) when the Service or this Agreement is disconnected, discontinued, or terminated." --Patrick From owen at delong.com Mon Apr 19 21:57:04 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 19 Apr 2010 19:57:04 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <87zl0zgkk5.fsf@mid.deneb.enyo.de> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC9157.9040507@bryanfields.net> <20100419180719.GB97473@ussenterprise.ufp.org> <87zl0zgkk5.fsf@mid.deneb.enyo.de> Message-ID: <6E6E5B81-36CC-43AA-B8C7-C4C364E9FEC6@delong.com> On Apr 19, 2010, at 3:10 PM, Florian Weimer wrote: > * Leo Bicknell: > >> I know of no platform that does hardware NAT. Rather, NAT is a CPU >> function. While this is another interesting scaling issue, it means >> this data is not going in the FIB (hardware forwarding database), >> but rather is stored in a CPU accessible database. > > If you NAT all traffic, the NAT database needs the same level of > efficiency as the FIB. > > You could probably even join the two (you should check that the > corresponding RIB entry is still current, but that can probably be > forced to be cheap). More likely, if you're going to do this (and I would not wish it on my worst competitors), you would want to push smaller NATs out towards the customer aggregation point where you can get away with cheaper commodity hardware that can later be repurposed. Yes, more boxes, but, much less expensive and keeps the router doing what routers do best rather than NATing everything on the router. Owen From owen at delong.com Mon Apr 19 22:05:54 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 19 Apr 2010 20:05:54 -0700 Subject: Juniper firewalls - SSG or SRX In-Reply-To: References: Message-ID: <95099184-EE87-4191-9EF1-9EE52E6A5738@delong.com> Much.. Go SRX over SSG every time. For anything that doesn't have an SRX analog, consider the J-series. SRX/J-Series == JunOS == Good. SSG Series == ScreenOS == @)#$*#@)$(*!)(@$!@$ Just my $0.02 having dealt extensively with both environments over the years. Owen On Apr 19, 2010, at 5:32 PM, Jeffrey Negro wrote: > Has anyone on Nanog had any hands on experience with the lower end of the > new SRX series Junipers? We're looking to purchase two new firewalls, and > I'm debating going with SSG series or to make the jump to the SRX line. Any > input, especially about the learning curve jumping from ScreenOS to JunOS > would be greatly appreciated. Thank you in advance. > > Jeffrey From marka at isc.org Mon Apr 19 22:20:11 2010 From: marka at isc.org (Mark Andrews) Date: Tue, 20 Apr 2010 13:20:11 +1000 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: Your message of "Mon, 19 Apr 2010 22:43:59 -0400." <4BCD14EF.8090204@zill.net> References: <201004200022.o3K0M2Ba007459@aurora.sol.net> <201004200225.o3K2OwVi070153@drugs.dv.isc.org> <4BCD14EF.8090204@zill.net> Message-ID: <201004200320.o3K3KB4s071149@drugs.dv.isc.org> In message <4BCD14EF.8090204 at zill.net>, Patrick Giagnocavo writes: > Mark Andrews wrote: > > In message <201004200022.o3K0M2Ba007459 at aurora.sol.net>, Joe Greco writes: > >>> That'd be easy if you were just starting up an ISP. What do you do with > >>> your existing customer base? If their current service includes a > >>> dynamic public IPv4 address, you can't gracefully take it away, without > >>> likey violating services T&Cs, government telco regulations etc. So > >>> you'll have to go through a formal process of getting agreement with > >>> customers to take them away. > >> I haven't seen any such documents or regulations. > > > > People purchaced the service on the understanding that they would > > get a Internet address. A address behind a NAT is not a Internet > > address, it's a *shared* Internet address which is a very different > > thing. > > Given that many ISPs put their sign-up documents, including contracts, > on-line, you can no doubt supply a link to such a document that has > legal terms that would preclude NATed service, yes? > > My recollection is only that I would be provided with "Internet service" > or "access to the Internet" . No mention of RFC1918 space or other > distinguishing information was given. > > Note in the below blurb no mention of publicly routable addresses... It doesn't have to as the normal definition of a Internet address is a publically routable internet address. A address behind a NAT is not a Internet address (Big I Internet). If you supply something less than a full blown Internet access you need to point out the restriction otherwise I would expect you to be subject to "Bait and Switch" and other consumer protection laws. Mark > Comcast's contract states: > > "Comcast will provide you with dynamic Internet protocol ("IP") > address(es) as a component of HSI, and these IP address(es) can and do > change over time. You will not alter, modify, or tamper with dynamic IP > address(es) assigned to you or any other customer. You agree not to use > a dynamic domain name server or DNS to associate a host name with the > dynamic IP address(es) for any commercial purpose. You also agree not to > use any software that provides for static IP address(es) on or in > conjunction with any computer(s) or network device connected to HSI. If > applicable, Comcast will release and/or recover the dynamic IP > address(es) when the Service or this Agreement is disconnected, > discontinued, or terminated." > > --Patrick -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From patrick at zill.net Mon Apr 19 22:32:14 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Mon, 19 Apr 2010 23:32:14 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <201004200320.o3K3KB4s071149@drugs.dv.isc.org> References: <201004200022.o3K0M2Ba007459@aurora.sol.net> <201004200225.o3K2OwVi070153@drugs.dv.isc.org> <4BCD14EF.8090204@zill.net> <201004200320.o3K3KB4s071149@drugs.dv.isc.org> Message-ID: <4BCD203E.3050302@zill.net> Mark Andrews wrote: > In message <4BCD14EF.8090204 at zill.net>, Patrick Giagnocavo writes: >> Mark Andrews wrote: >>> In message <201004200022.o3K0M2Ba007459 at aurora.sol.net>, Joe Greco writes: >>>> I haven't seen any such documents or regulations. >>> People purchaced the service on the understanding that they would >>> get a Internet address. A address behind a NAT is not a Internet >>> address, it's a *shared* Internet address which is a very different >>> thing. >> Given that many ISPs put their sign-up documents, including contracts, >> on-line, you can no doubt supply a link to such a document that has >> legal terms that would preclude NATed service, yes? >> >> My recollection is only that I would be provided with "Internet service" >> or "access to the Internet" . No mention of RFC1918 space or other >> distinguishing information was given. >> >> Note in the below blurb no mention of publicly routable addresses... > > It doesn't have to as the normal definition of a Internet address > is a publically routable internet address. A address behind a NAT > is not a Internet address (Big I Internet). > (hope the attribution is not screwed up) *ANY* valid Internet Protocol address is an "IP address" as mentioned in the contract I quoted. Including 192.168.99.2 . > If you supply something less than a full blown Internet access you > need to point out the restriction otherwise I would expect you to > be subject to "Bait and Switch" and other consumer protection laws. > You are charmingly naive about how "the law" actually works in the USA - that is IMHO. In any case, I left the large amount of quotes in to show that I (and possibly Joe) are asking you for specific examples to support your argument - and all you are offering is more of your personal opinion, which is not an objective source of support for your position. If I want that, I can go to any of *.livejournal.com, *.blogger.com , etc. --Patrick From marka at isc.org Mon Apr 19 22:58:13 2010 From: marka at isc.org (Mark Andrews) Date: Tue, 20 Apr 2010 13:58:13 +1000 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: Your message of "Mon, 19 Apr 2010 23:32:14 -0400." <4BCD203E.3050302@zill.net> References: <201004200022.o3K0M2Ba007459@aurora.sol.net> <201004200225.o3K2OwVi070153@drugs.dv.isc.org> <4BCD14EF.8090204@zill.net> <201004200320.o3K3KB4s071149@drugs.dv.isc.org> <4BCD203E.3050302@zill.net> Message-ID: <201004200358.o3K3wDQk071509@drugs.dv.isc.org> In message <4BCD203E.3050302 at zill.net>, Patrick Giagnocavo writes: > Mark Andrews wrote: > > In message <4BCD14EF.8090204 at zill.net>, Patrick Giagnocavo writes: > >> Mark Andrews wrote: > >>> In message <201004200022.o3K0M2Ba007459 at aurora.sol.net>, Joe Greco writes > : > >>>> I haven't seen any such documents or regulations. > >>> People purchaced the service on the understanding that they would > >>> get a Internet address. A address behind a NAT is not a Internet > >>> address, it's a *shared* Internet address which is a very different > >>> thing. > >> Given that many ISPs put their sign-up documents, including contracts, > >> on-line, you can no doubt supply a link to such a document that has > >> legal terms that would preclude NATed service, yes? > >> > >> My recollection is only that I would be provided with "Internet service" > >> or "access to the Internet" . No mention of RFC1918 space or other > >> distinguishing information was given. > >> > >> Note in the below blurb no mention of publicly routable addresses... > > > > It doesn't have to as the normal definition of a Internet address > > is a publically routable internet address. A address behind a NAT > > is not a Internet address (Big I Internet). > > > > (hope the attribution is not screwed up) > > *ANY* valid Internet Protocol address is an "IP address" as mentioned in > the contract I quoted. Including 192.168.99.2 . > > > > If you supply something less than a full blown Internet access you > > need to point out the restriction otherwise I would expect you to > > be subject to "Bait and Switch" and other consumer protection laws. > > You are charmingly naive about how "the law" actually works in the USA - > that is IMHO. Yes, things vary around the world. You failed to state "In the USA". There is plenty of case law in Australia about companies attempting to arbitarially change terms and conditions to the detriment of the consumer and being made to reverse the changes. Changing from a public IP address to a private IP address is a big change in the conditions of the contract. People do select ISP's on the basis of whether they will get a public IP address or a private IP address. > In any case, I left the large amount of quotes in to show that I (and > possibly Joe) are asking you for specific examples to support your > argument - and all you are offering is more of your personal opinion, > which is not an objective source of support for your position. > > If I want that, I can go to any of *.livejournal.com, *.blogger.com , etc. > > --Patrick -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From perry at coders.net Mon Apr 19 23:33:48 2010 From: perry at coders.net (Perry Lorier) Date: Tue, 20 Apr 2010 16:33:48 +1200 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCC9157.9040507@bryanfields.net> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC9157.9040507@bryanfields.net> Message-ID: <4BCD2EAC.60209@coders.net> > LSN is not trivial. > > Here is some unverified calculations I did on the problem of scaling nat. > One of my colleagues here (Shane Alcock) did some research into "Service Provider NAT" based off passive traces from a New Zealand Residential ISP[1]. By passively looking at connections he investigated how you could dimension a NAT box for an ISP. His research is available here http://www.wand.net.nz/~salcock/spnat/tech_report.pdf . If walls of text scare you (why are you reading this mailing list then?) skip through and look at the graphs (page 3 onwards) [1]: Contrary to Joe Abley's belief, I'm not aware of any major DSL provider in NZ that is doing NAT inside their network -- although almost all of the CPE's in New Zealand do NAT you, so as an end user you usually do end up behind NAT, but it is one under your own control, and can be eliminated with a careful choice of CPE. There are some wifi providers, and some 3G APN's that will provide you with ISP NAT. From seph at directionless.org Mon Apr 19 23:39:47 2010 From: seph at directionless.org (seph) Date: Tue, 20 Apr 2010 00:39:47 -0400 Subject: Juniper firewalls - SSG or SRX In-Reply-To: <95099184-EE87-4191-9EF1-9EE52E6A5738@delong.com> (Owen DeLong's message of "Mon, 19 Apr 2010 20:05:54 -0700") References: <95099184-EE87-4191-9EF1-9EE52E6A5738@delong.com> Message-ID: I'm with Owen. I have nothing good to say about ScreenOS. In contrast JunOS has been great. seph Owen DeLong writes: > Much.. Go SRX over SSG every time. For anything that doesn't have an > SRX analog, consider the J-series. > > SRX/J-Series == JunOS == Good. > SSG Series == ScreenOS == @)#$*#@)$(*!)(@$!@$ > > Just my $0.02 having dealt extensively with both environments over the > years. > > Owen > > On Apr 19, 2010, at 5:32 PM, Jeffrey Negro wrote: > >> Has anyone on Nanog had any hands on experience with the lower end of the >> new SRX series Junipers? We're looking to purchase two new firewalls, and >> I'm debating going with SSG series or to make the jump to the SRX line. Any >> input, especially about the learning curve jumping from ScreenOS to JunOS >> would be greatly appreciated. Thank you in advance. >> >> Jeffrey From adrian at creative.net.au Mon Apr 19 23:47:39 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 20 Apr 2010 12:47:39 +0800 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCD2EAC.60209@coders.net> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC9157.9040507@bryanfields.net> <4BCD2EAC.60209@coders.net> Message-ID: <20100420044739.GK17577@skywalker.creative.net.au> On Tue, Apr 20, 2010, Perry Lorier wrote: > One of my colleagues here (Shane Alcock) did some research into "Service > Provider NAT" based off passive traces from a New Zealand Residential > ISP[1]. By passively looking at connections he investigated how you > could dimension a NAT box for an ISP. His research is available here > http://www.wand.net.nz/~salcock/spnat/tech_report.pdf . If walls of > text scare you (why are you reading this mailing list then?) skip > through and look at the graphs (page 3 onwards) Interesting. Only a few days, and not really any analysis for worst case scenarios and how to possibly gracefully recover from those. (eg, I've done some NAT hacks to detect idle HTTP pconns and toss those before tossing the others.) Adrian From mysidia at gmail.com Tue Apr 20 01:20:09 2010 From: mysidia at gmail.com (James Hess) Date: Tue, 20 Apr 2010 01:20:09 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100420044739.GK17577@skywalker.creative.net.au> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC9157.9040507@bryanfields.net> <4BCD2EAC.60209@coders.net> <20100420044739.GK17577@skywalker.creative.net.au> Message-ID: On Mon, Apr 19, 2010 at 11:47 PM, Adrian Chadd wrote: > On Tue, Apr 20, 2010, Perry Lorier wrote: >> could dimension a NAT box for an ISP. ?His research is available here >> http://www.wand.net.nz/~salcock/spnat/tech_report.pdf . ?If walls of >> text scare you (why are you reading this mailing list then?) skip >> through and look at the graphs (page 3 onwards) > Interesting. Only a few days, and not really any analysis for worst > case scenarios and how to possibly gracefully recover from those. > (eg, I've done some NAT hacks to detect idle HTTP pconns and toss > those before tossing the others.) I found some of the premises lacking, at least, in an initial reading; session expiration is a problem for SP NAT, and for that reason, the dimensioning that makes it even worse is questionable, in that the shown er solution to UDP packets creating many sessions was by establishing extra short expiration durations; it attempts to address one problem, while creating an even bigger one..., NAPT with short expiration in a SP environment indicates a point of more breakage to network connectivity than the negative impact of current NAPT practice in enterprise environments. At least table sizings can be met by expanding capacity. Expiring good/still-active "short lived" sessions cannot be fixed, except by not expiring them. A good example of an application this "short lived sessions" treatment may break is DNS, if for example, a domain's authoritative responses are taking >10 seconds to arrive, and the DNS cache on a subscriber's PC submits a query to each of the authoritative servers for that domain, the session will expire, before 1/3rd of the normal DNS timeout has passed -- since only one packet is sent to submit each DNS query, they all get considered "short-lived sessions". Now instead of DNS being slow (response after 10 seconds due to congestion of an overseas link or something), the domain being resolved is completely unreachable ---- the response arrives but was discarded because the session expired, so never seen, unless one of the servers can get a response in within that 10s window.... That's an ungraceful failure result. Expiring sessions early is likely to create a similar problem for P2P client applications -- they were waiting for a response, but will never get it. That "one packet session" concept is just a prediction; in reality, the client likely hopes for a response from many of those requests within a few minutes... If expiring these"short lived sessions" is undesired by the application and if adopted by SPs could probably result in significant changes by the developers to the client software applications observed. Changes to the applications (in reaction to SP NAT) could be expected to effect that peak result of SP NAT, negating portions of state table reductions obtained temporarily through shortening expiration periods. Means that new apps designed for use with such services would probably have to re-transmit much earlier, or flood no-op UDP, TCP packets in order to keep sessions open, in order to provide the user a reasonable experience.. sending additional packets to 'keep sessions alive' on the NAT device consumes more time on the wire (bandwidth), negates and might eventually exceed part of the SP's advantage of early expiration, if the expire is short enough -- -J From mohacsi at niif.hu Tue Apr 20 02:37:52 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Tue, 20 Apr 2010 09:37:52 +0200 (CEST) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCCBB08.5040206@consolejunkie.net> References: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBE891.4010206@bogus.com> <20100419143118.GA77881@ussenterprise.ufp.org> <4BCCBB08.5040206@consolejunkie.net> Message-ID: On Mon, 19 Apr 2010, Leen Besselink wrote: >> > > I actually think the razor thin margins make it less likely. > > If I'm not mistaken, one of the reasons firmware updates are not > available from a number of vendors/products, is because the small > boxes don't have enough ROM and/or RAM. > > The ROM is to small to hold an extra stack (or other features) and/or > the RAM is to small to handle the connection tracking for the larger > addresses. Because people want a stateful firewall, right ? In a very low end devices maybe. Mid range devices there is enough flash and RAM. I have been using openwrt on various devices (asus, dlink, lynksys) with ipv6 for more than 3 years. Best Regards, Janos Mohacsi From nanog at maunier.org Tue Apr 20 02:54:00 2010 From: nanog at maunier.org (Pierre-Yves Maunier) Date: Tue, 20 Apr 2010 09:54:00 +0200 Subject: Juniper firewalls - SSG or SRX In-Reply-To: References: <95099184-EE87-4191-9EF1-9EE52E6A5738@delong.com> Message-ID: I prefer Junos as screenOS except for one thing : HA is a hell to configure with Junos whereas it's really easy to do it with screenOS, at least last time I tried a couple of months ago. Anyway, ScreenOS cli really sucks compared to JunOS cli. Pierre-Yves 2010/4/20 seph > I'm with Owen. I have nothing good to say about ScreenOS. In contrast > JunOS has been great. > > seph > > Owen DeLong writes: > > > Much.. Go SRX over SSG every time. For anything that doesn't have an > > SRX analog, consider the J-series. > > > > SRX/J-Series == JunOS == Good. > > SSG Series == ScreenOS == @)#$*#@)$(*!)(@$!@$ > > > > Just my $0.02 having dealt extensively with both environments over the > > years. > > > > Owen > > > > On Apr 19, 2010, at 5:32 PM, Jeffrey Negro wrote: > > > >> Has anyone on Nanog had any hands on experience with the lower end of > the > >> new SRX series Junipers? We're looking to purchase two new firewalls, > and > >> I'm debating going with SSG series or to make the jump to the SRX line. > Any > >> input, especially about the learning curve jumping from ScreenOS to > JunOS > >> would be greatly appreciated. Thank you in advance. > >> > >> Jeffrey > > From jeff.richmond at gmail.com Tue Apr 20 03:10:10 2010 From: jeff.richmond at gmail.com (Jeff Richmond) Date: Tue, 20 Apr 2010 01:10:10 -0700 Subject: Juniper firewalls - SSG or SRX In-Reply-To: References: <95099184-EE87-4191-9EF1-9EE52E6A5738@delong.com> Message-ID: Count me in as well. I ditched my personal Netscreens and replaced with SRXs and we have done so as well at my day job. Other than a few quirky things, they are very nice. V6 support is still somewhat limited though, but I am using an SRX210H with ADSL2 PIM as my main router at home and it has been absolutely solid. Using it for both V4 (flow) and V6 (packet) routing, as well as doing a bunch of other things. It replaced my older NS5GT and SSG5. Configuration is so much easier now too. I almost forgot the pain of screenos. Ok, maybe not... -Jeff On Apr 19, 2010, at 9:39 PM, seph wrote: > I'm with Owen. I have nothing good to say about ScreenOS. In contrast > JunOS has been great. > > seph > > Owen DeLong writes: > >> Much.. Go SRX over SSG every time. For anything that doesn't have an >> SRX analog, consider the J-series. >> >> SRX/J-Series == JunOS == Good. >> SSG Series == ScreenOS == @)#$*#@)$(*!)(@$!@$ >> >> Just my $0.02 having dealt extensively with both environments over the >> years. >> >> Owen >> >> On Apr 19, 2010, at 5:32 PM, Jeffrey Negro wrote: >> >>> Has anyone on Nanog had any hands on experience with the lower end of the >>> new SRX series Junipers? We're looking to purchase two new firewalls, and >>> I'm debating going with SSG series or to make the jump to the SRX line. Any >>> input, especially about the learning curve jumping from ScreenOS to JunOS >>> would be greatly appreciated. Thank you in advance. >>> >>> Jeffrey > From cian.brennan at redbrick.dcu.ie Tue Apr 20 03:11:29 2010 From: cian.brennan at redbrick.dcu.ie (Cian Brennan) Date: Tue, 20 Apr 2010 09:11:29 +0100 Subject: Juniper firewalls - SSG or SRX In-Reply-To: References: Message-ID: <20100420081129.GA11809@minerva.redbrick.dcu.ie> On Mon, Apr 19, 2010 at 08:32:47PM -0400, Jeffrey Negro wrote: > Has anyone on Nanog had any hands on experience with the lower end of the > new SRX series Junipers? We're looking to purchase two new firewalls, and > I'm debating going with SSG series or to make the jump to the SRX line. Any > input, especially about the learning curve jumping from ScreenOS to JunOS > would be greatly appreciated. Thank you in advance. > Depends. SRXes are (in my experience) still quite a bit away from stable. We've had far more crashes than I'd like with them, without doing anything particularly strange. SSGs on the other hand are a horrible pain to admin, but (again, ime) seem stable as a rock. I assume SRXes will get betters given time, so the question is can you afford the instability for the moment? > Jeffrey > -- -- From snar at snar.spb.ru Tue Apr 20 03:53:04 2010 From: snar at snar.spb.ru (Alexandre Snarskii) Date: Tue, 20 Apr 2010 12:53:04 +0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <29025843.127.1271635699337.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <20100420085304.GA80522@snar.spb.ru> On Mon, Apr 19, 2010 at 06:56:43AM +0200, Mikael Abrahamsson wrote: > On Mon, 19 Apr 2010, Franck Martin wrote: > > >Anybody has better projections? What's the plan? > > My guess is that end user access will be more and more NAT444:ed (CGN) > while at the same time end users will get more and more IPv6 access (of > all types), and over a period of time more and more of the p2p traffic > (VoIP, file transfers etc) will move to IPv6 because it'll stop working > over IPv4. When enough users have IPv6 access the server-based content > will be made reachable over v6 as well. > > The transition will take at least 5 years, I guess in 2015 we'll be > perhaps halfway there. I suppose we will be here before 2015. We have at least one segment where IPv6 CPE is mandated by network access providers - that's cellular networks. So, adding "Verizon mandates IPv6 for LTE phones"[1] and "Verizon expects to commercially launch its LTE 4G network in up to 30 markets in 2010"[2] I can suggest that there will be significant increase of IPv6-enabled users in 2010-2011. May be this increase will be even significant enough to push content providers to dual-stack too... [1]: http://www.circleid.com/posts/20090609_verizon_mandates_ipv6_support_for_next_gen_cell_phones/ [2]: http://www.wirelessweek.com/News-Verizon-LTE-Data-Calls-081709.aspx From martin.rushworth at sohonet.co.uk Tue Apr 20 04:02:54 2010 From: martin.rushworth at sohonet.co.uk (Martin Rushworth) Date: Tue, 20 Apr 2010 10:02:54 +0100 Subject: Earthlink Email Issues with new ARIN range In-Reply-To: <4BCCB973.2060500@rollernet.us> References: <0900C6A3-C4FE-470D-B78D-7766C25F2001@sohonet.co.uk> <4BCCB973.2060500@rollernet.us> Message-ID: <99875B99-BDA1-4C08-9162-CD2CE9BA3224@sohonet.co.uk> no, but I will give it a go now, thanks for the suggestion. Martin On 19 Apr 2010, at 21:13, Seth Mattinen wrote: > On 4/19/2010 04:09, Martin Rushworth wrote: >> Hi, >> >> can someone that handles Earthlink blacklist/zombie settings please contact me off-list? >> >> we have a recently allocated ARIN /20 range, and all our clients allocated out of this are having issues emailing earthlink email accounts, our other ARIN ranges are fine. No luck through any other channels. >> > > > Have you tried asking mailop or spam-l ? > > ~Seth > From fw at deneb.enyo.de Tue Apr 20 05:27:54 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 20 Apr 2010 12:27:54 +0200 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCCD328.1030907@bryanfields.net> (Bryan Fields's message of "Mon, 19 Apr 2010 18:03:20 -0400") References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC9157.9040507@bryanfields.net> <20100419180719.GB97473@ussenterprise.ufp.org> <4BCCD328.1030907@bryanfields.net> Message-ID: <87d3xubeqd.fsf@mid.deneb.enyo.de> * Bryan Fields: > Yes, but I was showing what a great DDOS attack method it would be > too ;) The beauty of flow-based forwarding (with or without NAT) is that several types of denial-of-service attacks tend to hurt close to the packet sources, and not just close to the victim. As far as the whole system is concerned, this is a very, very good thing. From owen at delong.com Tue Apr 20 06:18:11 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 20 Apr 2010 04:18:11 -0700 Subject: Juniper firewalls - SSG or SRX In-Reply-To: <20100420081129.GA11809@minerva.redbrick.dcu.ie> References: <20100420081129.GA11809@minerva.redbrick.dcu.ie> Message-ID: <81231BA3-AB5C-4ADF-83C8-DAC7BB097463@delong.com> On Apr 20, 2010, at 1:11 AM, Cian Brennan wrote: > On Mon, Apr 19, 2010 at 08:32:47PM -0400, Jeffrey Negro wrote: >> Has anyone on Nanog had any hands on experience with the lower end of the >> new SRX series Junipers? We're looking to purchase two new firewalls, and >> I'm debating going with SSG series or to make the jump to the SRX line. Any >> input, especially about the learning curve jumping from ScreenOS to JunOS >> would be greatly appreciated. Thank you in advance. >> > Depends. SRXes are (in my experience) still quite a bit away from stable. We've > had far more crashes than I'd like with them, without doing anything > particularly strange. SSGs on the other hand are a horrible pain to admin, but > (again, ime) seem stable as a rock. I assume SRXes will get betters given time, > so the question is can you afford the instability for the moment? > Interesting. My SRXes have been rock solid since upgrading to 10.0R1.8. Owen From ras at e-gerbil.net Tue Apr 20 07:01:31 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Tue, 20 Apr 2010 07:01:31 -0500 Subject: Juniper firewalls - SSG or SRX In-Reply-To: <81231BA3-AB5C-4ADF-83C8-DAC7BB097463@delong.com> References: <20100420081129.GA11809@minerva.redbrick.dcu.ie> <81231BA3-AB5C-4ADF-83C8-DAC7BB097463@delong.com> Message-ID: <20100420120131.GX1261@gerbil.cluepon.net> On Tue, Apr 20, 2010 at 04:18:11AM -0700, Owen DeLong wrote: > > Interesting. My SRXes have been rock solid since upgrading to > 10.0R1.8. Not so much here. My basement SRX210 starts dropping bgp sessions over an IPSEC tunnel every 30 secs or so after around 1-1.5 days of uptime, and won't stop until you restart rpd (which buys you another day or so of functioning bgp). And about 1 out of every 4 times you do restart rpd, dhcpd will spin at 100% cpu until you restart that too. Even 10.1S1.3 doesn't help these issues. It's a nice box in theory, and it has lots of potential, but lots and lots of unresolved bugs too. I knew things were off to a bad start when I tried to downgrade from the 10.0R1 that shipped with the box to 9.6 after my first round of issues, and it crashed in the middle of the installer, wiping the config in the process and requiring a tftp boot of new code to recover. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From bmanning at vacation.karoshi.com Tue Apr 20 07:12:16 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 20 Apr 2010 12:12:16 +0000 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <201004200225.o3K2OwVi070153@drugs.dv.isc.org> References: <201004200022.o3K0M2Ba007459@aurora.sol.net> <201004200225.o3K2OwVi070153@drugs.dv.isc.org> Message-ID: <20100420121216.GD15321@vacation.karoshi.com.> On Tue, Apr 20, 2010 at 12:24:57PM +1000, Mark Andrews wrote: > > In message <201004200022.o3K0M2Ba007459 at aurora.sol.net>, Joe Greco writes: > > > That'd be easy if you were just starting up an ISP. What do you do with > > > your existing customer base? If their current service includes a > > > dynamic public IPv4 address, you can't gracefully take it away, without > > > likey violating services T&Cs, government telco regulations etc. So > > > you'll have to go through a formal process of getting agreement with > > > customers to take them away. > > > > I haven't seen any such documents or regulations. > > People purchaced the service on the understanding that they would > get a Internet address. A address behind a NAT is not a Internet > address, it's a *shared* Internet address which is a very different > thing. whats an "Internet" address? and are you sure thats part of the service offering? > Mark Andrews, ISC --bill From patrick.sumby at sohonet.co.uk Tue Apr 20 07:14:03 2010 From: patrick.sumby at sohonet.co.uk (Patrick Sumby) Date: Tue, 20 Apr 2010 13:14:03 +0100 Subject: PeeringDB contact Message-ID: <4BCD9A8B.4020100@sohonet.co.uk> Hi, Could someone from PeeringDB contact me off-list please. Or if anyone has any contact details other than the support at peeringdb.com address that would be much appreciated. Thanks Patrick From bmanning at vacation.karoshi.com Tue Apr 20 07:16:46 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 20 Apr 2010 12:16:46 +0000 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <201004200358.o3K3wDQk071509@drugs.dv.isc.org> References: <201004200022.o3K0M2Ba007459@aurora.sol.net> <201004200225.o3K2OwVi070153@drugs.dv.isc.org> <4BCD14EF.8090204@zill.net> <201004200320.o3K3KB4s071149@drugs.dv.isc.org> <4BCD203E.3050302@zill.net> <201004200358.o3K3wDQk071509@drugs.dv.isc.org> Message-ID: <20100420121646.GE15321@vacation.karoshi.com.> On Tue, Apr 20, 2010 at 01:58:13PM +1000, Mark Andrews wrote: > > > You are charmingly naive about how "the law" actually works in the USA - > > that is IMHO. > > Yes, things vary around the world. You failed to state "In the > USA". There is plenty of case law in Australia about companies > attempting to arbitarially change terms and conditions to the > detriment of the consumer and being made to reverse the changes. this is the North American Network Operators Group. Not the Australian Network Operators Group. > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia --bill From martin.rushworth at sohonet.co.uk Tue Apr 20 07:28:11 2010 From: martin.rushworth at sohonet.co.uk (Martin Rushworth) Date: Tue, 20 Apr 2010 13:28:11 +0100 Subject: Earthlink Email Issues with new ARIN range In-Reply-To: <4BCCB973.2060500@rollernet.us> References: <0900C6A3-C4FE-470D-B78D-7766C25F2001@sohonet.co.uk> <4BCCB973.2060500@rollernet.us> Message-ID: <6F91DEB8-EB17-4556-B55E-38CEF0FFD5F5@sohonet.co.uk> mailop was the place to ask, thanks again. > Have you tried asking mailop or spam-l ? > > ~Seth > From jeff.richmond at gmail.com Tue Apr 20 07:36:32 2010 From: jeff.richmond at gmail.com (Jeff Richmond) Date: Tue, 20 Apr 2010 05:36:32 -0700 Subject: Juniper firewalls - SSG or SRX In-Reply-To: <20100420120131.GX1261@gerbil.cluepon.net> References: <20100420081129.GA11809@minerva.redbrick.dcu.ie> <81231BA3-AB5C-4ADF-83C8-DAC7BB097463@delong.com> <20100420120131.GX1261@gerbil.cluepon.net> Message-ID: I will admit I have the same issue with a both my BGP sessions over GRE as well, which is really annoying, but I only use this for remote hopping over to my other lab, not for anything I would ever do in production so I haven't bothered opening a case on it yet. Glad to know I am not the only one though. However, that said, everything else I am doing has been rock solid, so no complaints there. -Jeff On Apr 20, 2010, at 5:01 AM, Richard A Steenbergen wrote: > On Tue, Apr 20, 2010 at 04:18:11AM -0700, Owen DeLong wrote: >> >> Interesting. My SRXes have been rock solid since upgrading to >> 10.0R1.8. > > Not so much here. My basement SRX210 starts dropping bgp sessions over > an IPSEC tunnel every 30 secs or so after around 1-1.5 days of uptime, > and won't stop until you restart rpd (which buys you another day or so > of functioning bgp). And about 1 out of every 4 times you do restart > rpd, dhcpd will spin at 100% cpu until you restart that too. Even > 10.1S1.3 doesn't help these issues. It's a nice box in theory, and it > has lots of potential, but lots and lots of unresolved bugs too. I knew > things were off to a bad start when I tried to downgrade from the 10.0R1 > that shipped with the box to 9.6 after my first round of issues, and it > crashed in the middle of the installer, wiping the config in the process > and requiring a tftp boot of new code to recover. :) > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > From jgreco at ns.sol.net Tue Apr 20 07:40:17 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 20 Apr 2010 07:40:17 -0500 (CDT) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <201004200225.o3K2OwVi070153@drugs.dv.isc.org> from "Mark Andrews" at Apr 20, 2010 12:24:57 PM Message-ID: <201004201240.o3KCeHl4074118@aurora.sol.net> > In message <201004200022.o3K0M2Ba007459 at aurora.sol.net>, Joe Greco writes: > > > That'd be easy if you were just starting up an ISP. What do you do with > > > your existing customer base? If their current service includes a > > > dynamic public IPv4 address, you can't gracefully take it away, without > > > likey violating services T&Cs, government telco regulations etc. So > > > you'll have to go through a formal process of getting agreement with > > > customers to take them away. > > > > I haven't seen any such documents or regulations. > > People purchaced the service on the understanding that they would > get a Internet address. A address behind a NAT is not a Internet > address, it's a *shared* Internet address which is a very different > thing. People purchase mobile Internet service and get placed behind carrier NAT. People get free Internet at hotels and are almost always behind a NAT. The terminology war is lost. > > Many/most people are _already_ behind a NAT gateway. > > They are behind NAT44 which they deployed themselves and control > the configuration of themselves. They can direct incoming traffic > as they see fit. They are NOT restricted to UDP and TCP. > > NAT444 is a different kettle of fish. There are lots of things > that you do with a NAT44 that you can't do with a NAT444. > > If all you do is browse the web and read email then you won't see > the much of a difference. If you do anything more complicated than > making outgoing queries you will see the difference. You *might* see the difference. You might not, too. And hey, just so we're clear here, I would *agree* that Internet access ought to mean an actual IP address with as little filtering, etc., as reasonable... but we're exploring what happens at exhaustion here. So I'm not interested in arguing this point; the fact of the matter is that we WILL hit exhaustion, and it's going to be a hell of an operational issue the day your subscribers cannot get an IP from the DHCP server because they're all allocated and in use. I'm as offended as anyone by what is often passed off as "Internet" access, but it's completely devoid of value to argue what you seem to be saying: the fact that it is so _today_ does not mean that it /has/ to be so _tomorrow._ All that's down that path is exhaustion with no solutions. ... 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 marka at isc.org Tue Apr 20 07:45:02 2010 From: marka at isc.org (Mark Andrews) Date: Tue, 20 Apr 2010 22:45:02 +1000 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: Your message of "Tue, 20 Apr 2010 12:16:46 GMT." <20100420121646.GE15321@vacation.karoshi.com.> References: <201004200022.o3K0M2Ba007459@aurora.sol.net> <201004200225.o3K2OwVi070153@drugs.dv.isc.org> <4BCD14EF.8090204@zill.net> <201004200320.o3K3KB4s071149@drugs.dv.isc.org> <4BCD203E.3050302@zill.net> <201004200358.o3K3wDQk071509@drugs.dv.isc.org> <20100420121646.GE15321@vacation.karoshi.com.> Message-ID: <201004201245.o3KCj2mm074967@drugs.dv.isc.org> In message <20100420121646.GE15321 at vacation.karoshi.com.>, bmanning at vacation.ka roshi.com writes: > On Tue, Apr 20, 2010 at 01:58:13PM +1000, Mark Andrews wrote: > > > > > You are charmingly naive about how "the law" actually works in the USA - > > > that is IMHO. > > > > Yes, things vary around the world. You failed to state "In the > > USA". There is plenty of case law in Australia about companies > > attempting to arbitarially change terms and conditions to the > > detriment of the consumer and being made to reverse the changes. > > > this is the North American Network Operators Group. > Not the Australian Network Operators Group. And last I heard NA != USA. So have you decided to annex the rest of NA and bring it under US law. :-) > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > --bill -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From arnold at nipper.de Tue Apr 20 08:00:16 2010 From: arnold at nipper.de (Arnold Nipper) Date: Tue, 20 Apr 2010 15:00:16 +0200 Subject: PeeringDB contact In-Reply-To: <4BCD9A8B.4020100@sohonet.co.uk> References: <4BCD9A8B.4020100@sohonet.co.uk> Message-ID: <4BCDA560.8050200@nipper.de> Hi Patrick, On 20.04.2010 14:14 Patrick Sumby wrote > Could someone from PeeringDB contact me off-list please. Or if anyone > has any contact details other than the support at peeringdb.com address > that would be much appreciated. > does support at peeringdb.com not work for you? Best regards, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From patrick.sumby at sohonet.co.uk Tue Apr 20 08:04:00 2010 From: patrick.sumby at sohonet.co.uk (Patrick Sumby) Date: Tue, 20 Apr 2010 14:04:00 +0100 Subject: PeeringDB contact In-Reply-To: <4BCDA560.8050200@nipper.de> References: <4BCD9A8B.4020100@sohonet.co.uk> <4BCDA560.8050200@nipper.de> Message-ID: <4BCDA640.3070706@sohonet.co.uk> Hi Arnold, Sadly not, I've sent a number of emails to support at peeringdb.com and had no reply :( which is why I'm here! Cheers Patrick Arnold Nipper wrote: > Hi Patrick, > > On 20.04.2010 14:14 Patrick Sumby wrote > >> Could someone from PeeringDB contact me off-list please. Or if anyone >> has any contact details other than the support at peeringdb.com address >> that would be much appreciated. >> > > does support at peeringdb.com not work for you? > > > Best regards, > Arnold From owen at delong.com Tue Apr 20 08:12:58 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 20 Apr 2010 06:12:58 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <201004201240.o3KCeHl4074118@aurora.sol.net> References: <201004201240.o3KCeHl4074118@aurora.sol.net> Message-ID: <019421AD-EAD9-4C62-A2B4-97F1EA8DA42E@delong.com> On Apr 20, 2010, at 5:40 AM, Joe Greco wrote: >> In message <201004200022.o3K0M2Ba007459 at aurora.sol.net>, Joe Greco writes: >>>> That'd be easy if you were just starting up an ISP. What do you do with >>>> your existing customer base? If their current service includes a >>>> dynamic public IPv4 address, you can't gracefully take it away, without >>>> likey violating services T&Cs, government telco regulations etc. So >>>> you'll have to go through a formal process of getting agreement with >>>> customers to take them away. >>> >>> I haven't seen any such documents or regulations. >> >> People purchaced the service on the understanding that they would >> get a Internet address. A address behind a NAT is not a Internet >> address, it's a *shared* Internet address which is a very different >> thing. > > People purchase mobile Internet service and get placed behind > carrier NAT. People get free Internet at hotels and are almost > always behind a NAT. The terminology war is lost. > Most hotels I have stayed in recently have a "Upgrade to public IP" button which I routinely use. I have never encountered an additional charge for that public IP. >>> Many/most people are _already_ behind a NAT gateway. >> >> They are behind NAT44 which they deployed themselves and control >> the configuration of themselves. They can direct incoming traffic >> as they see fit. They are NOT restricted to UDP and TCP. >> >> NAT444 is a different kettle of fish. There are lots of things >> that you do with a NAT44 that you can't do with a NAT444. >> >> If all you do is browse the web and read email then you won't see >> the much of a difference. If you do anything more complicated than >> making outgoing queries you will see the difference. > > You *might* see the difference. You might not, too. > > And hey, just so we're clear here, I would *agree* that Internet access > ought to mean an actual IP address with as little filtering, etc., as > reasonable... but we're exploring what happens at exhaustion here. So > I'm not interested in arguing this point; the fact of the matter is that > we WILL hit exhaustion, and it's going to be a hell of an operational > issue the day your subscribers cannot get an IP from the DHCP server > because they're all allocated and in use. > The good news is that in IPv6, it probably will mean that again. Owen From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Apr 20 08:23:14 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Tue, 20 Apr 2010 22:53:14 +0930 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <6E6E5B81-36CC-43AA-B8C7-C4C364E9FEC6@delong.com> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC9157.9040507@bryanfields.net> <20100419180719.GB97473@ussenterprise.ufp.org> <87zl0zgkk5.fsf@mid.deneb.enyo.de> <6E6E5B81-36CC-43AA-B8C7-C4C364E9FEC6@delong.com> Message-ID: <20100420225314.7dcd4da4@opy.nosense.org> On Mon, 19 Apr 2010 19:57:04 -0700 Owen DeLong wrote: > > On Apr 19, 2010, at 3:10 PM, Florian Weimer wrote: > > > * Leo Bicknell: > > > >> I know of no platform that does hardware NAT. Rather, NAT is a CPU > >> function. While this is another interesting scaling issue, it means > >> this data is not going in the FIB (hardware forwarding database), > >> but rather is stored in a CPU accessible database. > > > > If you NAT all traffic, the NAT database needs the same level of > > efficiency as the FIB. > > > > You could probably even join the two (you should check that the > > corresponding RIB entry is still current, but that can probably be > > forced to be cheap). > > More likely, if you're going to do this (and I would not wish it on my > worst competitors), you would want to push smaller NATs out towards > the customer aggregation point where you can get away with cheaper > commodity hardware that can later be repurposed. Yes, more boxes, > but, much less expensive and keeps the router doing what routers do > best rather than NATing everything on the router. > Pushing functions as closer to the edge of the network usually makes them easier to scale and more robust and resilient to failure. There might be more chance of failure, but there is less consequence. Specific to CGN/LSN, I think the best idea is that if we can't have a 1 to 1 relationship between subscriber and global IPv4 address (in the ISP network that is), the next best thing is to try to keep as close to that as possible e.g. if you share a single IPv4 address between two customers, you've halved your IPv4 addressing requirements / doubled your growth opportunity, and allowed for e.g. 32K TCP or UDP ports for each of those customers. Regards, Mark. From rs at seastrom.com Tue Apr 20 08:25:01 2010 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 20 Apr 2010 09:25:01 -0400 Subject: Postel Network Operator's Scholarship 2010 Message-ID: <86zl0yfe8i.fsf@seastrom.com> [Sent to multiple lists; apologies for the duplicates] On behalf of the North American Network Operators' Group (NANOG) and the American Registry for Internet Numbers (ARIN), I would like to take this opportunity to draw your attention to the 2010 Postel Network Operator's Scholarship. The Postel Network Operator's Scholarship targets personnel from developing countries who are actively involved in Internet development, in any of the following roles: * Engineers (Network Builders) * Operational and Infrastructure Support Personnel * Educators and Trainers This is not a postgraduate fellowship or academic scholarship. Individuals may nominate themselves for the Scholarship via email or online form. The Scholarship will be awarded annually to a recipient selected by a committee comprising representatives from the NANOG Steering Committee and the ARIN Board of Trustees. The selection committee will "whimsically" select the annual recipient exclusively in response to the question: "What Would Jon Do?" if he were asked to select a recipient. The successful applicant will be provided with transportation to and from the NANOG and ARIN joint meeting 3-8 October 2010, in Atlanta, Georgia, USA, and a reasonable (local host standard) allowance for food and accommodation. In addition, all fees for participation in both meetings' events will be waived. The final grant size is determined according to final costs and available funding. The chosen recipient will be advised at least 2 months prior to the fall meeting date. Applications from qualified individuals are now being accepted. The deadline for application is 1 June 2010, and the awardees will be informed by 3 July 2010. Please read full information about the scholarship at: http://www.nanog.org/scholarships/postel.php To apply, please complete the web-based application form that is linked from that page. Optionally, you may submit your application in PLAIN ASCII in the BODY of the message, not as an attachment nor as a Word document, PDF, or any other form, to PostelNOS at nanog.org. Please be sure to include the following: * Full name and contact info * Your brief biography, including current and recent jobs held * A description of why you need and deserve this Scholarship to attend the NANOG and ARIN meetings * A description of how you plan to leverage your attendance at the meetings in your work * A brief abstract of a presentation you would give at the NANOG and/or ARIN meetings, if selected as a Scholarship winner Kind regards, -Rob Seastrom, on behalf of the Postel Scholarship Selection Committee From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Apr 20 08:32:26 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Tue, 20 Apr 2010 23:02:26 +0930 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100420121646.GE15321@vacation.karoshi.com.> References: <201004200022.o3K0M2Ba007459@aurora.sol.net> <201004200225.o3K2OwVi070153@drugs.dv.isc.org> <4BCD14EF.8090204@zill.net> <201004200320.o3K3KB4s071149@drugs.dv.isc.org> <4BCD203E.3050302@zill.net> <201004200358.o3K3wDQk071509@drugs.dv.isc.org> <20100420121646.GE15321@vacation.karoshi.com.> Message-ID: <20100420230226.18111ea5@opy.nosense.org> On Tue, 20 Apr 2010 12:16:46 +0000 bmanning at vacation.karoshi.com wrote: > On Tue, Apr 20, 2010 at 01:58:13PM +1000, Mark Andrews wrote: > > > > > You are charmingly naive about how "the law" actually works in the USA - > > > that is IMHO. > > > > Yes, things vary around the world. You failed to state "In the > > USA". There is plenty of case law in Australia about companies > > attempting to arbitarially change terms and conditions to the > > detriment of the consumer and being made to reverse the changes. > > > this is the North American Network Operators Group. > Not the Australian Network Operators Group. > So when did NA stop being the most litigious society on the planet? I could see a class action suit over not getting proper big "I" Internet access like you used to. You guys sue over hot coffee (of both kinds)! > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > --bill > From marka at isc.org Tue Apr 20 08:56:54 2010 From: marka at isc.org (Mark Andrews) Date: Tue, 20 Apr 2010 23:56:54 +1000 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: Your message of "Tue, 20 Apr 2010 07:40:17 EST." <201004201240.o3KCeHl4074118@aurora.sol.net> References: <201004201240.o3KCeHl4074118@aurora.sol.net> Message-ID: <201004201356.o3KDusSa075588@drugs.dv.isc.org> In message <201004201240.o3KCeHl4074118 at aurora.sol.net>, Joe Greco writes: > > In message <201004200022.o3K0M2Ba007459 at aurora.sol.net>, Joe Greco writes: > > > > That'd be easy if you were just starting up an ISP. What do you do with > > > > your existing customer base? If their current service includes a > > > > dynamic public IPv4 address, you can't gracefully take it away, without > > > > likey violating services T&Cs, government telco regulations etc. So > > > > you'll have to go through a formal process of getting agreement with > > > > customers to take them away. > > > > > > I haven't seen any such documents or regulations. > > > > People purchaced the service on the understanding that they would > > get a Internet address. A address behind a NAT is not a Internet > > address, it's a *shared* Internet address which is a very different > > thing. > > People purchase mobile Internet service and get placed behind > carrier NAT. People get free Internet at hotels and are almost > always behind a NAT. The terminology war is lost. But regardless of what it is called people usually know what they signed up for and when what has worked for the 5-6 years suddenly breaks ... > > > Many/most people are _already_ behind a NAT gateway. > > > > They are behind NAT44 which they deployed themselves and control > > the configuration of themselves. They can direct incoming traffic > > as they see fit. They are NOT restricted to UDP and TCP. > > > > NAT444 is a different kettle of fish. There are lots of things > > that you do with a NAT44 that you can't do with a NAT444. > > > > If all you do is browse the web and read email then you won't see > > the much of a difference. If you do anything more complicated than > > making outgoing queries you will see the difference. > > You *might* see the difference. You might not, too. > > And hey, just so we're clear here, I would *agree* that Internet access > ought to mean an actual IP address with as little filtering, etc., as > reasonable... but we're exploring what happens at exhaustion here. So > I'm not interested in arguing this point; the fact of the matter is that > we WILL hit exhaustion, and it's going to be a hell of an operational > issue the day your subscribers cannot get an IP from the DHCP server > because they're all allocated and in use. > > I'm as offended as anyone by what is often passed off as "Internet" > access, but it's completely devoid of value to argue what you seem to > be saying: the fact that it is so _today_ does not mean that it /has/ > to be so _tomorrow._ All that's down that path is exhaustion with no > solutions. Hopefully being on the Internet, for the home user, will mean you have IPv6 connectivity and public address space handed out using PD in 3-5 years time. That Google, Yahoo etc. have turned on IPv6 to everyone. DS-lite or some other distributed NAT44 technology is being used to for those machines that don't support IPv6 or to reach content providers that have not yet enabled IPv6. If the ISP decides to go with NAT444 then the will be control pages that get you a real IPv4 address the same as many hotels have today as there will be customers that need the functionality. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jbates at brightok.net Tue Apr 20 08:59:10 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 20 Apr 2010 08:59:10 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <201004200012.o3K0CDUL007165@aurora.sol.net> References: <201004200012.o3K0CDUL007165@aurora.sol.net> Message-ID: <4BCDB32E.3050900@brightok.net> Joe Greco wrote: > > And what'll you do for your customers when you have no more IPv4 > addresses? > IPv6, request IPv4 from my transit providers, buy a small ISP that has IPv4 address, consolidate my own IP addressing much tighter, butchering the clean allocations and routing table. Quit selling new IPv4 services. I will NOT do NAT over a customer base, ever, ever, ever, ever again. Did that when we were small. The hardware upgrades required to even hope to do that would make it better to just quit accepting new customers. Jack From Valdis.Kletnieks at vt.edu Tue Apr 20 09:04:03 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 20 Apr 2010 10:04:03 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: Your message of "Tue, 20 Apr 2010 23:02:26 +0930." <20100420230226.18111ea5@opy.nosense.org> References: <201004200022.o3K0M2Ba007459@aurora.sol.net> <201004200225.o3K2OwVi070153@drugs.dv.isc.org> <4BCD14EF.8090204@zill.net> <201004200320.o3K3KB4s071149@drugs.dv.isc.org> <4BCD203E.3050302@zill.net> <201004200358.o3K3wDQk071509@drugs.dv.isc.org> <20100420121646.GE15321@vacation.karoshi.com> <20100420230226.18111ea5@opy.nosense.org> Message-ID: <6275.1271772243@localhost> On Tue, 20 Apr 2010 23:02:26 +0930, Mark Smith said: > access like you used to. You guys sue over hot coffee (of both > kinds)! Well.. yeah. When it causes 3rd degree burns, you start thinking about suing. http://www.lectlaw.com/files/cur78.htm "McDonalds also argued that consumers know coffee is hot and that its customers want it that way. The company admitted its customers were unaware that they could suffer thirddegree burns from the coffee...." Read that and tell me if you *still* think it's a totally frivolous lawsuit. (Hot water is *dangerous* - in many cases even more so than an open flame. If you stick your hand/arm in a flame, you can *usually* pull it out before your shirt sleeve catches fire, and you only take damage the time your arm is actually in the flame. You get a hot water spill on you, that sleeve will hold the hot water against your skin, and the burn becomes a gift that keeps on giving...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jmaimon at ttec.com Tue Apr 20 09:38:45 2010 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 20 Apr 2010 10:38:45 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100420225314.7dcd4da4@opy.nosense.org> References: <6760231.131.1271637891968.JavaMail.franck@franck-martins-macbook-pro.local> <4BCBB1A1.1020805@zill.net> <2ECD9372-1E81-40D1-9D2C-7CFF6EA83F08@ianai.net> <87hbn7k90f.fsf@mid.deneb.enyo.de> <17384977-AF91-47E6-9DF6-33E77620A15E@ianai.net> <87zl0z8sb2.fsf@mid.deneb.enyo.de> <476BE53B-722B-4965-B25F-A2110D7B9CAE@delong.com> <4BCC6553.4060202@zill.net> <4BCC9157.9040507@bryanfields.net> <20100419180719.GB97473@ussenterprise.ufp.org> <87zl0zgkk5.fsf@mid.deneb.enyo.de> <6E6E5B81-36CC-43AA-B8C7-C4C364E9FEC6@delong.com> <20100420225314.7dcd4da4@opy.nosense.org> Message-ID: <4BCDBC75.7070601@ttec.com> Mark Smith wrote: > On Mon, 19 Apr 2010 19:57:04 -0700 > Owen DeLong wrote: > Pushing functions as closer to the edge of the network usually makes > them easier to scale and more robust and resilient to failure. > There might be more chance of failure, but there is less consequence. > > Specific to CGN/LSN, I think the best idea is that if we can't have > a 1 to 1 relationship between subscriber and global IPv4 address (in > the ISP network that is), the next best thing is to try to keep as > close to that as possible e.g. if you share a single IPv4 address > between two customers, you've halved your IPv4 addressing > requirements / doubled your growth opportunity, and allowed for e.g. > 32K TCP or UDP ports for each of those customers. > > Regards, > Mark. > > But if you free up large swaths you might actually be generating additional revenue opportunity instead of only growth opportunity. From arnold at nipper.de Tue Apr 20 09:42:40 2010 From: arnold at nipper.de (Arnold Nipper) Date: Tue, 20 Apr 2010 16:42:40 +0200 Subject: PeeringDB contact In-Reply-To: <4BCDA640.3070706@sohonet.co.uk> References: <4BCD9A8B.4020100@sohonet.co.uk> <4BCDA560.8050200@nipper.de> <4BCDA640.3070706@sohonet.co.uk> Message-ID: <4BCDBD60.3080806@nipper.de> Patrick (et al.) On 20.04.2010 15:04 Patrick Sumby wrote > Sadly not, I've sent a number of emails to support at peeringdb.com and had > no reply :( which is why I'm here! > if you run into the same problem pls feel free to contact anyone listed as peeringDB admin (see e.g. http://www.menog.net/sites/default/files/e-an-20100414-peeringdb.pdf for names) @Patrick: please provide some msg-id's to us. Best regards, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From bmanning at vacation.karoshi.com Tue Apr 20 09:43:28 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 20 Apr 2010 14:43:28 +0000 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <201004201245.o3KCj2mm074967@drugs.dv.isc.org> References: <201004200022.o3K0M2Ba007459@aurora.sol.net> <201004200225.o3K2OwVi070153@drugs.dv.isc.org> <4BCD14EF.8090204@zill.net> <201004200320.o3K3KB4s071149@drugs.dv.isc.org> <4BCD203E.3050302@zill.net> <201004200358.o3K3wDQk071509@drugs.dv.isc.org> <20100420121646.GE15321@vacation.karoshi.com.> <201004201245.o3KCj2mm074967@drugs.dv.isc.org> Message-ID: <20100420144328.GE17235@vacation.karoshi.com.> On Tue, Apr 20, 2010 at 10:45:02PM +1000, Mark Andrews wrote: > > In message <20100420121646.GE15321 at vacation.karoshi.com.>, bmanning at vacation.ka > roshi.com writes: > > On Tue, Apr 20, 2010 at 01:58:13PM +1000, Mark Andrews wrote: > > > > > > > You are charmingly naive about how "the law" actually works in the USA - > > > > that is IMHO. > > > > > > Yes, things vary around the world. You failed to state "In the > > > USA". There is plenty of case law in Australia about companies > > > attempting to arbitarially change terms and conditions to the > > > detriment of the consumer and being made to reverse the changes. > > > > > > this is the North American Network Operators Group. > > Not the Australian Network Operators Group. > > And last I heard NA != USA. So have you decided to annex the rest of > NA and bring it under US law. :-) nope - but we'll be glad to tell your PM that Australia is prepared to join the Union as the next five states and enjoy all the benefits of our enlighted government and laws. or would you prefer to be part of Canada? --bill From johnl at iecc.com Tue Apr 20 09:53:32 2010 From: johnl at iecc.com (John Levine) Date: 20 Apr 2010 14:53:32 -0000 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <201004201356.o3KDusSa075588@drugs.dv.isc.org> Message-ID: <20100420145332.58995.qmail@joyce.lan> >But regardless of what it is called people usually know what they >signed up for and when what has worked for the 5-6 years suddenly >breaks ... If a consumer ISP moved its customers from separate IPs to NAT, what do you think would break? I'm the guy who was behind a double NAT for several months without realizing it, and I can report that the only symptom I noticed was incoming call flakiness on one of my VoIP phones, and even that was easy to fix by decreasing the registration interval. The other VoIP phone worked fine in its default config. Other than the .01% of consumer customers who are mega multiplayer game weenies, what's not going to work? Actual experience as opposed to hypothetical hand waving would be preferable. I'm not saying that NAT is wonderful, but my experience, in which day to day stuff all works fine, is utterly different from the doom and disaster routinely predicted here. R's, John From simon.perreault at viagenie.ca Tue Apr 20 09:59:37 2010 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Tue, 20 Apr 2010 10:59:37 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100420145332.58995.qmail@joyce.lan> References: <20100420145332.58995.qmail@joyce.lan> Message-ID: <4BCDC159.4050003@viagenie.ca> On 2010-04-20 10:53, John Levine wrote: > Other than the .01% of consumer customers who are mega multiplayer > game weenies, what's not going to work? Actual experience as opposed > to hypothetical hand waving would be preferable. http://tools.ietf.org/html/draft-ford-shared-addressing-issues Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From jbates at brightok.net Tue Apr 20 09:57:36 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 20 Apr 2010 09:57:36 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100420145332.58995.qmail@joyce.lan> References: <20100420145332.58995.qmail@joyce.lan> Message-ID: <4BCDC0E0.1070209@brightok.net> John Levine wrote: > Other than the .01% of consumer customers who are mega multiplayer > game weenies, what's not going to work? Actual experience as opposed > to hypothetical hand waving would be preferable. > .01%? heh. NAT can break xbox, ps3, certain pc games, screw with various programs that dislike multiple connections from a single IP, and the crap load of vpn clients that appear on the network and do not support nat traversal (either doesn't support it, or big corp A refuses to enable it). When we were in our infancy, we had areas doing NAT. It was a support nightmare from hell, and in some cases, it just didn't work period. That doesn't even get into the load issues. Jack From owen at delong.com Tue Apr 20 10:13:52 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 20 Apr 2010 08:13:52 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100420145332.58995.qmail@joyce.lan> References: <20100420145332.58995.qmail@joyce.lan> Message-ID: <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> On Apr 20, 2010, at 7:53 AM, John Levine wrote: >> But regardless of what it is called people usually know what they >> signed up for and when what has worked for the 5-6 years suddenly >> breaks ... > > If a consumer ISP moved its customers from separate IPs to NAT, what > do you think would break? I'm the guy who was behind a double NAT for > several months without realizing it, and I can report that the only > symptom I noticed was incoming call flakiness on one of my VoIP > phones, and even that was easy to fix by decreasing the registration > interval. The other VoIP phone worked fine in its default config. > Did you use Yahoo IM, AIM, or Skype? Did you use any of those for Video Chat and/or to transfer files? Did you do any peer to peer filesharing? Did you play any MMOs? Did you run any services? > Other than the .01% of consumer customers who are mega multiplayer > game weenies, what's not going to work? Actual experience as opposed > to hypothetical hand waving would be preferable. > I hate to break it to you, but they are not 0.1%, they are more like 15%. When you add in the other things that break which I have outlined above, you start to approach 75%. I would argue that 75% is a significant and meaningful fraction of an ISPs customer base. > I'm not saying that NAT is wonderful, but my experience, in which day > to day stuff all works fine, is utterly different from the doom and > disaster routinely predicted here. > Perhaps your day to day is different from others. Perhaps people here generally think in terms of servicing all of their customers. Perhaps in many cases if just 1% of our customers are on the phone with our technical support department, we are losing money. YMMV. Owen From ken.gilmour at gmail.com Tue Apr 20 10:15:26 2010 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Tue, 20 Apr 2010 09:15:26 -0600 Subject: Juniper firewalls - SSG or SRX In-Reply-To: References: Message-ID: We are in the process of replacing some SSGs (and NSes) with SRXes. The biggest issues so far that we've faced are: 1. Although the devices can be used at the core you can't enable "multifunction" IDP (i.e. you can only enable the filters for HTTP or Fileserver etc, not all at the same time or the device will crash). 2. The config restore is limited to a small file (i don't know what that is yet). If you need to restore a big file from SCP or USB key it will fail, you have to convert the file into commands (a bit like ScreenOS or IPTables) and then paste them all into CLI which can get messy if you make a typo or do them in the wrong order. 3. In shell mode the CPU shows pflow using up over 1000% CPU, apparently this is just an aesthetics problem and it's not actually using up 1000% CPU (the GUI also shows this but this is also an aesthetics problem). The advantages are that the CLI has more middle ground between IOS and ScreenOS, for example: ScreenOS and JunOS: set interfaces Cisco interface JunOS edit interface set The BGP configuration is much more complicated, and in my short experience with JunOS, less feature rich than OpenBGPd from the OpenBSD crew (although the syntax is very similar). Regards, Ken On 19 April 2010 18:32, Jeffrey Negro wrote: > Has anyone on Nanog had any hands on experience with the lower end of the > new SRX series Junipers? We're looking to purchase two new firewalls, and > I'm debating going with SSG series or to make the jump to the SRX line. > Any > input, especially about the learning curve jumping from ScreenOS to JunOS > would be greatly appreciated. Thank you in advance. > > Jeffrey > From johnl at iecc.com Tue Apr 20 10:29:59 2010 From: johnl at iecc.com (John R. Levine) Date: 20 Apr 2010 11:29:59 -0400 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> Message-ID: > Did you use Yahoo IM, AIM, or Skype? Yes, yes, and yes. Works fine. > Did you use any of those for > Video Chat and/or to transfer files? Skype video chat, all the time, works fine. Don't remember about file transfer. > Did you do any peer to peer filesharing? Yeah, I got the latest Freebsd via bittorrent, and left it up overnight and observed from the stats that it served chunks of it back to other people. > Did you play any MMOs? No, I noted the game players. > Did you run any services? Of course not, it's consumer DSL. I run services on my server which is somewhere else and tunnel in via ssh which, of course, works fine through NAT. > When you add in the other things that break which I have outlined above, > you start to approach 75%. I would argue that 75% is a significant and > meaningful fraction of an ISPs customer base. The hypthetical network that your consumers would use appears to be very different from the actual one available to consumers around here. R's, John From ipv16.com at gmail.com Tue Apr 20 10:31:00 2010 From: ipv16.com at gmail.com (IPv16.com) Date: Tue, 20 Apr 2010 10:31:00 -0500 Subject: IPv4 Options now Deprecated - Header Length Always 5 (0101) - 160 Bits=32x5 Message-ID: IPv4 Options now Deprecated - Header Length Always 5 (0101) - 160 Bits=32x5 http://www.ietf.org/mail-archive/web/rrg/current/msg06481.html N at T box firmware updates ensure no IPv4 Options are sent Upstream. IPv4 TTL fields should now be 3+1+4 with the left-most 3 bits Deprecated (Re-Purposed) From morrowc.lists at gmail.com Tue Apr 20 10:43:16 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 20 Apr 2010 11:43:16 -0400 Subject: IPv4 Options now Deprecated - Header Length Always 5 (0101) - 160 Bits=32x5 In-Reply-To: References: Message-ID: On Tue, Apr 20, 2010 at 11:31 AM, IPv16.com wrote: > IPv4 Options now Deprecated - Header Length Always 5 (0101) - 160 Bits=32x5 that's not what the message says at all, thanks for playing, pls don't spray the list with meaningless content. -chris From swmike at swm.pp.se Tue Apr 20 11:38:33 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 20 Apr 2010 18:38:33 +0200 (CEST) Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> Message-ID: On Tue, 20 Apr 2010, John R. Levine wrote: > Skype video chat, all the time, works fine. Don't remember about file > transfer. Whenever I am behind NAT and talk to someone else who is behind NAT skype seems to lower the quality, my guess it's because it now bounces traffic via another non-NATed node. These kind of applications work best if there is at least one non-NATed party involved, especially for video etc. -- Mikael Abrahamsson email: swmike at swm.pp.se From lear at cisco.com Tue Apr 20 12:19:59 2010 From: lear at cisco.com (Eliot Lear) Date: Tue, 20 Apr 2010 19:19:59 +0200 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> Message-ID: <4BCDE23F.4030506@cisco.com> On 4/20/10 6:38 PM, Mikael Abrahamsson wrote: > On Tue, 20 Apr 2010, John R. Levine wrote: > >> Skype video chat, all the time, works fine. Don't remember about >> file transfer. > > Whenever I am behind NAT and talk to someone else who is behind NAT > skype seems to lower the quality, my guess it's because it now bounces > traffic via another non-NATed node. > > These kind of applications work best if there is at least one > non-NATed party involved, especially for video etc. My own experience is that skype quality lags that of iChat A/V, but I had always attributed that to iChat having better codecs. I could be wrong. iChat A/V, on the other hand, seems to have a heart attack when both sides have private addresses, and the firewall configuration is non-trivial. But I think we're going about this the wrong way. I wonder if we could change the way we do business in the longer term if everyone had public address space. As an application guy, I dislike the fact that people have to rely on some sort of service to share their calendars. That makes great sense for the service provider, and it even makes sense for the consumer right now due to the state of the art. But perhaps the times could change. There are lots of use cases where connecting into the house would be nice. Baby monitoring, security monitoring, Smart this, smart that, etc. Instead we require extra middleware to make it all work. The economics are, if nothing else, a painful lesson. Eliot From marquis at roble.com Tue Apr 20 12:29:02 2010 From: marquis at roble.com (Roger Marquis) Date: Tue, 20 Apr 2010 10:29:02 -0700 (PDT) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: Message-ID: <20100420172902.CB3BB2B2121@mx5.roble.com> Owen DeLong wrote: > The hardware cost of supporting LSN is trivial. The management/maintenance > costs and the customer experience -> dissatisfaction -> support calls -> > employee costs will not be so trivial. Interesting opinion but not backed up by experience. By contrast John Levine wrote: > My small telco-owned ISP NATs all of its DSL users, but you can get your > own IP on request. They have about 5000 users and I think they said I was > the eighth to ask for a private IP. I have to say that it took several > months to realize I was behind a NAT I'd bet good money John's experience is a better predictor of what will begin occurring when the supply of IPv4 addresses runs low. Then as now few consumers are likely to notice or care. Interesting how the artificial roadblocks to NAT66 are both delaying the transition to IPv6 and increasing the demand for NAT in both protocols. Nicely illustrates the risk when customer demand (for NAT) is ignored. That said the underlying issue is still about choice. We (i.e., the IETF) should be giving consumers the _option_ of NAT in IPv6 so they aren't required to use it in IPv4. IMO, Roger Marquis From owen at delong.com Tue Apr 20 12:38:17 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 20 Apr 2010 10:38:17 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100420172902.CB3BB2B2121@mx5.roble.com> References: <20100420172902.CB3BB2B2121@mx5.roble.com> Message-ID: On Apr 20, 2010, at 10:29 AM, Roger Marquis wrote: > Owen DeLong wrote: >> The hardware cost of supporting LSN is trivial. The management/maintenance >> costs and the customer experience -> dissatisfaction -> support calls -> >> employee costs will not be so trivial. > > Interesting opinion but not backed up by experience. > Since nobody has experience with LSN, that's a pretty easy statement to make. However, given the tech. support costs of single-layer NAT and the number of support calls I've seen from other less disruptive maintenance actions at various providers where I have worked, I think that in terms of applicable related experience available, yes, this is backed by experience. > By contrast John Levine wrote: >> My small telco-owned ISP NATs all of its DSL users, but you can get your >> own IP on request. They have about 5000 users and I think they said I was >> the eighth to ask for a private IP. I have to say that it took several >> months to realize I was behind a NAT > > I'd bet good money John's experience is a better predictor of what will > begin occurring when the supply of IPv4 addresses runs low. Then as now > few consumers are likely to notice or care. > ROFL... John has already made it clear that his usage profile is particularly NAT friendly compared to the average user. > Interesting how the artificial roadblocks to NAT66 are both delaying the > transition to IPv6 and increasing the demand for NAT in both protocols. > Nicely illustrates the risk when customer demand (for NAT) is ignored. > Uh, no. Interesting how the wilful ignorance around NAT and IPv6 is both delaying IPv6 transition and being used as an excuse to make things even worse for customers in the future. > That said the underlying issue is still about choice. We (i.e., the > IETF) should be giving consumers the _option_ of NAT in IPv6 so they > aren't required to use it in IPv4. > I guess that depends on whose choice you are interested in preserving. Owen From marquis at roble.com Tue Apr 20 13:53:31 2010 From: marquis at roble.com (Roger Marquis) Date: Tue, 20 Apr 2010 11:53:31 -0700 (PDT) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: Message-ID: <20100420185331.4DCEB2B2121@mx5.roble.com> Simon Perreault wrote: > http://tools.ietf.org/html/draft-ford-shared-addressing-issues The Ford Draft is quite liberal in its statements regarding issues with NAT. Unfortunately, in the real-world, those examples are somewhat fewer and farther between than the draft RFC would lead you to believe. Considering how many end-users sit behind NAT firewalls and non-firewall gateways at home, at work, and at public access points all day without issue, this is a particularly good example of the IETF's ongoing issues with design-by-committee, particularly committees short on security engineering and long on special interest. While LECs and ISPs may or may not feel some pain from LSN, they're equally sure feel better after crying all the way to the bank. IMO, Roger Marquis From jbates at brightok.net Tue Apr 20 13:56:32 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 20 Apr 2010 13:56:32 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100420185331.4DCEB2B2121@mx5.roble.com> References: <20100420185331.4DCEB2B2121@mx5.roble.com> Message-ID: <4BCDF8E0.8010706@brightok.net> Roger Marquis wrote: > Considering how many end-users sit behind NAT firewalls and non-firewall > gateways at home, at work, and at public access points all day without > issue, this is a particularly good example of the IETF's ongoing issues > with design-by-committee, particularly committees short on security > engineering and long on special interest. While LECs and ISPs may or may > not feel some pain from LSN, they're equally sure feel better after > crying all the way to the bank. Remove uPNP from those home user nat boxes and see how well the nat to nat connections work. Office firewalls often are heavily restrictive, use proxy layers to deal with connectivity issues and tend to have less typical types of traffic. Jack From joelja at bogus.com Tue Apr 20 13:59:29 2010 From: joelja at bogus.com (joel jaeggli) Date: Tue, 20 Apr 2010 11:59:29 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100420172902.CB3BB2B2121@mx5.roble.com> References: <20100420172902.CB3BB2B2121@mx5.roble.com> Message-ID: <4BCDF991.9010604@bogus.com> On 4/20/2010 10:29 AM, Roger Marquis wrote: > Interesting how the artificial roadblocks to NAT66 are both delaying the > transition to IPv6 and increasing the demand for NAT in both protocols. > Nicely illustrates the risk when customer demand (for NAT) is ignored. This is really tiresome. IPv4 NAT existed commercially long before there was any effort at standardizing it. If you have a commercial requirement for IPv6 NAT inform your vendors and help them build a business case. I worked at a firewall vendor for a couple of years, and in that time I worked on the business cases for both ipv6 NAT and NAT-PT ipv6 ipv4 nat protocol translation, NAT-PT even got so far as a prototype in that organization (IOS has NAT-PT btw). I can tell you want stalled me out on this in 2007-2009 was a lack of paying customers prroritizing the features not an inability to understand the problem space. What's commercially available in the space is going to be a product of demand, not a product of documents produced by the IETF. if there is consensus among vendors about how such a thing in implemented that manifests itself ietf doucments so much the better. > That said the underlying issue is still about choice. We (i.e., the > IETF) should be giving consumers the _option_ of NAT in IPv6 so they > aren't required to use it in IPv4. You're going to use it in v4 anyway. choice in the marketplace is about what you're willing to pay for, vendors at leat the ones that I work with don't turn on a dime and the have a lot of functionality gaps to close with ipv6 not just this one. > IMO, > Roger Marquis > From jabley at hopcount.ca Tue Apr 20 14:19:52 2010 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 20 Apr 2010 15:19:52 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCDF991.9010604@bogus.com> References: <20100420172902.CB3BB2B2121@mx5.roble.com> <4BCDF991.9010604@bogus.com> Message-ID: <6CE72154-7F21-4FC7-BD87-452099D80256@hopcount.ca> On 2010-04-20, at 14:59, joel jaeggli wrote: > On 4/20/2010 10:29 AM, Roger Marquis wrote: >> Interesting how the artificial roadblocks to NAT66 are both delaying the >> transition to IPv6 and increasing the demand for NAT in both protocols. >> Nicely illustrates the risk when customer demand (for NAT) is ignored. > > This is really tiresome. IPv4 NAT existed commercially long before there was any effort at standardizing it. Another way of looking at that would be that IPv4 NAT existed commercially despite massive resistance to the idea of standardising it. I think it is fair to say that standardisation would have saved many developers from a certain amount of pain and suffering. It'd be nice to think that with v6 the pressures that caused v4 NAT to be a good idea no longer exist. v6 is being deployed into a world where it's normal to assume residential users have more than one device, for example. However, in enterprise/campus environments I think the pressure for NAT66 is not because there are technical problems that NAT66 would solve, but rather because there's a generation of common wisdom that says that NAT is how you build enterprise/campus networks. This is unfortunate. Hopefully I'm wrong. Joe From owen at delong.com Tue Apr 20 14:16:52 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 20 Apr 2010 12:16:52 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCDF8E0.8010706@brightok.net> References: <20100420185331.4DCEB2B2121@mx5.roble.com> <4BCDF8E0.8010706@brightok.net> Message-ID: <47850C17-EA86-4115-9CC5-2AD1792E4495@delong.com> On Apr 20, 2010, at 11:56 AM, Jack Bates wrote: > Roger Marquis wrote: >> Considering how many end-users sit behind NAT firewalls and non-firewall >> gateways at home, at work, and at public access points all day without >> issue, this is a particularly good example of the IETF's ongoing issues >> with design-by-committee, particularly committees short on security >> engineering and long on special interest. While LECs and ISPs may or may >> not feel some pain from LSN, they're equally sure feel better after >> crying all the way to the bank. > > Remove uPNP from those home user nat boxes and see how well the nat to nat connections work. Office firewalls often are heavily restrictive, use proxy layers to deal with connectivity issues and tend to have less typical types of traffic. > > Jack uPNP will not likely be feasible on LSN. So, yes, you need to do your NAT testing in preparation for LSN on the basis of what works without uPNP. Owen From marquis at roble.com Tue Apr 20 14:31:47 2010 From: marquis at roble.com (Roger Marquis) Date: Tue, 20 Apr 2010 12:31:47 -0700 (PDT) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: Message-ID: <20100420193147.C69612B2128@mx5.roble.com> Jack Bates wrote: > .01%? heh. NAT can break xbox, ps3, certain pc games, screw with various > programs that dislike multiple connections from a single IP, and the > crap load of vpn clients that appear on the network and do not support > nat traversal (either doesn't support it, or big corp A refuses to > enable it). If this were really an issue I'd expect my nieces and nephews, all of whom are big game players, would have mentioned it. They haven't though, despite being behind cheap NATing CPE from D-Link and Netgear. Address conservation aside, the main selling point of NAT is its filtering of inbound session requests. NAT _always_ fails-closed by forcing inbound connections to pass validation by stateful inspection. Without this you'd have to depend on less reliable (fail-open) mechanisms and streams could be initiated from the Internet at large. In theory you could enforce fail-closed reliably without NAT, but the rules would have to be more complex and complexity is the enemy of security. Worse, if non-NATed CPE didn't do adequate session validation, inspection, and tracking, as low-end gear might be expected to cut corners on, end-user networks would be more exposed to nefarious outside-initiated streams. Arguments against NAT uniformly fail to give credit to these security considerations, which is a large reason the market has not taken IPv6 seriously to-date. Even in big business, CISOs are able to shoot-down netops recommendations for 1:1 address mapping with ease (not that vocal NAT opponents get jobs where internal security is a concern). IMO, Roger Marquis From jbfixurpc at gmail.com Tue Apr 20 14:41:31 2010 From: jbfixurpc at gmail.com (jbfixurpc at gmail.com) Date: Tue, 20 Apr 2010 15:41:31 -0400 Subject: IPV4 and IPV6 question Message-ID: <000801cae0c1$7aca03d0$4401a8c0@jgbpc> Greetings, This may seem like a stupid question, but in IPV4 there are a few "reserved" bits which I've not seen used, but perhaps I am behind the times. With regard to these, what if one was to use such to delegate a second venue of IP space? In otherwords flip a bit in the flags reserved < http://www.networksorcery.com/enp/protocol/ip.htm#Flags > and now its considered IPV4.2 ... Would that not give a second range of IP address space to use? Granted there would be a ton of upgrades/updates to enable such, but sounds a little bit simplier than an IPV6 upgrade, maybe? I am on the fence regarding IPV6 as there have been many logical arguments pro and con regarding its deployment. I still have to wonder about these "reserved" bits, that seem never to be used, why not use them? Again perhaps I am behind the times and all of the bits are being used. Just my 2 cents. Kind regards -Joe From cmadams at hiwaay.net Tue Apr 20 14:51:19 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 20 Apr 2010 14:51:19 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100420193147.C69612B2128@mx5.roble.com> References: <20100420193147.C69612B2128@mx5.roble.com> Message-ID: <20100420195119.GC1184776@hiwaay.net> Once upon a time, Roger Marquis said: > Address conservation aside, the main selling point of NAT is its filtering > of inbound > session requests. NAT _always_ fails-closed by forcing inbound connections > to pass > validation by stateful inspection. Without this you'd have to depend on > less > reliable (fail-open) mechanisms and streams could be initiated from the > Internet at > large. In theory you could enforce fail-closed reliably without NAT, but > the rules > would have to be more complex and complexity is the enemy of security. NAT == stateful firewall + packet mangling. You can do all the same stateful firewall bits and drop the packet mangling quite easily (it is certainly not "more complex" to not mangle packets). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jabley at hopcount.ca Tue Apr 20 14:55:54 2010 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 20 Apr 2010 15:55:54 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100420193147.C69612B2128@mx5.roble.com> References: <20100420193147.C69612B2128@mx5.roble.com> Message-ID: On 2010-04-20, at 15:31, Roger Marquis wrote: > If this were really an issue I'd expect my nieces and nephews, all of whom are big > game players, would have mentioned it. They haven't though, despite being behind > cheap NATing CPE from D-Link and Netgear. I have heard it said before that there is significant cooperation and/or software engineering work between some or all of those who make residential gateways and those who make multi-player games to achieve this end result. The opinion I heard vocalised at the time was that it would have been a lot easier to reach this state of affairs if there had been standardisation of NAT in v4 at an early stage. As it is, peer-to-peer apps like games require significant if-then-else to make anything work. > Address conservation aside, the main selling point of NAT is its filtering of inbound > session requests. If that was all that was required, you could sell a stateful firewall that didn't do NAT, and everybody would buy that instead because it would make things like iChat AV break less. Apparently there are other reasons to buy and sell devices that NAT (e.g. my ISP gives me one address, but the laptop and the Wii both want to use the internet). Joe From owen at delong.com Tue Apr 20 15:02:07 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 20 Apr 2010 13:02:07 -0700 Subject: IPV4 and IPV6 question In-Reply-To: <000801cae0c1$7aca03d0$4401a8c0@jgbpc> References: <000801cae0c1$7aca03d0$4401a8c0@jgbpc> Message-ID: You're literally talking about modifying code on every computer, router, printer, and other device with an IP address as well as updating every application, routing protocol, etc. Pretty much the same set of requirements for deploying IPv6, but, with IPv6, we've at least already done the code on most computers and routers. To me, it sounds like the same effort as deploying IPv6, but, without gaining as many bits and without having the advantage of the progress we have already made in IPv6. Owen On Apr 20, 2010, at 12:41 PM, wrote: > > Greetings, > > > > This may seem like a stupid question, but in IPV4 there are a few > "reserved" bits which I've not seen used, but perhaps I am behind the times. > With regard to these, what if one was to use such to delegate a second venue > of IP space? In otherwords flip a bit in the flags reserved < > http://www.networksorcery.com/enp/protocol/ip.htm#Flags > and now its > considered IPV4.2 ... Would that not give a second range of IP address space > to use? Granted there would be a ton of upgrades/updates to enable such, but > sounds a little bit simplier than an IPV6 upgrade, maybe? I am on the fence > regarding IPV6 as there have been many logical arguments pro and con > regarding its deployment. I still have to wonder about these "reserved" > bits, that seem never to be used, why not use them? Again perhaps I am > behind the times and all of the bits are being used. Just my 2 cents. > > > > Kind regards > -Joe > From owen at delong.com Tue Apr 20 14:59:32 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 20 Apr 2010 12:59:32 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100420193147.C69612B2128@mx5.roble.com> References: <20100420193147.C69612B2128@mx5.roble.com> Message-ID: <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote: > Jack Bates wrote: >> .01%? heh. NAT can break xbox, ps3, certain pc games, screw with various >> programs that dislike multiple connections from a single IP, and the >> crap load of vpn clients that appear on the network and do not support >> nat traversal (either doesn't support it, or big corp A refuses to >> enable it). > > If this were really an issue I'd expect my nieces and nephews, all of whom are big > game players, would have mentioned it. They haven't though, despite being behind > cheap NATing CPE from D-Link and Netgear. > > Address conservation aside, the main selling point of NAT is its filtering of inbound > session requests. NAT _always_ fails-closed by forcing inbound connections to pass > validation by stateful inspection. Without this you'd have to depend on less Repeating the same falsehood does not make it any less false. > reliable (fail-open) mechanisms and streams could be initiated from the Internet at > large. In theory you could enforce fail-closed reliably without NAT, but the rules Stateful Inspection can be implemented fail-closed. I point to Juniper ScreenOS and Services JunOS as examples of this. Absent a specific permit or specific configuration telling it to pass particular traffic inbound, traffic must pass the same stateful inspection that NAT would require. This is default behavior in those boxes. The rules are not complex at all. > would have to be more complex and complexity is the enemy of security. Worse, if > non-NATed CPE didn't do adequate session validation, inspection, and tracking, as Again, you simply are not correct here. I'm not sure what level of implementation is available in low-end gear as it hasn't met my needs in a long long time. However, I will say that although an SRX-100 is not especially low-end at 10x absolute low end pricing and 5x average home gateway pricing, it is low-enough end that I know this can be done in reasonable gear. > low-end gear might be expected to cut corners on, end-user networks would be more > exposed to nefarious outside-initiated streams. > Frankly, even with NAT, corner-cutting in those areas can lead to things passing which you don't expect. > Arguments against NAT uniformly fail to give credit to these security considerations, Because they are false. It's not that they fail to give credit to them. It's that they know them to be false. It's like saying that discussions of breathing gas fail to give credit to the respiratory effects of the trace amounts of argon present in the atmosphere. > which is a large reason the market has not taken IPv6 seriously to-date. Even in big > business, CISOs are able to shoot-down netops recommendations for 1:1 address mapping > with ease (not that vocal NAT opponents get jobs where internal security is a > concern). > While I recognize that there is a group of people who religiously believe that NAT has a security benefit, I don't think the represent a significant fraction of the reasons IPv6 is not getting deployed. Frankly, many of them have more IPv6 deployed than they realize and their NAT is not protecting them from it at all. It may even be helping some of the nefarious traffic that may be taking advantage of the current situation to remain safely anonymized and invisible. Owen From jamesmartin at ieee.org Tue Apr 20 15:08:04 2010 From: jamesmartin at ieee.org (James Martin) Date: Tue, 20 Apr 2010 16:08:04 -0400 Subject: Reverse DNS Question Message-ID: All: In the process of requesting a block of IP's for a client, ARIN requested that we list Reverse DNS Servers for the block. I've never done this before, nor have I ever thought it through. What is the purpose for this besides resolving name-based reverse lookups? Are there any definitive guides out there on how this works (besides the ARIN site)? I know this is really basic stuff but I don't know it and have never needed to know it until now. Thanks -- __________________________________ James Martin jamesmartin at ieee.org From owen at delong.com Tue Apr 20 15:07:09 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 20 Apr 2010 13:07:09 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100420193147.C69612B2128@mx5.roble.com> Message-ID: <002D2D4F-686F-4067-87C2-B3434AB4321E@delong.com> On Apr 20, 2010, at 12:55 PM, Joe Abley wrote: > > On 2010-04-20, at 15:31, Roger Marquis wrote: > >> If this were really an issue I'd expect my nieces and nephews, all of whom are big >> game players, would have mentioned it. They haven't though, despite being behind >> cheap NATing CPE from D-Link and Netgear. > > I have heard it said before that there is significant cooperation and/or software engineering work between some or all of those who make residential gateways and those who make multi-player games to achieve this end result. The opinion I heard vocalised at the time was that it would have been a lot easier to reach this state of affairs if there had been standardisation of NAT in v4 at an early stage. As it is, peer-to-peer apps like games require significant if-then-else to make anything work. > The fact that they work is usually due to uPNP or another inbound NAT-T solution. All of these will be very unlikely to work in an LSN environment. None of them work in a multilayer NAT environment. >> Address conservation aside, the main selling point of NAT is its filtering of inbound >> session requests. > > If that was all that was required, you could sell a stateful firewall that didn't do NAT, and everybody would buy that instead because it would make things like iChat AV break less. Apparently there are other reasons to buy and sell devices that NAT (e.g. my ISP gives me one address, but the laptop and the Wii both want to use the internet). > In IPv4, yes, there are other reasons. (Address conservation). In IPv6, it shouldn't be a problem to sell a stateful firewall that doesn't do NAT. Owen From jack at crepinc.com Tue Apr 20 15:19:23 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Tue, 20 Apr 2010 16:19:23 -0400 Subject: Reverse DNS Question In-Reply-To: References: Message-ID: > What is the purpose for this besides resolving name-based reverse lookups? Resolving the reverse lookups IS the reason they need the nameservers - how else do you reckon queries on one of your IPs would end up finding the correct answer? In the same manner that you tell your domain registrar where to find nameservers for that domain, you're telling ARIN what servers can handle a query for [your-ips].IN-ADDR.ARPA > Are there any definitive guides out there on how this works (besides the > ARIN site)? On setting up nameservers? Googling 'configuring BIND' will lead you on your way, unless you're already using a different nameserver daemon. As far as I know there are no ARIN-specific requirements to it. Cheers, -Jack Carrozzo > > I know this is really basic stuff but I don't know it and have never needed > to know it until now. > > Thanks > > -- > __________________________________ > James Martin > jamesmartin at ieee.org > From tony at lava.net Tue Apr 20 15:26:17 2010 From: tony at lava.net (Antonio Querubin) Date: Tue, 20 Apr 2010 10:26:17 -1000 (HST) Subject: Reverse DNS Question In-Reply-To: References: Message-ID: On Tue, 20 Apr 2010, James Martin wrote: > What is the purpose for this besides resolving name-based reverse lookups? > Are there any definitive guides out there on how this works (besides the > ARIN site)? It's for resolving address-based lookups. When ARIN allocates address space to you, you now become responsible for the reverse-lookups for that allocated address range. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From leen at consolejunkie.net Tue Apr 20 15:31:46 2010 From: leen at consolejunkie.net (Leen Besselink) Date: Tue, 20 Apr 2010 22:31:46 +0200 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100420193147.C69612B2128@mx5.roble.com> References: <20100420193147.C69612B2128@mx5.roble.com> Message-ID: <4BCE0F32.6020608@consolejunkie.net> On 04/20/2010 09:31 PM, Roger Marquis wrote: > Jack Bates wrote: >> .01%? heh. NAT can break xbox, ps3, certain pc games, screw with various >> programs that dislike multiple connections from a single IP, and the >> crap load of vpn clients that appear on the network and do not support >> nat traversal (either doesn't support it, or big corp A refuses to >> enable it). > > If this were really an issue I'd expect my nieces and nephews, all of > whom are big > game players, would have mentioned it. They haven't though, despite > being behind > cheap NATing CPE from D-Link and Netgear. > > Address conservation aside, the main selling point of NAT is its > filtering of inbound > session requests. NAT _always_ fails-closed by forcing inbound > connections to pass > validation by stateful inspection. Without this you'd have to depend > on less > reliable (fail-open) mechanisms and streams could be initiated from > the Internet at > large. In theory you could enforce fail-closed reliably without NAT, > but the rules > would have to be more complex and complexity is the enemy of > security. Worse, if As others have mentioned on the list, this is wrong. NAT is the one that makes things much more complicated in fact. And even NAT can be tricked. But I do have a question: Do you think TCP-port 53 for DNS are only used for domain-name transfers ? > non-NATed CPE didn't do adequate session validation, inspection, and > tracking, as > low-end gear might be expected to cut corners on, end-user networks > would be more > exposed to nefarious outside-initiated streams. > > Arguments against NAT uniformly fail to give credit to these security > considerations, > which is a large reason the market has not taken IPv6 seriously > to-date. Even in big > business, CISOs are able to shoot-down netops recommendations for 1:1 > address mapping > with ease (not that vocal NAT opponents get jobs where internal > security is a > concern). > > IMO, > Roger Marquis > > From LarrySheldon at cox.net Tue Apr 20 15:37:54 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 20 Apr 2010 15:37:54 -0500 Subject: Reverse DNS Question In-Reply-To: References: Message-ID: <4BCE10A2.3090103@cox.net> On 4/20/2010 15:26, Antonio Querubin wrote: > On Tue, 20 Apr 2010, James Martin wrote: > >> What is the purpose for this besides resolving name-based reverse lookups? >> Are there any definitive guides out there on how this works (besides the >> ARIN site)? > > It's for resolving address-based lookups. When ARIN allocates address > space to you, you now become responsible for the reverse-lookups for that > allocated address range. Some email blacklist operators have draconian requirements for PTR values for IP addresses that (attempt to) send email. To minimize unwarranted hassle, if you will have email senders, spend some time looking into the "requirements". I don't think there are any RFC or other authoritative standards in the matter. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From schmoe at gmail.com Tue Apr 20 15:44:57 2010 From: schmoe at gmail.com (Joe Wood) Date: Tue, 20 Apr 2010 13:44:57 -0700 Subject: Intrado Service Message-ID: Hello. Can someone at Intrado contact me sometime soon? Your voicemails are not being returned, as with your emails. I'd love to give you money, but without details, I can't . Joe From jbates at brightok.net Tue Apr 20 15:51:46 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 20 Apr 2010 15:51:46 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100420193147.C69612B2128@mx5.roble.com> References: <20100420193147.C69612B2128@mx5.roble.com> Message-ID: <4BCE13E2.2020509@brightok.net> Roger Marquis wrote: > If this were really an issue I'd expect my nieces and nephews, all of > whom are big > game players, would have mentioned it. They haven't though, despite > being behind > cheap NATing CPE from D-Link and Netgear. Disable the uPNP (some routers lack it, and yes, it breaks and microsoft will tell you to get uPNP capable NAT routers or get a new ISP). uPNP at a larger scale? Would require some serious security and scalability analysis. > Arguments against NAT uniformly fail to give credit to these security > considerations, Your argument has nothing to do with this part of the thread and discussion of why implementing NAT at a larger scale is bad. I guess it might have something to do in other tangents of supporting NAT66. Jack From simon at slimey.org Tue Apr 20 16:41:29 2010 From: simon at slimey.org (Simon Lockhart) Date: Tue, 20 Apr 2010 22:41:29 +0100 Subject: Anyone got access to Cisco Call Manager >= 7.1(3b)SU1 ? Message-ID: <20100420214129.GL23204@virtual.bogons.net> All (and apologies for the slight off-topic-ness), I need to get hold of a config file for a Cisco 9971 handset that has been generated by Cisco Call Manager (or, rather Cisco Unified Communications Manager) release 7.1(3b)SU1 or higher. Does anyone have access to such a system and would be prepared to generate a handset config file for me? If so, please respond to me off-list and I'll let you know exactly what I'm after... Many thanks, Simon From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Apr 20 16:56:12 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 21 Apr 2010 07:26:12 +0930 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> Message-ID: <20100421072612.38afe94f@opy.nosense.org> On Tue, 20 Apr 2010 18:38:33 +0200 (CEST) Mikael Abrahamsson wrote: > On Tue, 20 Apr 2010, John R. Levine wrote: > > > Skype video chat, all the time, works fine. Don't remember about file > > transfer. > > Whenever I am behind NAT and talk to someone else who is behind NAT skype > seems to lower the quality, my guess it's because it now bounces traffic > via another non-NATed node. > I think that means skype will be ported to IPv6 pretty quickly. CGN/LSN is going to dramatically reduce the number of 'super nodes' with public IPv4 addresses to relay calls through. That'll be particularly unfair to people in Australia, because here we have a per-month quota system e.g. 20GB of downloads and/or uploads a month. I wouldn't want my quota being chewed up by lots of other people's phone calls. > These kind of applications work best if there is at least one non-NATed > party involved, especially for video etc. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > Regards, Mark. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Apr 20 16:59:09 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 21 Apr 2010 07:29:09 +0930 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100420172902.CB3BB2B2121@mx5.roble.com> References: <20100420172902.CB3BB2B2121@mx5.roble.com> Message-ID: <20100421072909.5675eb83@opy.nosense.org> On Tue, 20 Apr 2010 10:29:02 -0700 (PDT) Roger Marquis wrote: > Owen DeLong wrote: > > The hardware cost of supporting LSN is trivial. The management/maintenance > > costs and the customer experience -> dissatisfaction -> support calls -> > > employee costs will not be so trivial. > > Interesting opinion but not backed up by experience. > > By contrast John Levine wrote: > > My small telco-owned ISP NATs all of its DSL users, but you can get your > > own IP on request. They have about 5000 users and I think they said I was > > the eighth to ask for a private IP. I have to say that it took several > > months to realize I was behind a NAT > > I'd bet good money John's experience is a better predictor of what will > begin occurring when the supply of IPv4 addresses runs low. Then as now > few consumers are likely to notice or care. > > Interesting how the artificial roadblocks to NAT66 are both delaying the > transition to IPv6 and increasing the demand for NAT in both protocols. > Nicely illustrates the risk when customer demand (for NAT) is ignored. > Customers never asked for NAT. Ask the non-geek customer if they went looking for a ISP plan or modem that supports NAT and they'll look at you funny. Ask them if they want to share their Internet access between multiple devices in their home, and they'll say yes. > That said the underlying issue is still about choice. We (i.e., the > IETF) should be giving consumers the _option_ of NAT in IPv6 so they > aren't required to use it in IPv4. > > IMO, > Roger Marquis > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Apr 20 17:02:39 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 21 Apr 2010 07:32:39 +0930 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100420172902.CB3BB2B2121@mx5.roble.com> Message-ID: <20100421073239.0c6d4ff7@opy.nosense.org> On Tue, 20 Apr 2010 10:38:17 -0700 Owen DeLong wrote: > > On Apr 20, 2010, at 10:29 AM, Roger Marquis wrote: > > > Owen DeLong wrote: > >> The hardware cost of supporting LSN is trivial. The management/maintenance > >> costs and the customer experience -> dissatisfaction -> support calls -> > >> employee costs will not be so trivial. > > > > Interesting opinion but not backed up by experience. > > > Since nobody has experience with LSN, that's a pretty easy statement to make. > It is backed up by capex - how many people can afford to have just the chassis to put one of these in? I know most ISPs in Australia can't (and my opinion is that you shouldn't be putting it in the core anyway - the only justification I can see to building one of these at this size is that scaling down is usually a lot easier than scaling up): http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/brochure_c02-560497_ns1017_Networking_Solutions_Brochure.html > However, given the tech. support costs of single-layer NAT and the number of > support calls I've seen from other less disruptive maintenance actions at various > providers where I have worked, I think that in terms of applicable related > experience available, yes, this is backed by experience. > > > By contrast John Levine wrote: > >> My small telco-owned ISP NATs all of its DSL users, but you can get your > >> own IP on request. They have about 5000 users and I think they said I was > >> the eighth to ask for a private IP. I have to say that it took several > >> months to realize I was behind a NAT > > > > I'd bet good money John's experience is a better predictor of what will > > begin occurring when the supply of IPv4 addresses runs low. Then as now > > few consumers are likely to notice or care. > > > ROFL... John has already made it clear that his usage profile is particularly > NAT friendly compared to the average user. > > > Interesting how the artificial roadblocks to NAT66 are both delaying the > > transition to IPv6 and increasing the demand for NAT in both protocols. > > Nicely illustrates the risk when customer demand (for NAT) is ignored. > > > Uh, no. Interesting how the wilful ignorance around NAT and IPv6 > is both delaying IPv6 transition and being used as an excuse to make > things even worse for customers in the future. > > > That said the underlying issue is still about choice. We (i.e., the > > IETF) should be giving consumers the _option_ of NAT in IPv6 so they > > aren't required to use it in IPv4. > > > I guess that depends on whose choice you are interested in preserving. > > Owen > > From simon.perreault at viagenie.ca Tue Apr 20 17:03:09 2010 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Tue, 20 Apr 2010 18:03:09 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCE13E2.2020509@brightok.net> References: <20100420193147.C69612B2128@mx5.roble.com> <4BCE13E2.2020509@brightok.net> Message-ID: <4BCE249D.7090805@viagenie.ca> On 04/20/2010 04:51 PM, Jack Bates wrote: > uPNP at a larger scale? Would require some serious security and > scalability analysis. This is the latest proposal. The Security Considerations section needs some love... http://tools.ietf.org/html/draft-wing-softwire-port-control-protocol Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From frnkblk at iname.com Tue Apr 20 17:19:41 2010 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 20 Apr 2010 17:19:41 -0500 Subject: Seeking Amazon EC2 abuse contact In-Reply-To: References: , <1271063763.6107.3179.camel@mike-desktop> , <02a601cada45$91aa34d0$b4fe9e70$@nl> Message-ID: Just a follow-up: Amazon posted a response at https://aws.amazon.com/security/ which discusses the issue and what they're doing to improve things. Frank -----Original Message----- From: Erik L [mailto:erik_list at caneris.com] Sent: Monday, April 12, 2010 11:52 AM To: nanog at nanog.org Subject: RE: Seeking Amazon EC2 abuse contact Many thanks again to the large number of off-list responses. After making human contact, the issue was very promptly resolved by Amazon and a gentleman there has promised to look into the error on the abuse form as well. Erik ________________________________________ From: Mark Scholten [mark at streamservice.nl] Sent: Monday, April 12, 2010 9:39 AM To: Erik L; 'Michael J McCafferty' Cc: nanog at nanog.org Subject: RE: Seeking Amazon EC2 abuse contact Hello Erik, Do you care to share the IP address? So everyone could update their firewalls to block the attacks? Even only blocking known SIP ports (5060) could be a good idea. With kind regards, Mark Scholten > -----Original Message----- > From: Erik L [mailto:erik_list at caneris.com] > Sent: Monday, April 12, 2010 3:05 PM > To: Michael J McCafferty > Cc: nanog at nanog.org > Subject: RE: Seeking Amazon EC2 abuse contact > > Michael, > > I've received numerous off-list responses yesterday. Most of them were > asking if I've made contact with anyone there as they were being > attacked as well. One gentleman who works at AWS (but not EC2 abuse) > promised to forward my e-mail to them. I've also been reading the > asterisk-users list where many have reported attacks from Amazon EC2 as > well over the past few days. > > At one point we were seeing 197 SIP brute force attempts per second > against a customer's box. The intensity in terms of bandwidth is low, > but if you do the math, you can see that this isn't the point. > > This morning I received an e-mail from Amazon which was basically the > same as the one you received. The attack is still on-going and I've > still not made contact with a human at Amazon. > > Erik > > > > > -----Original Message----- > > From: Michael J McCafferty [mailto:mike at m5computersecurity.com] > > Sent: April 12, 2010 05:16 > > To: Erik L > > Cc: nanog at nanog.org > > Subject: Re: Seeking Amazon EC2 abuse contact > > > > Erik, > > We have several customers being attacked from the same > > EC2 instance on > > their network for 2 full days now. Contacted them at > > ec2-abuse at amazon.com and 25 hours later received a message that > > basically said, "Yep, we can confirm that a customer of ours is > > attacking you but that's their fault. We sometimes do stuff, > > but not in > > this case. Please don't block us, because the IP might be someone > else > > later. Have a nice day". > > The telephone number in the WHOIS record goes to a > > general voicemail > > box for their legal department. > > A few of our customers who are being attacked by this > > same instance at > > EC2 have also contacted Amazon, and were told essentially the same > > thing. > > While I appreciate that they sent a response, I do not > > appreciate it's > > uselessness. > > Anyone over there at AWS that can do something willing > > to reply to me > > directly? > > > > Thanks! > > Mike > > > > > > On Sun, 2010-04-11 at 10:38 -0400, Erik L wrote: > > > Could someone from Amazon EC2 please contact me off-list > > regarding an abuse issue from one of their IPs? > > Alternatively, could someone please send me the contact > > details of someone there? > > > > > > E-mailing the abuse e-mail listed in WHOIS per their > > instructions, including all pertinent data, results in an > > auto-reply indicating to use a form on their site. Submitting > > the form results in "There has been an error while submitting > > your data. Please try again later." Calling their supposed > > NOC (as per WHOIS) results in "You have reached the legal > > department at Amazon...please leave a message". > > > > > > Thanks > > > > > -- > > ************************************************************ > > 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 jbates at brightok.net Tue Apr 20 17:25:09 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 20 Apr 2010 17:25:09 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCE249D.7090805@viagenie.ca> References: <20100420193147.C69612B2128@mx5.roble.com> <4BCE13E2.2020509@brightok.net> <4BCE249D.7090805@viagenie.ca> Message-ID: <4BCE29C5.8000203@brightok.net> Simon Perreault wrote: > This is the latest proposal. The Security Considerations section needs > some love... > > http://tools.ietf.org/html/draft-wing-softwire-port-control-protocol > Nice read. IF it ever makes it into all the necessary clients, then perhaps it might be a bit more feasible. That is a big if and very little time for adoption in a large number of devices to fix just one of the problems. Jack From newton at internode.com.au Tue Apr 20 17:31:33 2010 From: newton at internode.com.au (Mark Newton) Date: Wed, 21 Apr 2010 08:01:33 +0930 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <201004200358.o3K3wDQk071509@drugs.dv.isc.org> References: <201004200022.o3K0M2Ba007459@aurora.sol.net> <201004200225.o3K2OwVi070153@drugs.dv.isc.org> <4BCD14EF.8090204@zill.net> <201004200320.o3K3KB4s071149@drugs.dv.isc.org> <4BCD203E.3050302@zill.net> <201004200358.o3K3wDQk071509@drugs.dv.isc.org> Message-ID: <67D28817-D47B-468F-9212-186C60531140@internode.com.au> On 20/04/2010, at 1:28 PM, Mark Andrews wrote: > Changing from a public IP address to a private IP address is a big > change in the conditions of the contract. People do select ISP's > on the basis of whether they will get a public IP address or a > private IP address. Seems to me your objection is based on whether or not the customer gets a public address vs a private address. There's no need for NAT pools to be RFC1918. Pretty sure everyone is going to get a public address of some form... it just won't necessarily be globally unique to them. As for jurisdictional issues: This particular Australian ISP amended its T&C document to give us the discretion of providing LSN addresses about two years ago. Will we need to? Perhaps not. But if we do, the T&C's are already worked out. Looking ahead in time and forecasting future risks is one of the things businesses are supposed to do, right? Regards, - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Apr 20 17:38:21 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 21 Apr 2010 08:08:21 +0930 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> References: <20100420193147.C69612B2128@mx5.roble.com> <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> Message-ID: <20100421080821.7339acae@opy.nosense.org> On Tue, 20 Apr 2010 12:59:32 -0700 Owen DeLong wrote: > > On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote: > > > Jack Bates wrote: > >> .01%? heh. NAT can break xbox, ps3, certain pc games, screw with various > >> programs that dislike multiple connections from a single IP, and the > >> crap load of vpn clients that appear on the network and do not support > >> nat traversal (either doesn't support it, or big corp A refuses to > >> enable it). > > > > If this were really an issue I'd expect my nieces and nephews, all of whom are big > > game players, would have mentioned it. They haven't though, despite being behind > > cheap NATing CPE from D-Link and Netgear. > > > > Address conservation aside, the main selling point of NAT is its filtering of inbound > > session requests. NAT _always_ fails-closed by forcing inbound connections to pass > > validation by stateful inspection. Without this you'd have to depend on less > > Repeating the same falsehood does not make it any less false. > > > reliable (fail-open) mechanisms and streams could be initiated from the Internet at > > large. In theory you could enforce fail-closed reliably without NAT, but the rules > > Stateful Inspection can be implemented fail-closed. I point to Juniper ScreenOS > and Services JunOS as examples of this. Absent a specific permit or specific > configuration telling it to pass particular traffic inbound, traffic must pass the same > stateful inspection that NAT would require. This is default behavior in those boxes. > The rules are not complex at all. > Frankly, when you hear people strongly using the argument stateful firewalling == NAT, you start to wonder if they've ever seen a stateful firewall using public addresses. > > would have to be more complex and complexity is the enemy of security. Worse, if > > non-NATed CPE didn't do adequate session validation, inspection, and tracking, as > > Again, you simply are not correct here. I'm not sure what level of implementation is > available in low-end gear as it hasn't met my needs in a long long time. However, > I will say that although an SRX-100 is not especially low-end at 10x absolute low > end pricing and 5x average home gateway pricing, it is low-enough end that I > know this can be done in reasonable gear. > > > low-end gear might be expected to cut corners on, end-user networks would be more > > exposed to nefarious outside-initiated streams. > > > Frankly, even with NAT, corner-cutting in those areas can lead to things passing which > you don't expect. > > > Arguments against NAT uniformly fail to give credit to these security considerations, > > Because they are false. It's not that they fail to give credit to them. It's that they know > them to be false. It's like saying that discussions of breathing gas fail to give credit > to the respiratory effects of the trace amounts of argon present in the atmosphere. > > > which is a large reason the market has not taken IPv6 seriously to-date. Even in big > > business, CISOs are able to shoot-down netops recommendations for 1:1 address mapping > > with ease (not that vocal NAT opponents get jobs where internal security is a > > concern). > > > While I recognize that there is a group of people who religiously believe that NAT > has a security benefit, I don't think the represent a significant fraction of the reasons > IPv6 is not getting deployed. Frankly, many of them have more IPv6 deployed than > they realize and their NAT is not protecting them from it at all. It may even be helping > some of the nefarious traffic that may be taking advantage of the current situation > to remain safely anonymized and invisible. > > > Owen > > From tariq198487 at hotmail.com Tue Apr 20 17:44:05 2010 From: tariq198487 at hotmail.com (Tarig Yassin) Date: Wed, 21 Apr 2010 01:44:05 +0300 Subject: Reverse DNS Question In-Reply-To: References: Message-ID: Dear janes as I know many services use reverse lookup as a sender authentication technique. e.g. Email server using this technique to reduce spams.( if the ip adress of sending smtp server has no reverse lookup it's messages will be considered spam). regards, > Date: Tue, 20 Apr 2010 16:08:04 -0400 > Subject: Reverse DNS Question > From: jamesmartin at ieee.org > To: nanog at nanog.org > > All: > > In the process of requesting a block of IP's for a client, ARIN requested > that we list Reverse DNS Servers for the block. I've never done this > before, nor have I ever thought it through. > > What is the purpose for this besides resolving name-based reverse lookups? > Are there any definitive guides out there on how this works (besides the > ARIN site)? > > I know this is really basic stuff but I don't know it and have never needed > to know it until now. > > Thanks > > -- > __________________________________ > James Martin > jamesmartin at ieee.org _________________________________________________________________ Hotmail: Trusted email with Microsoft?s powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969 From Valdis.Kletnieks at vt.edu Tue Apr 20 18:15:48 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 20 Apr 2010 19:15:48 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: Your message of "Tue, 20 Apr 2010 18:03:09 EDT." <4BCE249D.7090805@viagenie.ca> References: <20100420193147.C69612B2128@mx5.roble.com> <4BCE13E2.2020509@brightok.net> <4BCE249D.7090805@viagenie.ca> Message-ID: <6784.1271805348@localhost> On Tue, 20 Apr 2010 18:03:09 EDT, Simon Perreault said: > This is the latest proposal. The Security Considerations section needs > some love... I may be the only one that finds that unintentionally hilarious. In any case, to a first-order approximation, it doesn't even matter all that much security wise. I mean - let's be *honest* guys. After XP SP2 got any significant market penetration, pretty much everybody had a host-based firewall that defaulted to default-deny, so the NAT-firewall was merely belt and suspenders. Pretty much all the attacks we've seen in the last few years have been things like web drive-bys, trojaned torrents, and other stuff that sails right in through open ports through the firewall (both host and standalone). And any malware that's able to turn around and punch open a port on the host firewall is just as easily able to go and use uPNP to send a "Pants Down!" command to the standalone firewall. (Yes, defense in depth is a Good Thing. But that external firewall isn't doing squat for your security if it actually accepts uPNP from inside.) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From marquis at roble.com Tue Apr 20 18:38:22 2010 From: marquis at roble.com (Roger Marquis) Date: Tue, 20 Apr 2010 16:38:22 -0700 (PDT) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: Message-ID: <20100420233822.28CE02B2127@mx5.roble.com> Jack Bates wrote: > Disable the uPNP (some routers lack it, and yes, it breaks and microsoft > will tell you to get uPNP capable NAT routers or get a new ISP). Thing is, neither of these cheap CPE has UPNP enabled, which leads me to question whether claims regarding large numbers of serverless multi-user game users are accurate. I disable UPNP as standard practice since it is cannot be enabled securely, at least not on cheap CPE. > Your argument has nothing to do with this part of the thread and > discussion of why implementing NAT at a larger scale is bad. I guess it > might have something to do in other tangents of supporting NAT66. I should have been clearer, apologies. WRT LSN, there is no reason individual users couldn't upgrade to a static IP for their insecurely designed multi-user games, and no reason to suspect John Levine's ISP is not representative with 0.16% of its users requesting upgrades. Roger Marquis From marka at isc.org Tue Apr 20 18:54:59 2010 From: marka at isc.org (Mark Andrews) Date: Wed, 21 Apr 2010 09:54:59 +1000 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: Your message of "Wed, 21 Apr 2010 08:01:33 +0930." <67D28817-D47B-468F-9212-186C60531140@internode.com.au> References: <201004200022.o3K0M2Ba007459@aurora.sol.net> <201004200225.o3K2OwVi070153@drugs.dv.isc.org> <4BCD14EF.8090204@zill.net> <201004200320.o3K3KB4s071149@drugs.dv.isc.org> <4BCD203E.3050302@zill.net> <201004200358.o3K3wDQk071509@drugs.dv.isc.org> <67D28817-D47B-468F-9212-186C60531140@internode.com.au> Message-ID: <201004202355.o3KNsxOs087832@drugs.dv.isc.org> In message <67D28817-D47B-468F-9212-186C60531140 at internode.com.au>, Mark Newton writes: > > On 20/04/2010, at 1:28 PM, Mark Andrews wrote: > > > Changing from a public IP address to a private IP address is a big > > change in the conditions of the contract. People do select ISP's > > on the basis of whether they will get a public IP address or a > > private IP address. > > Seems to me your objection is based on whether or not the customer > gets a public address vs a private address. > > There's no need for NAT pools to be RFC1918. Pretty sure everyone > is going to get a public address of some form... it just won't > necessarily be globally unique to them. RFC1918 addresses are not the only source of private addresses. If you are giving out addresses behind a NAT then they are private address. > As for jurisdictional issues: This particular Australian ISP amended > its T&C document to give us the discretion of providing LSN addresses > about two years ago. Will we need to? Perhaps not. But if we do, the > T&C's are already worked out. Looking ahead in time and forecasting > future risks is one of the things businesses are supposed to do, right? Which is a good thing to do. If you are offering a (potentially) degraded service then the customer needs to be informed before they agree to the service. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From dougb at dougbarton.us Tue Apr 20 19:34:47 2010 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 20 Apr 2010 17:34:47 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100421072909.5675eb83@opy.nosense.org> References: <20100420172902.CB3BB2B2121@mx5.roble.com> <20100421072909.5675eb83@opy.nosense.org> Message-ID: <4BCE4827.6070300@dougbarton.us> On 4/20/2010 2:59 PM, Mark Smith wrote: > > Customers never asked for NAT. Ask the non-geek customer if they went > looking for a ISP plan or modem that supports NAT and they'll look at > you funny. Ask them if they want to share their Internet access between > multiple devices in their home, without having to pay extra for the privilege > and they'll say yes. -- ... 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 jbates at brightok.net Tue Apr 20 19:36:59 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 20 Apr 2010 19:36:59 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100420233822.28CE02B2127@mx5.roble.com> References: <20100420233822.28CE02B2127@mx5.roble.com> Message-ID: <4BCE48AB.2070500@brightok.net> Roger Marquis wrote: > Thing is, neither of these cheap CPE has UPNP enabled, which leads me to > question whether claims regarding large numbers of serverless multi-user > game users are accurate. I'd say it's a question for m$. I've seen it break, I've had to reprogram older cpe's that didn't have uPNP enabled to get customers working. I base my assertions on personal experience of managing a medium sized ISP. > > I should have been clearer, apologies. WRT LSN, there is no reason > individual users couldn't upgrade to a static IP for their insecurely > designed multi-user games, and no reason to suspect John Levine's ISP is > not representative with 0.16% of its users requesting upgrades. It's not representative of my ISP, though my 30,000 consumers (we'll ignore more business accounts) may be too small to be indicative of larger networks. Jack From jbates at brightok.net Tue Apr 20 19:38:40 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 20 Apr 2010 19:38:40 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <6784.1271805348@localhost> References: <20100420193147.C69612B2128@mx5.roble.com> <4BCE13E2.2020509@brightok.net> <4BCE249D.7090805@viagenie.ca> <6784.1271805348@localhost> Message-ID: <4BCE4910.1020504@brightok.net> Valdis.Kletnieks at vt.edu wrote: > (Yes, defense in depth is a Good Thing. But that external firewall isn't > doing squat for your security if it actually accepts uPNP from inside.) In this case we are referring to uPNP functionality at a LSN level. uPNP as it sits will not work at all, and security in this case refers not to the customer but to the ISP's router/server performing this service. Jack From cmadams at hiwaay.net Tue Apr 20 19:46:26 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 20 Apr 2010 19:46:26 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <6784.1271805348@localhost> References: <20100420193147.C69612B2128@mx5.roble.com> <4BCE13E2.2020509@brightok.net> <4BCE249D.7090805@viagenie.ca> <6784.1271805348@localhost> Message-ID: <20100421004626.GC1156773@hiwaay.net> Once upon a time, Valdis.Kletnieks at vt.edu said: > In any case, to a first-order approximation, it doesn't even matter all that > much security wise. I mean - let's be *honest* guys. After XP SP2 got any > significant market penetration, pretty much everybody had a host-based firewall > that defaulted to default-deny, so the NAT-firewall was merely belt and > suspenders. Well, that covers the hosts. "Normal" people are adding more devices than PCs all the time, such as network printers (which have a very spotty security record, especially on the cheap end) and disk servers. Network devices like that _can't_ just block all access. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From swmike at swm.pp.se Tue Apr 20 19:58:21 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 21 Apr 2010 02:58:21 +0200 (CEST) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100421004626.GC1156773@hiwaay.net> References: <20100420193147.C69612B2128@mx5.roble.com> <4BCE13E2.2020509@brightok.net> <4BCE249D.7090805@viagenie.ca> <6784.1271805348@localhost> <20100421004626.GC1156773@hiwaay.net> Message-ID: On Tue, 20 Apr 2010, Chris Adams wrote: > than PCs all the time, such as network printers (which have a very > spotty security record, especially on the cheap end) and disk servers. > Network devices like that _can't_ just block all access. Windows XP SP2 and later has the concept of different "zones" (or whatever it's called) where it'll allow things from the local subnet but not from outside of it, if you tell it so. I know people who configure their network printers without default gw to handle their spotty security. I do think the home router should have a stateful firewall and according to what I see in the IETF, this is going to be the recommendation for an IPv6 enabled home gateway. -- Mikael Abrahamsson email: swmike at swm.pp.se From kauer at biplane.com.au Tue Apr 20 20:34:15 2010 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 21 Apr 2010 11:34:15 +1000 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> References: <20100420193147.C69612B2128@mx5.roble.com> <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> Message-ID: <1271813655.6417.431.camel@karl> On Tue, 2010-04-20 at 12:59 -0700, Owen DeLong wrote: > On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote: > > NAT _always_ fails-closed > Stateful Inspection can be implemented fail-closed. Not to take issue with either statement in particular, but I think there needs to be some consideration of what "fail" means. Dealing with an unwanted but foreseeable error condition, like running out of memory, is not a failure mode. It is a controlled event. NOT dealing with it is a failure mode. So a properly written program (or properly constructed device) will deal with whatever error conditions the designer was able to anticipate, and will hopefully deal with them intelligently. Power failure and physical damage are harder to handle than others, but on high-end equipment even some of those are considered and managed. Ideally the designer will have considered all conditions that can possibly arise, but the ideal is not achievable. There will *always* be conditions a program or device is unable to handle or possibly even detect. When a situation arises that is beyond the control of the program or device, was not anticipated by the designer, or if the designer made a mistake, we enter the realm of an actual failure. And all bets are off. NAT (for example) could fail in any way at all - including by (say) inappropriately sharing a mapping. If processes are running on a shared platform - say NAT, routing and packet filtering - failure of any part could cause failure of any other part. In some cases (I seem to recall that recent Californian power failures were an example) the error handling itself can cause another error condition and another opportunity for failure. Reading through the security alerts from any vendor is a pretty sobering process - stuff fails open more often than you might expect. So I think we should be very cautious about saying that things "fail open" or "fail closed". We should be especially cautious about it when the functionality we are interested in is really no more than a happy side effect of some other functionality. NAT's "security", to the extent that it exists at all, is a side effect of what it is intended to do, which is translate and map addresses. 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 joelja at bogus.com Tue Apr 20 21:04:12 2010 From: joelja at bogus.com (joel jaeggli) Date: Tue, 20 Apr 2010 19:04:12 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <1271813655.6417.431.camel@karl> References: <20100420193147.C69612B2128@mx5.roble.com> <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> <1271813655.6417.431.camel@karl> Message-ID: <4BCE5D1C.3020209@bogus.com> On 4/20/2010 6:34 PM, Karl Auer wrote: > On Tue, 2010-04-20 at 12:59 -0700, Owen DeLong wrote: >> On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote: >>> NAT _always_ fails-closed I love this statement particularly in the context of enterprise networks... When you pop the label off an l3 vpn or pseudo wire in the wrong place where does the packet go? Does one even know? does the outside network have overlapping addresses with the inside one, does it have a default route? is there filtering? Is it an opportunity for information leakage? How many parallel networks with overlapping private addressing domains are there on router? your your l3 vpn providers routers? How far will a private address get you when it leaks. These sorts of things I wonder about when I contemplate doing syslog on a q-in-q vlan over a vpls. >> Stateful Inspection can be implemented fail-closed. > > Not to take issue with either statement in particular, but I think there > needs to be some consideration of what "fail" means. > > Dealing with an unwanted but foreseeable error condition, like running > out of memory, is not a failure mode. It is a controlled event. NOT > dealing with it is a failure mode. > > So a properly written program (or properly constructed device) will deal > with whatever error conditions the designer was able to anticipate, and > will hopefully deal with them intelligently. Power failure and physical > damage are harder to handle than others, but on high-end equipment even > some of those are considered and managed. Ideally the designer will have > considered all conditions that can possibly arise, but the ideal is not > achievable. There will *always* be conditions a program or device is > unable to handle or possibly even detect. > > When a situation arises that is beyond the control of the program or > device, was not anticipated by the designer, or if the designer made a > mistake, we enter the realm of an actual failure. And all bets are off. > NAT (for example) could fail in any way at all - including by (say) > inappropriately sharing a mapping. If processes are running on a shared > platform - say NAT, routing and packet filtering - failure of any part > could cause failure of any other part. In some cases (I seem to recall > that recent Californian power failures were an example) the error > handling itself can cause another error condition and another > opportunity for failure. > > Reading through the security alerts from any vendor is a pretty sobering > process - stuff fails open more often than you might expect. > > So I think we should be very cautious about saying that things "fail > open" or "fail closed". > > We should be especially cautious about it when the functionality we are > interested in is really no more than a happy side effect of some other > functionality. NAT's "security", to the extent that it exists at all, is > a side effect of what it is intended to do, which is translate and map > addresses. > > Regards, K. > From cmadams at hiwaay.net Tue Apr 20 21:39:35 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 20 Apr 2010 21:39:35 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100420193147.C69612B2128@mx5.roble.com> <4BCE13E2.2020509@brightok.net> <4BCE249D.7090805@viagenie.ca> <6784.1271805348@localhost> <20100421004626.GC1156773@hiwaay.net> Message-ID: <20100421023935.GD1156773@hiwaay.net> Once upon a time, Mikael Abrahamsson said: > Windows XP SP2 and later has the concept of different "zones" (or whatever > it's called) where it'll allow things from the local subnet but not from > outside of it, if you tell it so. I know people who configure their > network printers without default gw to handle their spotty security. That still requires someone to configure a printer, while most just plug it in and let it DHCP. Also, I needed to update the firmware on a network printer once, and it had to have a gateway because it downloaded the firmware directly. Heck, I have filled up a 5 port switch in my entertainment center now with TiVo, Xbox, Blu-Ray, and TV (plus back-haul); all of those use the Internet and so should have the protection of a firewall at the gateway (and of course the Xbox requires UPnP for some games). The TiVo, Blu-Ray, and possibly TV run Linux, which may be somewhat safer, but Linux has had (and will have) bugs too. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From dave.nanog at alfordmedia.com Tue Apr 20 21:58:33 2010 From: dave.nanog at alfordmedia.com (Dave Pooser) Date: Tue, 20 Apr 2010 21:58:33 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100421080821.7339acae@opy.nosense.org> Message-ID: > Frankly, when you hear people strongly using the argument stateful > firewalling == NAT, you start to wonder if they've ever seen a stateful > firewall using public addresses. I'd hazard a guess that the number of hosts behind NAT gateways is an order of magnitude -- probably two-- greater than the number of hosts behind stateful firewalls using public addresses. It's not that the latter don't exist, it's that economies of scale make the NAT/PAT appliances more widely used and thus more relevant to the discussion. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com From owen at delong.com Tue Apr 20 23:16:10 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 20 Apr 2010 21:16:10 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100421080821.7339acae@opy.nosense.org> References: <20100420193147.C69612B2128@mx5.roble.com> <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> <20100421080821.7339acae@opy.nosense.org> Message-ID: <66C49CF3-0719-4E03-A657-9F380668F3D6@delong.com> > > Frankly, when you hear people strongly using the argument stateful > firewalling == NAT, you start to wonder if they've ever seen a stateful > firewall using public addresses. > I've run several of them. Why do you ask? Owen From owen at delong.com Tue Apr 20 23:27:14 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 20 Apr 2010 21:27:14 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <1271813655.6417.431.camel@karl> References: <20100420193147.C69612B2128@mx5.roble.com> <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> <1271813655.6417.431.camel@karl> Message-ID: On Apr 20, 2010, at 6:34 PM, Karl Auer wrote: > On Tue, 2010-04-20 at 12:59 -0700, Owen DeLong wrote: >> On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote: >>> NAT _always_ fails-closed >> Stateful Inspection can be implemented fail-closed. > > Not to take issue with either statement in particular, but I think there > needs to be some consideration of what "fail" means. > I believe we are talking about the case where some engineer fat-fingers a change and Roger's claim is that a stateful inspection without NAT box will permit unintended traffic while a NAT box will not. My claim is that the stateful inspection box can be implemented such that it has an equally secure set of failure modes for fat-fingering to a NAT+stateful inspection device. > > Reading through the security alerts from any vendor is a pretty sobering > process - stuff fails open more often than you might expect. > Yep. > So I think we should be very cautious about saying that things "fail > open" or "fail closed". > My point is not that they do or do not fail closed, but, that a well designed SI firewall will fail with the exact same security risks as a NAT device. > We should be especially cautious about it when the functionality we are > interested in is really no more than a happy side effect of some other > functionality. NAT's "security", to the extent that it exists at all, is > a side effect of what it is intended to do, which is translate and map > addresses. > IOW, All of NAT's security comes from the fact that it requires a state table, like stateful inspection. Owen From bmanning at vacation.karoshi.com Tue Apr 20 23:34:32 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 21 Apr 2010 04:34:32 +0000 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] Message-ID: <20100421043432.GB25523@vacation.karoshi.com.> and a very pleasant evening. a few questions. IPv6 on your radar? Looking at options for addressing your future v6 needs? Have you looked at the IETF/ID in the subject line? if you think something like this is a good idea, worth persuing, I'd like to hear from you. --bill From mysidia at gmail.com Tue Apr 20 23:39:11 2010 From: mysidia at gmail.com (James Hess) Date: Tue, 20 Apr 2010 23:39:11 -0500 Subject: Reverse DNS Question In-Reply-To: References: Message-ID: On Tue, Apr 20, 2010 at 3:08 PM, James Martin wrote: > All: > In the process of requesting a block of IP's for a client, ARIN requested > that we list Reverse DNS Servers for the block. ?I've never done this > before, nor have I ever thought it through. The Reverse DNS zone is for mapping internet address to hostname. It is a basic requirement for proper DNS functionality that the Internet address of every host maps back to the host's authoritative name. It is important, and cannot be fully explained here, but you should see the relevant RFCs to research the requirements to properly implement Reverse DNS. See, RFC 1912. http://tools.ietf.org/html/rfc1912 for some usage information (Forward-confirmed Reverse DNS) Any good DNS book should contain relevant details about how reverse mapping is implemented in the DNS protocol. Zytrax is one of the well-known online guides http://www.zytrax.com/books/dns/ch3/ The RIRs also have (limited resources) https://www.arin.net/resources/request/reversedns.html APNIC's manual is OK and provides instructions for reverse zone creation, if you ignore APNIC-specific policy details, such as their delegation objects/delegation templates. http://www.apnic.net/__data/assets/pdf_file/0009/9792/Reverse-DNS-manual.pdf This is not necessarily just about sending e-mail, RDNS verification and use of forward-confirmed RDNS may have fallen into some disuse in recent years, with SSH replacing RSH and all, and "hosts.equiv" going away, but, various internet services have been known to reject connections intentionally (or accidentally) if reverse DNS is not setup for an IP address of the peer/requestor, or is not present at all, e.g. many IRC, NNTP, WHOIS, Finger servers. It is a default behavior of TCP Wrappers (#define PARANOID), commonly used to protect programs run by inetd on *ix systems. Authentication/login protocols such as Kerberos also rely on proper RDNS. When IP addresses are allocated to you by a regional registry such as ARIN, or if another provider officially re-assigns and delegates reverse to your IPs, the reverse DNS authority for those IPs becomes your org's responsibility to either manage (or delegate further downstream, using NS records, when appropriate). .. See RFC1035, "Section 3.5. IN-ADDR.ARPA domain " What you supply to ARIN are hostnames of some DNS servers that ARIN will delegate your portions of the reverse DNS space to, from the in-addr.arpa domain. For example, if you were allocated the IP block 192.0.0.0/23 then these would be delegated to your listed reverse DNS servers (by the registry), it is entirely dependant on your allocation: 0.0.192.in-addr.arpa 1.0.192.in-addr.arpa The expectation is that your DNS servers will serve a PTR record in the proper zone for each IP address you have assigned to a host e.g. for that example, your first BIND zone might look like " 0.0.192.in-addr.arpa. IN SOA ns1.example.com. email.addr. ( 2037011800 7200 7200 604800 7200 ) IN NS ns1.example.com. IN NS ns2.example.com. 1 IN PTR ip192-0-0-1.example.com. 2 IN PTR ip192-0-0-2.example.com. 3 IN PTR ip192-0-0-3.example.com. " Assuming "ip192-0-0-1.example.com." resolved to 192.0.0.1, etc, etc... And you would have a second zone for the 192.0.1.* IPs EXCEPT.... that is just an example, don't actually use a hostname like "ip192-0-0-1.example.com." in real life. [*] Certain overly aggressive blacklists assume that the host must be a dynamic / dial-up user due to the presence of "192-0-0-1", which is recognized to be an IP address, so be careful. -- -J From marka at isc.org Tue Apr 20 23:51:37 2010 From: marka at isc.org (Mark Andrews) Date: Wed, 21 Apr 2010 14:51:37 +1000 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: Your message of "Tue, 20 Apr 2010 21:27:14 MST." References: <20100420193147.C69612B2128@mx5.roble.com> <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> <1271813655.6417.431.camel@karl> Message-ID: <201004210451.o3L4pbbS099081@drugs.dv.isc.org> In message , Owen DeLong write s: > > On Apr 20, 2010, at 6:34 PM, Karl Auer wrote: > > > On Tue, 2010-04-20 at 12:59 -0700, Owen DeLong wrote: > >> On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote: > >>> NAT _always_ fails-closed > >> Stateful Inspection can be implemented fail-closed. > > > > Not to take issue with either statement in particular, but I think there > > needs to be some consideration of what "fail" means. > > > I believe we are talking about the case where some engineer fat-fingers > a change and Roger's claim is that a stateful inspection without NAT > box will permit unintended traffic while a NAT box will not. > > My claim is that the stateful inspection box can be implemented such > that it has an equally secure set of failure modes for fat-fingering to > a NAT+stateful inspection device. Especially when the NAT/Router has a enable/disable NAT checkbox. > > Reading through the security alerts from any vendor is a pretty sobering > > process - stuff fails open more often than you might expect. > > > Yep. > > > So I think we should be very cautious about saying that things "fail > > open" or "fail closed". > > > My point is not that they do or do not fail closed, but, that a well designed > SI firewall will fail with the exact same security risks as a NAT device. > > > We should be especially cautious about it when the functionality we are > > interested in is really no more than a happy side effect of some other > > functionality. NAT's "security", to the extent that it exists at all, is > > a side effect of what it is intended to do, which is translate and map > > addresses. > > > IOW, All of NAT's security comes from the fact that it requires a state > table, like stateful inspection. > > Owen > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From franck at genius.com Tue Apr 20 23:53:37 2010 From: franck at genius.com (Franck Martin) Date: Wed, 21 Apr 2010 16:53:37 +1200 (MAGST) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <14466287.746.1271825360873.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <31942984.748.1271825615067.JavaMail.franck@franck-martins-macbook-pro.local> Why don't they use IPv6 instead of uPnP? They control the consumer box (and PS3, XBOX, .... are not cheap boxes) and they control the gaming servers. Look at the feature back to my mac., it opens when possible an IPv6 over IPv4 toredo tunnel, so that apple servers can easily contact back the desktop. If not possible it falls back to NAT traversal with IPv4... http://www.appleinsider.com/articles/08/08/19/apples_secret_back_to_my_mac_push_behind_ipv6.html http://collison.ie/blog/2008/12/leopard-and-back-to-my-mac-tunnels ----- Original Message ----- From: "Chris Adams" To: nanog at nanog.org Sent: Wednesday, 21 April, 2010 2:39:35 PM Subject: Re: Rate of growth on IPv6 not fast enough? Once upon a time, Mikael Abrahamsson said: > Windows XP SP2 and later has the concept of different "zones" (or > whatever it's called) where it'll allow things from the local subnet > but not from > outside of it, if you tell it so. I know people who configure their > network printers without default gw to handle their spotty security. That still requires someone to configure a printer, while most just plug it in and let it DHCP. Also, I needed to update the firmware on a network printer once, and it had to have a gateway because it downloaded the firmware directly. Heck, I have filled up a 5 port switch in my entertainment center now with TiVo, Xbox, Blu-Ray, and TV (plus back-haul); all of those use the Internet and so should have the protection of a firewall at the gateway (and of course the Xbox requires UPnP for some games). The TiVo, Blu-Ray, and possibly TV run Linux, which may be somewhat safer, but Linux has had (and will have) bugs too. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From joelja at bogus.com Tue Apr 20 23:54:15 2010 From: joelja at bogus.com (joel jaeggli) Date: Tue, 20 Apr 2010 21:54:15 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <1271813655.6417.431.camel@karl> References: <20100420193147.C69612B2128@mx5.roble.com> <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> <1271813655.6417.431.camel@karl> Message-ID: <4BCE84F7.3060602@bogus.com> On 4/20/2010 6:34 PM, Karl Auer wrote: > On Tue, 2010-04-20 at 12:59 -0700, Owen DeLong wrote: >> On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote: >>> NAT _always_ fails-closed I love this statement particularly in the context of enterprise networks... When you pop the label off an l3 vpn or pseudo wire in the wrong place where does the packet go? Does one even know? does the outside network have overlapping addresses with the inside one, does it have a default route? is there filtering? Is it an opportunity for information leakage? How many parallel networks with overlapping private addressing domains are there on router? your your l3 vpn providers routers? How far will a private addressed packet go when it leaks. These sorts of things I wonder about when I contemplate doing syslog on a q-in-q vlan over a vpls. >> Stateful Inspection can be implemented fail-closed. > > Not to take issue with either statement in particular, but I think there > needs to be some consideration of what "fail" means. > > Dealing with an unwanted but foreseeable error condition, like running > out of memory, is not a failure mode. It is a controlled event. NOT > dealing with it is a failure mode. > > So a properly written program (or properly constructed device) will deal > with whatever error conditions the designer was able to anticipate, and > will hopefully deal with them intelligently. Power failure and physical > damage are harder to handle than others, but on high-end equipment even > some of those are considered and managed. Ideally the designer will have > considered all conditions that can possibly arise, but the ideal is not > achievable. There will *always* be conditions a program or device is > unable to handle or possibly even detect. > > When a situation arises that is beyond the control of the program or > device, was not anticipated by the designer, or if the designer made a > mistake, we enter the realm of an actual failure. And all bets are off. > NAT (for example) could fail in any way at all - including by (say) > inappropriately sharing a mapping. If processes are running on a shared > platform - say NAT, routing and packet filtering - failure of any part > could cause failure of any other part. In some cases (I seem to recall > that recent Californian power failures were an example) the error > handling itself can cause another error condition and another > opportunity for failure. > > Reading through the security alerts from any vendor is a pretty sobering > process - stuff fails open more often than you might expect. > > So I think we should be very cautious about saying that things "fail > open" or "fail closed". > > We should be especially cautious about it when the functionality we are > interested in is really no more than a happy side effect of some other > functionality. NAT's "security", to the extent that it exists at all, is > a side effect of what it is intended to do, which is translate and map > addresses. > > Regards, K. > From dts at senie.com Tue Apr 20 23:58:27 2010 From: dts at senie.com (Daniel Senie) Date: Wed, 21 Apr 2010 00:58:27 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100420193147.C69612B2128@mx5.roble.com> Message-ID: <554C226C-D3AB-4237-A096-00D8250BFF8D@senie.com> On Apr 20, 2010, at 3:55 PM, Joe Abley wrote: > > On 2010-04-20, at 15:31, Roger Marquis wrote: > >> If this were really an issue I'd expect my nieces and nephews, all of whom are big >> game players, would have mentioned it. They haven't though, despite being behind >> cheap NATing CPE from D-Link and Netgear. > > I have heard it said before that there is significant cooperation and/or software engineering work between some or all of those who make residential gateways and those who make multi-player games to achieve this end result. The opinion I heard vocalised at the time was that it would have been a lot easier to reach this state of affairs if there had been standardisation of NAT in v4 at an early stage. As it is, peer-to-peer apps like games require significant if-then-else to make anything work. Please go read RFC3235. Also please go read some history. This RFC and others that came out of the NAT working group in the IETF were an attempt to document what NAT was, in its various flavors, and NOT to standardize it in any way. Those of us working on the effort faced voices of opposition at every turn, not for trying to standardize it, but just to DOCUMENT it. During the writing of the drafts that became 3235, I was approached by folks working on gaming, and indeed you will find therein a reference to exactly that. What the gamers wanted was a way to punch a hole out in normal NAT fashion for UDP packets with a given port mapping, but then have less stringent matching on subsequent return packets. > >> Address conservation aside, the main selling point of NAT is its filtering of inbound >> session requests. > > If that was all that was required, you could sell a stateful firewall that didn't do NAT, and everybody would buy that instead because it would make things like iChat AV break less. Apparently there are other reasons to buy and sell devices that NAT (e.g. my ISP gives me one address, but the laptop and the Wii both want to use the internet). Implementing stateful inspection firewall code is rather straightforward. Adding NAT functionality to it adds a small number of additional instructions in the forwarding path, enabled only as needed depending on configuration. The NAT part of it is a trivial additional step, nothing more. The point, though, is when dialup and later DSL and cable connections originally came out, ISPs didn't (and in general wouldn't, or wouldn't without a substantial additional fee) give out blocks of addresses to customers. It was the mismatch of customer need and ISP offerings that led to the implementation of NAT in the router products at the vendor I worked at in the early 1990s. In the end, this is all really good lounge discussion, but has nothing to do with network operations and the purpose of the main NANOG list. It doesn't even have anything to do with the subject line of the threat to which it's attached. From owen at delong.com Wed Apr 21 00:29:07 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 20 Apr 2010 22:29:07 -0700 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <20100421043432.GB25523@vacation.karoshi.com.> References: <20100421043432.GB25523@vacation.karoshi.com.> Message-ID: <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> While I think this is an improvement, unless the distribution of ULA-C is no cheaper and no easier to get than GUA, I still think there is reason to believe that it is likely ULA-C will become de facto GUA over the long term. As such, I still think the current draft is a bad idea absent appropriate protections in RIR policy. Owen On Apr 20, 2010, at 9:34 PM, bmanning at vacation.karoshi.com wrote: > > and a very pleasant evening. > > a few questions. > > IPv6 on your radar? > Looking at options for addressing your future v6 needs? > > Have you looked at the IETF/ID in the subject line? > > if you think something like this is a good idea, worth > persuing, I'd like to hear from you. > > > --bill From dts at senie.com Wed Apr 21 00:46:47 2010 From: dts at senie.com (Daniel Senie) Date: Wed, 21 Apr 2010 01:46:47 -0400 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> Message-ID: I see a need for stable, permanent blocks of addresses within an organization. For example, a branch office connecting to a central office over VPN: firewall rules need to be predictable. If the branch office' IPv6 block changes, much access will break. This is directly analogous to how RFC1918 space is used today in such environments. There is a need to have organizations be able to either self-assign or RIR-assign space that they own and can use without trouble within their network. That address space need not be routable on the public networks. In general I think this draft has merit. On Apr 21, 2010, at 1:29 AM, Owen DeLong wrote: > While I think this is an improvement, unless the distribution of ULA-C is no cheaper > and no easier to get than GUA, I still think there is reason to believe that it is likely > ULA-C will become de facto GUA over the long term. > > As such, I still think the current draft is a bad idea absent appropriate protections in > RIR policy. > > Owen > > On Apr 20, 2010, at 9:34 PM, bmanning at vacation.karoshi.com wrote: > >> >> and a very pleasant evening. >> >> a few questions. >> >> IPv6 on your radar? >> Looking at options for addressing your future v6 needs? >> >> Have you looked at the IETF/ID in the subject line? >> >> if you think something like this is a good idea, worth >> persuing, I'd like to hear from you. >> >> >> --bill > > From kauer at biplane.com.au Wed Apr 21 00:49:51 2010 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 21 Apr 2010 15:49:51 +1000 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100420193147.C69612B2128@mx5.roble.com> <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> <1271813655.6417.431.camel@karl> Message-ID: <1271828991.6417.528.camel@karl> On Tue, 2010-04-20 at 21:27 -0700, Owen DeLong wrote: > I believe we are talking about the case where some engineer > fat-fingers a change and Roger's claim is that a stateful inspection > without NAT box will permit unintended traffic while a NAT box will > not. Possibly restating Mark's point, but if fat fingers are allowed as a source of failure, impact is unlimited. > IOW, All of NAT's security comes from the fact that it requires a > state table, like stateful inspection. > Er - I think it's a deeper point I was making. To the extent that NAT offers security at all, that security comes as an *unintentional side effect* of the job it is actually designed to do. That is, the NAT device *does not care* about its "security" function. 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 cmorris at cs.odu.edu Wed Apr 21 00:54:38 2010 From: cmorris at cs.odu.edu (Charles Morris) Date: Wed, 21 Apr 2010 01:54:38 -0400 Subject: iabelle francois Message-ID: http://www.os-bc.de/home.php -- Charles Morris cmorris at cs.odu.edu, cmorris at occs.odu.edu Network Security Administrator, Software Developer Office of Computing and Communications Services, CS Systems Group Old Dominion University http://www.cs.odu.edu/~cmorris From jim at reptiles.org Wed Apr 21 01:31:44 2010 From: jim at reptiles.org (Jim Mercer) Date: Wed, 21 Apr 2010 02:31:44 -0400 Subject: Reverse DNS Question In-Reply-To: References: Message-ID: <20100421063143.GA57214@reptiles.org> On Tue, Apr 20, 2010 at 10:26:17AM -1000, Antonio Querubin wrote: > On Tue, 20 Apr 2010, James Martin wrote: > >What is the purpose for this besides resolving name-based reverse lookups? > >Are there any definitive guides out there on how this works (besides the > >ARIN site)? > > It's for resolving address-based lookups. When ARIN allocates address > space to you, you now become responsible for the reverse-lookups for that > allocated address range. with forward DNS, anyone can map a domain to any arbitrary IP address, such as mapping www.example.com to the same IP address as big-popular-bank.com. there is nothing to prevent this, and in some cases it is acceptable, and in some cases, possibly nefarious. when the registeries (ARIN/RIPE/APNIC/etc) require the "owner" of an ip block to define name servers for reverse maps, it provides a mechanism to double check if a domain/ip-addr map is valid. it isn't 100%, for sure, but, it is substantially better than nothing. in this sense, www.example.com can have an A record of 192.168.1.1 and, through the reverse map, 1.1.168.192.in-addr.arpa will have a PTR record of "www.example.com" in fact, there can be multiple PTR records, in case you have multiple domains pointing at the same IP address. on many unix(-ish) systems, the "host" command will show you the reverse PTR record, if you run: host 192.168.1.1 , it might show: user at hostname% host 192.168.1.1 1.1.168.192.in-addr.arpa domain name pointer www.example.com. keep in mind, this will only work if the name servers registered for the ip block actually contain data. check out: http://en.wikipedia.org/wiki/Reverse_DNS_lookup and, go to "Guide to reverse zones" in: http://www.apnic.net/__data/assets/pdf_file/0009/9792/Reverse-DNS-manual.pdf hope this is helpful -- Jim Mercer jim at reptiles.org +92 336 520-4504 "I'm Prime Minister of Canada, I live here and I'm going to take a leak." - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, "Who are you and where are you going?" From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Apr 21 04:57:24 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 21 Apr 2010 19:27:24 +0930 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> Message-ID: <20100421192724.020130df@opy.nosense.org> On Wed, 21 Apr 2010 01:46:47 -0400 Daniel Senie wrote: > I see a need for stable, permanent blocks of addresses within an organization. For example, a branch office connecting to a central office over VPN: firewall rules need to be predictable. If the branch office' IPv6 block changes, much access will break. This is directly analogous to how RFC1918 space is used today in such environments. > > There is a need to have organizations be able to either self-assign or RIR-assign space that they own and can use without trouble within their network. That address space need not be routable on the public networks. > > In general I think this draft has merit. > Unique Local Adresses, of which the linked draft is specifying a subset, were specified in RFC4193, published in October 2005. They meet all the requirements you've stated. You might also want to have a look at RFC3879, "Deprecating Site Local Addresses" for the reasons why IPv6 Site Local addresses, the direct IPv6 equivalent of RFC1918 addresses, were deprecated. Many of the reasons provided also apply to using IPv4 RFC1918 addresses. This draft is about a centralised registry for one half of the ULA space. It is debatable whether it is necessary, as ULAs shouldn't leak out of a site using them. The major concern is that if they are globally registered, then some people will start believing that they can use them as global addresses, and start demanding other parties such as their ISP or IXes route them, instead of getting proper global addresses for that purpose. As an example of the risks, an informal registry for non-central ULAs has been created at sixxs.net. As a single ULA /48 should be enough for most organisations, looking at the list, it seems that some people are already attempting an addressing 'land grab'. I can't even reach the website of one of the people who as registered 7 /48s. It's a bit hard to believe he has a large enough network to need 458 752 subnets ... http://www.sixxs.net/tools/grh/ula/list/ I think the fact that people have listed them there also means that they now think they now globally 'own' those addresses, and should there be a (very unlikely) collision, would argue that the address space was theirs first and point to that list. While duplicated ULAs shouldn't happen, it shouldn't matter if it does, unless those two organisations want to interconnect directly. ULAs are meant to be stable addressing for inside of your network. They are not meant to be leaked outside your network under most circumstances. The only time routes for your ULA address space may appear outside of your network is if you have a direct link to another organisation (i.e. a backdoor link), and you want to avoid using your Internet transit to reach them and vice-versa. In BGP terms, when you announce some of your ULA address space to the other organisation, you'd attach a NO_EXPORT community. Regards, Mark. From lists at quux.de Wed Apr 21 05:12:19 2010 From: lists at quux.de (Jens Link) Date: Wed, 21 Apr 2010 12:12:19 +0200 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100420145332.58995.qmail@joyce.lan> (John Levine's message of "20 Apr 2010 14\:53\:32 -0000") References: <20100420145332.58995.qmail@joyce.lan> Message-ID: <87tyr5ru64.fsf@bowmore.quux.de> John Levine writes: > I'm not saying that NAT is wonderful, but my experience, in which day > to day stuff all works fine, is utterly different from the doom and > disaster routinely predicted here. Ever tried too troubleshoot networks which where using multiple NAT? Every time I have to I'll have the urge to get really drunk afterwards. And when ISPs start using NAT for their customers, there will be more problems leading to more support calls. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From lists at quux.de Wed Apr 21 05:17:19 2010 From: lists at quux.de (Jens Link) Date: Wed, 21 Apr 2010 12:17:19 +0200 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: (John R. Levine's message of "20 Apr 2010 11\:29\:59 -0400") References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> Message-ID: <87pr1trtxs.fsf@bowmore.quux.de> "John R. Levine" writes: >> Did you run any services? > > Of course not, it's consumer DSL. I run services on my server which is > somewhere else and tunnel in via ssh which, of course, works fine > through NAT. Take a look at all those small SOHO storage boxes. They all offer web and FTP services and they all support something like dyndns. Customers want these features and are using these features. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Apr 21 05:38:26 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 21 Apr 2010 20:08:26 +0930 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <66C49CF3-0719-4E03-A657-9F380668F3D6@delong.com> References: <20100420193147.C69612B2128@mx5.roble.com> <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> <20100421080821.7339acae@opy.nosense.org> <66C49CF3-0719-4E03-A657-9F380668F3D6@delong.com> Message-ID: <20100421200826.4c815743@opy.nosense.org> On Tue, 20 Apr 2010 21:16:10 -0700 Owen DeLong wrote: > > > > Frankly, when you hear people strongly using the argument stateful > > firewalling == NAT, you start to wonder if they've ever seen a stateful > > firewall using public addresses. > > > I've run several of them. > My comment wasn't a reply to you, more of a general comment about the surprising effort you still need to go to explain that stateful firewalling doesn't mandate NAT. I sometimes wonder if some people's heads would explode if I told them that this PC is directly attached to the Internet, has both public IPv4 and IPv6 addresses, and is performing stateful firewalling - with no NAT anywhere. Regards, Mark. From jgreco at ns.sol.net Wed Apr 21 07:26:42 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 21 Apr 2010 07:26:42 -0500 (CDT) Subject: the alleged evils of NAT, In-Reply-To: <87pr1trtxs.fsf@bowmore.quux.de> from "Jens Link" at Apr 21, 2010 12:17:19 PM Message-ID: <201004211226.o3LCQhqd029003@aurora.sol.net> > "John R. Levine" writes: > >> Did you run any services? > > > > Of course not, it's consumer DSL. I run services on my server which is > > somewhere else and tunnel in via ssh which, of course, works fine > > through NAT. > > Take a look at all those small SOHO storage boxes. They all offer web > and FTP services and they all support something like dyndns. Customers > want these features and are using these features. For any such feature on such devices, it would be more honest for the purposes of debate to state that as "Some customers want these features [...]" which is completely true. There are a lot of features in a lot of devices that are never used by (a few, some, most, etc) end users, and even where they are used, the existence of web or ftp services on a storage appliance may merely mean that a user finds it more convenient to access the device locally that way... rather than setting up SMB etc. It certainly does not imply that all customers who buy the SuperStorageDeviceWithFTPCapability are running public FTP archives and that NAT becomes a problem for the owners of all those devices. It may be a problem for a percentage of them, though. ... 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 jimb at jsbc.cc Wed Apr 21 07:46:47 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Wed, 21 Apr 2010 05:46:47 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100421200826.4c815743@opy.nosense.org> References: <20100420193147.C69612B2128@mx5.roble.com> <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> <20100421080821.7339acae@opy.nosense.org> <66C49CF3-0719-4E03-A657-9F380668F3D6@delong.com> <20100421200826.4c815743@opy.nosense.org> Message-ID: <4BCEF3B7.8050102@jsbc.cc> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/21/2010 03:38, Mark Smith wrote: > On Tue, 20 Apr 2010 21:16:10 -0700 Owen DeLong > wrote: > >>> >>> Frankly, when you hear people strongly using the argument >>> stateful firewalling == NAT, you start to wonder if they've >>> ever seen a stateful firewall using public addresses. >>> >> I've run several of them. >> > > My comment wasn't a reply to you, more of a general comment about > the surprising effort you still need to go to explain that > stateful firewalling doesn't mandate NAT. > > I sometimes wonder if some people's heads would explode if I told > them that this PC is directly attached to the Internet, has both > public IPv4 and IPv6 addresses, and is performing stateful > firewalling - with no NAT anywhere. > I hear ya. Except for simple translations (e.g. one-to-one, whole net xlates), NAT is dependent on SPI, but SPI is not dependent on NAT. But some seem to combine the two into a single inseparable concept. I've definitely run into people who confuse the concepts. And also presume that without NAT there is less or no security. This head definitely wouldn't explode, since back in the early to mid 90s I ran enterprise networks on which all hosts had public IPs and there was no NAT at all. First protected by "dumb filters" on routers, which were fairly quickly replaced by dedicated SPI firewalls (such as Checkpoint). The first couple SPI firewalls I used didn't even *have* NAT capability. Yet, they did a fine job securing my LANs without it. And this is at a time when most workstations and servers on the LAN didn't have firewalls themselves (no OS included FW). Despite it doing the job it was intended to do, I've always seen NAT as a bit of an ugly hack, with potential to get even uglier with LSN and multi-level NAT in the future. I personally welcome a return to a NAT-less world with IPv6. :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvO87cACgkQ2fXFxl4S7sSzQQCfU4Ip5mHkJ/inTfKO/1zih5yY VWUAnjte4aAbrcYvUraMXsUmaPj2JHGA =S3Gn -----END PGP SIGNATURE----- From cmadams at hiwaay.net Wed Apr 21 08:24:28 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 21 Apr 2010 08:24:28 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <31942984.748.1271825615067.JavaMail.franck@franck-martins-macbook-pro.local> References: <14466287.746.1271825360873.JavaMail.franck@franck-martins-macbook-pro.local> <31942984.748.1271825615067.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <20100421132428.GA1129656@hiwaay.net> Once upon a time, Franck Martin said: > Why don't they use IPv6 instead of uPnP? UPnP (or something like it) is needed for any kind of firewall for some devices. At least on Xbox, some games are essentially peer-to-peer; when userA starts it up and invites friends, their Xbox becomes the game server. The other people joining the game talk directly to userA's Xbox (they don't go through a Microsoft Xbox Live server). When userA sets up the game, their Xbox sends a UPnP request to the local firewall to open up a port so outside connections can come in. It doesn't matter if there is IPv4, IPv6, NAT, etc. in play; the Xbox is saying "let the Internet talk to me on port foo for a bit". Now, the security model (or lack thereof) of UPnP can be debated, but home users are going to need something like that for peer-to-peer networking. IPv6 is supposed to bring back end-to-end networking and abolish NAT, but I think most people agree that the average home user will still need a basic statefull firewall for protection, which means there has to be a protocol for some devices to temporarily open up ports on the firewall (or there's still no end-to-end). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From morrowc.lists at gmail.com Wed Apr 21 08:25:46 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 21 Apr 2010 09:25:46 -0400 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> Message-ID: On Wed, Apr 21, 2010 at 1:29 AM, Owen DeLong wrote: > While I think this is an improvement, unless the distribution of ULA-C is no cheaper > and no easier to get than GUA, I still think there is reason to believe that it is likely > ULA-C will become de facto GUA over the long term. > > As such, I still think the current draft is a bad idea absent appropriate protections in > RIR policy. I agree with owen, mostly... except I think we should just push RIR's to make GUA accessible to folks that need ipv6 adress space, regardless of connectiivty to thegreater 'internet' (for some definition of that thing). ULA of all types causes headaches on hosts, routers, etc. There is no reason to go down that road, just use GUA (Globally Unique Addresses). -Chris From dts at senie.com Wed Apr 21 08:42:53 2010 From: dts at senie.com (Daniel Senie) Date: Wed, 21 Apr 2010 09:42:53 -0400 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> Message-ID: <54172322-02CC-4303-AEAC-AE9FF1EBB4EA@senie.com> On Apr 21, 2010, at 9:25 AM, Christopher Morrow wrote: > On Wed, Apr 21, 2010 at 1:29 AM, Owen DeLong wrote: >> While I think this is an improvement, unless the distribution of ULA-C is no cheaper >> and no easier to get than GUA, I still think there is reason to believe that it is likely >> ULA-C will become de facto GUA over the long term. >> >> As such, I still think the current draft is a bad idea absent appropriate protections in >> RIR policy. > > I agree with owen, mostly... except I think we should just push RIR's > to make GUA accessible to folks that need ipv6 adress space, > regardless of connectiivty to thegreater 'internet' (for some > definition of that thing). > > ULA of all types causes headaches on hosts, routers, etc. There is no > reason to go down that road, just use GUA (Globally Unique Addresses). > > -Chris Failure to provide an ULA mechanism will result in self assignment from the spaces not yet made available for allocation. Down that road we will find history repeating itself. The reason I see a use in ULA-C is to ensure there is a way for cooperating organizations (whether within or between enterprises) to have addressing that will not overlap for private interconnects. If the RIRs will give out the space to end users and not charge a fortune for it, there may be a chance of that working. It is less clear whether this is within the business model or mission of the RIRs, though, to hand out very small chucks of address space to a very large number of organizations for address space that will not be routed. Of course if the ULA approach does gain acceptance, you'll have a LOT easier time deciding which blocks of addresses to permit and deny in your BGP sessions and packet filters on your borders. From Olivier.Bonaventure at uclouvain.be Wed Apr 21 08:42:32 2010 From: Olivier.Bonaventure at uclouvain.be (Olivier Bonaventure) Date: Wed, 21 Apr 2010 15:42:32 +0200 Subject: BGP-add-path analyser Message-ID: <4BCF00C8.6040306@uclouvain.be> Hello, The IDR working group of the IETF has worked during the last years on the development of BGP extensions that allow a BGP router to advertise several paths towards the same prefix over a BGP session. This feature, usually called add-apths, is being implemented by router vendors and network operators are considering its deployment. To allow network operators to better understand the possible impact of BGP add-path in their network, we have enhanced a BGP simulator to support this feature and developped an analyser on top of this simulator. Based on a model of the network that can be developped with the IGP topology, the iBGP sessions and the routes received over eBGP sessions, the analyser computes metrics such as : - Number of messages exchanged (eBGP, iBGP, withdraws, updates) during an event - Control plane convergence time (time between first and last BGP message) of an event - Number of paths in Adj-Rib-Ins - Availability of path diversity (at least two different nexthops) for fast convergence - Path optimality for Hot Potato Routing (IGP costs to the nexthops) The simulator supports the different add-path selection modes that are discussed with the IETF. We have used the tool on the Abilene network whose configuration is publically available and you can find the results at http://inl.info.ucl.ac.be/softwares/add-paths-analyser-work-progress The simulator and the analyser tool were written by Virginie Van den Schrieck. They are both publically available : http://inl.info.ucl.ac.be/softwares/simbgp-addpaths-support http://inl.info.ucl.ac.be/softwares/add-paths-analyser-work-progress Feel free to contact Virginie for additional information or if you would like to use the analyser on your network. Best regards, Olivier Bonaventure From clapidus at gmail.com Wed Apr 21 08:49:07 2010 From: clapidus at gmail.com (Claudio Lapidus) Date: Wed, 21 Apr 2010 10:49:07 -0300 Subject: Mail Submission Protocol Message-ID: Hello all, At our ISP operation, we are seeing increasing levels of traffic in our outgoing MTA's, presumably due to spammers abusing some of our subscribers' accounts. In fact, we are seeing connections from IPs outside of our network as many as ten times of that from inside IPs. Probably all of our customers are travelling abroad and sending back a lot of postcards, but just in case... ;-) So we are considering ways to further filter this traffic. We are evaluating implementation of MSA through port 587. However, we never did this and would like to know of others more knowledgeable of their experiences. The question is what best practices and stories do you guys have to share in this regard. Also please let me know if you need additional detail. thanks in advance, cl. From bdflemin at gmail.com Wed Apr 21 08:51:42 2010 From: bdflemin at gmail.com (Brad Fleming) Date: Wed, 21 Apr 2010 08:51:42 -0500 Subject: Juniper firewalls - SSG or SRX In-Reply-To: References: Message-ID: <72379FC0-5839-48A6-8B98-7AF6C9C60233@gmail.com> On Apr 19, 2010, at 7:32 PM, Jeffrey Negro wrote: > Has anyone on Nanog had any hands on experience with the lower end > of the > new SRX series Junipers? We're looking to purchase two new > firewalls, and > I'm debating going with SSG series or to make the jump to the SRX > line. Any > input, especially about the learning curve jumping from ScreenOS to > JunOS > would be greatly appreciated. Thank you in advance. > My general take: Hardware == Well built and designed, very robust. The only thing 2 things I'd like to see are: 1) a field-replaceable CF card like the J- series (bonus points if there's a backup like the J's as well!) and 2) a 2-port T1 mPIM card. Software == Not horrible but far from great. We have issues with: Ethernet switching not functioning correctly, IPv6 not wanting to work on Enet switched VLANs, IP-IP tunnels acting very "weird", gmd crashing when trying to commit randomly, and lack of pretty much all IPv6 security features. I'd like to see Juniper really focus on getting the "branch" SRX software up-to-snuff especially in regards to IPv6 security features. I think they're working pretty hard on it but I haven't seen the fruits of their labor yet! From dwhite at olp.net Wed Apr 21 08:57:33 2010 From: dwhite at olp.net (Dan White) Date: Wed, 21 Apr 2010 08:57:33 -0500 Subject: Mail Submission Protocol In-Reply-To: References: Message-ID: <20100421135733.GA4738@dan.olp.net> On 21/04/10?10:49?-0300, Claudio Lapidus wrote: >Hello all, > >At our ISP operation, we are seeing increasing levels of traffic in our >outgoing MTA's, presumably due to spammers abusing some of our subscribers' >accounts. In fact, we are seeing connections from IPs outside of our network >as many as ten times of that from inside IPs. Probably all of our customers >are travelling abroad and sending back a lot of postcards, but just in >case... ;-) > >So we are considering ways to further filter this traffic. We are evaluating >implementation of MSA through port 587. However, we never did this and would >like to know of others more knowledgeable of their experiences. The question >is what best practices and stories do you guys have to share in this regard. >Also please let me know if you need additional detail. Depending on what level of pain you want to inflict on your roaming users: 1) Require them to smtp auth to your server when sending mail 2) Require them to use the local SMTP of the server they are connected to, and do not allow remote relay at all. 3) Require them to send mail via a webmail interface when they are not on your local network I would not think that using port 587 is going to work in many cases, such as from Hotel wireless networks. -- Dan White From mwalter at 3z.net Wed Apr 21 09:05:34 2010 From: mwalter at 3z.net (Mike Walter) Date: Wed, 21 Apr 2010 10:05:34 -0400 Subject: Mail Submission Protocol In-Reply-To: References: Message-ID: We have had very good luck with using port 587 and requiring the users to authenticate to send email from outside our network. Inside customers, we have not changed to force port 587 and authentication for email clients, but the topic has come up in discussions. This won't of course, stop spammers if they are hijacking the users local email client settings. -Mike -----Original Message----- From: Claudio Lapidus [mailto:clapidus at gmail.com] Sent: Wednesday, April 21, 2010 9:49 AM To: nanog at nanog.org Subject: Mail Submission Protocol Hello all, At our ISP operation, we are seeing increasing levels of traffic in our outgoing MTA's, presumably due to spammers abusing some of our subscribers' accounts. In fact, we are seeing connections from IPs outside of our network as many as ten times of that from inside IPs. Probably all of our customers are travelling abroad and sending back a lot of postcards, but just in case... ;-) So we are considering ways to further filter this traffic. We are evaluating implementation of MSA through port 587. However, we never did this and would like to know of others more knowledgeable of their experiences. The question is what best practices and stories do you guys have to share in this regard. Also please let me know if you need additional detail. thanks in advance, cl. From dts at senie.com Wed Apr 21 09:06:12 2010 From: dts at senie.com (Daniel Senie) Date: Wed, 21 Apr 2010 10:06:12 -0400 Subject: Mail Submission Protocol In-Reply-To: <20100421135733.GA4738@dan.olp.net> References: <20100421135733.GA4738@dan.olp.net> Message-ID: <3788B3D6-36F4-4704-A846-826E4D1BC174@senie.com> On Apr 21, 2010, at 9:57 AM, Dan White wrote: > On 21/04/10 10:49 -0300, Claudio Lapidus wrote: >> Hello all, >> >> At our ISP operation, we are seeing increasing levels of traffic in our >> outgoing MTA's, presumably due to spammers abusing some of our subscribers' >> accounts. In fact, we are seeing connections from IPs outside of our network >> as many as ten times of that from inside IPs. Probably all of our customers >> are travelling abroad and sending back a lot of postcards, but just in >> case... ;-) >> >> So we are considering ways to further filter this traffic. We are evaluating >> implementation of MSA through port 587. However, we never did this and would >> like to know of others more knowledgeable of their experiences. The question >> is what best practices and stories do you guys have to share in this regard. >> Also please let me know if you need additional detail. > > Depending on what level of pain you want to inflict on your roaming users: > > 1) Require them to smtp auth to your server when sending mail SMTP AUTH on port 587, preferably with SSL/TLS. > 2) Require them to use the local SMTP of the server they are connected to, > and do not allow remote relay at all. Good way to not have customers. > 3) Require them to send mail via a webmail interface when they are not on > your local network > > I would not think that using port 587 is going to work in many cases, such > as from Hotel wireless networks. Port 587 connectivity has survived almost every public access and hotel access system I've ever tried. Port 25 is often blocked or hijacked. > > -- > Dan White From johnl at iecc.com Wed Apr 21 09:13:31 2010 From: johnl at iecc.com (John Levine) Date: 21 Apr 2010 14:13:31 -0000 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <87tyr5ru64.fsf@bowmore.quux.de> Message-ID: <20100421141331.64547.qmail@joyce.lan> >And when ISPs start using NAT for their customers, there will be more >problems leading to more support calls. You say this as though they don't do it now. R's, John From leen at consolejunkie.net Wed Apr 21 09:14:01 2010 From: leen at consolejunkie.net (Leen Besselink) Date: Wed, 21 Apr 2010 16:14:01 +0200 Subject: Mail Submission Protocol In-Reply-To: References: Message-ID: <20100421141359.GA20980@apia.perrit.net> On Wed, Apr 21, 2010 at 10:49:07AM -0300, Claudio Lapidus wrote: > Hello all, > Hello Claudio, > At our ISP operation, we are seeing increasing levels of traffic in our > outgoing MTA's, presumably due to spammers abusing some of our subscribers' > accounts. In fact, we are seeing connections from IPs outside of our network > as many as ten times of that from inside IPs. Probably all of our customers > are travelling abroad and sending back a lot of postcards, but just in > case... ;-) > I presume you use SMTP-authentication ? That way it's easy to see what users are sending a lot of mail (or more then usual). > So we are considering ways to further filter this traffic. We are evaluating > implementation of MSA through port 587. However, we never did this and would > like to know of others more knowledgeable of their experiences. The question > is what best practices and stories do you guys have to share in this regard. > Also please let me know if you need additional detail. > We added SSL to our SMTP-service and tell our customers to use SSL (not TLS) with authentication and have the mailserver listen on the TCP-ports which the mailclients pick for that (of which their are a few if I'm not mistaken). We've found having to tell clients port-numbers sounds complicated and technical, but telling people to use encryption sounds like a good service and in most cases it just works (we ask the name of the e-mail client before we give them any settings). Also because port 25 is blocked in a lot of places, when people travel with laptops. The mailservers log the IP-adress and username from the authentication, that will hopefully allow us to easily play whack-a-mole when confronted with the problem you might be having. > thanks in advance, > cl. > From leen at consolejunkie.net Wed Apr 21 09:16:57 2010 From: leen at consolejunkie.net (Leen Besselink) Date: Wed, 21 Apr 2010 16:16:57 +0200 Subject: Mail Submission Protocol In-Reply-To: References: Message-ID: <20100421141655.GA27083@apia.perrit.net> On Wed, Apr 21, 2010 at 10:05:34AM -0400, Mike Walter wrote: > We have had very good luck with using port 587 and requiring the users > to authenticate to send email from outside our network. > > Inside customers, we have not changed to force port 587 and > authentication for email clients, but the topic has come up in > discussions. This won't of course, stop spammers if they are hijacking > the users local email client settings. > It does however help find the user more easily (if the mailserver logs the username), you can even automate sending an email to them and block them from sending any further email (with exception to support-staff for example). > -Mike > > -----Original Message----- > From: Claudio Lapidus [mailto:clapidus at gmail.com] > Sent: Wednesday, April 21, 2010 9:49 AM > To: nanog at nanog.org > Subject: Mail Submission Protocol > > Hello all, > > At our ISP operation, we are seeing increasing levels of traffic in our > outgoing MTA's, presumably due to spammers abusing some of our > subscribers' > accounts. In fact, we are seeing connections from IPs outside of our > network > as many as ten times of that from inside IPs. Probably all of our > customers > are travelling abroad and sending back a lot of postcards, but just in > case... ;-) > > So we are considering ways to further filter this traffic. We are > evaluating > implementation of MSA through port 587. However, we never did this and > would > like to know of others more knowledgeable of their experiences. The > question > is what best practices and stories do you guys have to share in this > regard. > Also please let me know if you need additional detail. > > thanks in advance, > cl. > > From nderitualex at gmail.com Wed Apr 21 09:18:03 2010 From: nderitualex at gmail.com (Alex Kamiru) Date: Wed, 21 Apr 2010 17:18:03 +0300 Subject: Mail Submission Protocol In-Reply-To: References: Message-ID: <1271859483.3681.25.camel@akamiru> >>Inside customers, we have not changed to force port 587 and >>authentication for email clients, but the topic has come up in >>discussions. This won't of course, stop spammers if they are hijacking >>the users local email client settings. How best would you stop spammers hijacking local users email clients -Mike -----Original Message----- From: Claudio Lapidus [mailto:clapidus at gmail.com] Sent: Wednesday, April 21, 2010 9:49 AM To: nanog at nanog.org Subject: Mail Submission Protocol Hello all, At our ISP operation, we are seeing increasing levels of traffic in our outgoing MTA's, presumably due to spammers abusing some of our subscribers' accounts. In fact, we are seeing connections from IPs outside of our network as many as ten times of that from inside IPs. Probably all of our customers are travelling abroad and sending back a lot of postcards, but just in case... ;-) So we are considering ways to further filter this traffic. We are evaluating implementation of MSA through port 587. However, we never did this and would like to know of others more knowledgeable of their experiences. The question is what best practices and stories do you guys have to share in this regard. Also please let me know if you need additional detail. thanks in advance, cl. From drc at virtualized.org Wed Apr 21 09:23:10 2010 From: drc at virtualized.org (David Conrad) Date: Wed, 21 Apr 2010 07:23:10 -0700 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> Message-ID: <22565F5E-D9B8-48A4-AE08-C0BE94A7D6C2@virtualized.org> On Apr 21, 2010, at 6:25 AM, Christopher Morrow wrote: > I agree with owen, mostly... except I think we should just push RIR's > to make GUA accessible to folks that need ipv6 adress space, > regardless of connectiivty to thegreater 'internet' (for some > definition of that thing). See RFC 1814. Fun how history repeats itself. Regards, -drc From morrowc.lists at gmail.com Wed Apr 21 09:54:28 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 21 Apr 2010 10:54:28 -0400 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <54172322-02CC-4303-AEAC-AE9FF1EBB4EA@senie.com> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <54172322-02CC-4303-AEAC-AE9FF1EBB4EA@senie.com> Message-ID: On Wed, Apr 21, 2010 at 9:42 AM, Daniel Senie wrote: > > On Apr 21, 2010, at 9:25 AM, Christopher Morrow wrote: > >> On Wed, Apr 21, 2010 at 1:29 AM, Owen DeLong wrote: >>> While I think this is an improvement, unless the distribution of ULA-C is no cheaper >>> and no easier to get than GUA, I still think there is reason to believe that it is likely >>> ULA-C will become de facto GUA over the long term. >>> >>> As such, I still think the current draft is a bad idea absent appropriate protections in >>> RIR policy. >> >> I agree with owen, mostly... except I think we should just push RIR's >> to make GUA accessible to folks that need ipv6 adress space, >> regardless of connectiivty to thegreater 'internet' (for some >> definition of that thing). >> >> ULA of all types causes headaches on hosts, routers, etc. There is no >> reason to go down that road, just use GUA (Globally Unique Addresses). >> >> -Chris > > Failure to provide an ULA mechanism will result in self assignment from the spaces not yet made available for allocation. Down that road we will find history repeating itself. > > The reason I see a use in ULA-C is to ensure there is a way for cooperating organizations > (whether within or between enterprises) to have addressing that will not overlap for private > interconnects. If the RIRs will give out the space to end users and not charge a fortune for > it, there may be a chance of that working. It is less clear whether this is within the define 'fortune' ? I think currently for a PI /48 it's 1250/yr right? So... the cost (less really) of a laptop for your newest employee per year, basically. That seems quite reasonable (to me). Is that in the range you feel is acceptable? > business model or mission of the RIRs, though, to hand out very small chucks of address > space to a very large number of organizations for address space that will not be routed. 'not be routed' .... I think the RIR's should assign ip space, they have no idea (and no control) over where/what gets routed. They are a uniqueness registry really, for ipv6. > Of course if the ULA approach does gain acceptance, you'll have a LOT easier time > deciding which blocks of addresses to permit and deny in your BGP sessions and packet > filters on your borders. PI for v6 comes from a set block in each RIR, eh? -Chris From morrowc.lists at gmail.com Wed Apr 21 09:56:30 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 21 Apr 2010 10:56:30 -0400 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <22565F5E-D9B8-48A4-AE08-C0BE94A7D6C2@virtualized.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <22565F5E-D9B8-48A4-AE08-C0BE94A7D6C2@virtualized.org> Message-ID: On Wed, Apr 21, 2010 at 10:23 AM, David Conrad wrote: > On Apr 21, 2010, at 6:25 AM, Christopher Morrow wrote: >> I agree with owen, mostly... except I think we should just push RIR's >> to make GUA accessible to folks that need ipv6 adress space, >> regardless of connectiivty to thegreater 'internet' (for some >> definition of that thing). > > See RFC 1814. ?Fun how history repeats itself. yes... for those less willing to search: "Unique Addresses are Good" The abstract: The IAB suggests that while RFC 1597 establishes reserved IP address space for the use of private networks which are isolated and will remain isolated from the Internet, any enterprise which anticipates external connectivity to the Internet should apply for a globally unique address from an Internet registry or service provider. This does seem to be pretty much exactly my point (their point I suppose) Thx (as always drc) -chris From rsk at gsp.org Wed Apr 21 10:34:44 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 21 Apr 2010 11:34:44 -0400 Subject: Mail Submission Protocol In-Reply-To: References: Message-ID: <20100421153444.GA12465@gsp.org> On Wed, Apr 21, 2010 at 10:49:07AM -0300, Claudio Lapidus wrote: > At our ISP operation, we are seeing increasing levels of traffic in our > outgoing MTA's, presumably due to spammers abusing some of our subscribers' > accounts. [snip] A discussion on this topic is happening on spam-l at the moment; it's probably worth your time to subscribe to that list and read it, doubly so since it's not really appropriate for nanog. ---Rsk From owen at delong.com Wed Apr 21 10:47:41 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 21 Apr 2010 08:47:41 -0700 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <22565F5E-D9B8-48A4-AE08-C0BE94A7D6C2@virtualized.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <22565F5E-D9B8-48A4-AE08-C0BE94A7D6C2@virtualized.org> Message-ID: On Apr 21, 2010, at 7:23 AM, David Conrad wrote: > On Apr 21, 2010, at 6:25 AM, Christopher Morrow wrote: >> I agree with owen, mostly... except I think we should just push RIR's >> to make GUA accessible to folks that need ipv6 adress space, >> regardless of connectiivty to thegreater 'internet' (for some >> definition of that thing). > > See RFC 1814. Fun how history repeats itself. > > Regards, > -drc > @Chris, I agree with you. Perhaps its time for us to throw a proposal into the hopper to do just that. Owen From Ed.Lewis at neustar.biz Wed Apr 21 11:00:17 2010 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 21 Apr 2010 12:00:17 -0400 Subject: Reverse DNS Question In-Reply-To: <4BCE10A2.3090103@cox.net> References: <4BCE10A2.3090103@cox.net> Message-ID: At 15:37 -0500 4/20/10, Larry Sheldon wrote: >To minimize unwarranted hassle, if you will have email senders, spend >some time looking into the "requirements". I don't think there are any >RFC or other authoritative standards in the matter. This is as close as the IETF has come to a document. http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06 That document has been expired for 3 years, meaning, no one has updated it, no one has tried to get a steering committee broad review (IESG approval), etc. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? From drc at virtualized.org Wed Apr 21 11:11:38 2010 From: drc at virtualized.org (David Conrad) Date: Wed, 21 Apr 2010 09:11:38 -0700 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <22565F5E-D9B8-48A4-AE08-C0BE94A7D6C2@virtualized.org> Message-ID: <961575C7-19B1-4EA8-886B-8C8D522A59AA@virtualized.org> On Apr 21, 2010, at 7:56 AM, Christopher Morrow wrote: > yes... for those less willing to search: "Unique Addresses are Good" > ... > This does seem to be pretty much exactly my point (their point I suppose) Yup. Back in the day, the folks who ran the RIRs (at the time) were a bit distressed at that IAB statement as we had seen the writing on the wall and were telling customers that due to the limited nature of IPv4, if you didn't want to connect to the Internet, you should use private addressing. It was a bit of a "War of RFCs" (1597, 1627, 1814, 1918). My impression, which may be wrong, is that the primary driver for ULA-C is to avoid the administrative/cost overhead with entering into a relationship with the RIRs, particularly if there is no interest in connecting (directly) to the Internet. I guess I don't really see the harm... Regards, -drc Speaking personally. Not representing anyone but myself. Really. No, REALLY. (although this disclaimer doesn't appear to work for some folks who really should know better) From bmanning at vacation.karoshi.com Wed Apr 21 11:22:02 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 21 Apr 2010 16:22:02 +0000 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <961575C7-19B1-4EA8-886B-8C8D522A59AA@virtualized.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <22565F5E-D9B8-48A4-AE08-C0BE94A7D6C2@virtualized.org> <961575C7-19B1-4EA8-886B-8C8D522A59AA@virtualized.org> Message-ID: <20100421162202.GA31754@vacation.karoshi.com.> On Wed, Apr 21, 2010 at 09:11:38AM -0700, David Conrad wrote: > On Apr 21, 2010, at 7:56 AM, Christopher Morrow wrote: > > yes... for those less willing to search: "Unique Addresses are Good" > > ... > > This does seem to be pretty much exactly my point (their point I suppose) > > Yup. Back in the day, the folks who ran the RIRs (at the time) were a bit distressed at that IAB statement as we had seen the writing on the wall and were telling customers that due to the limited nature of IPv4, if you didn't want to connect to the Internet, you should use private addressing. It was a bit of a "War of RFCs" (1597, 1627, 1814, 1918). > > My impression, which may be wrong, is that the primary driver for ULA-C is to avoid the administrative/cost overhead with entering into a relationship with the RIRs, particularly if there is no interest in connecting (directly) to the Internet. I guess I don't really see the harm... > > Regards, > -drc > Speaking personally. Not representing anyone but myself. Really. No, REALLY. > (although this disclaimer doesn't appear to work for some folks who really should know better) this is my take as well. The RIR system works quite well, esp for networks/networking based on the previous centuries interconnection models. Its the best method for managing constrained resources, such as IPv4. something like ULA, esp the -C varient might be worthwhile as an alternative distribution channel, a way for folks who want to do novel things with networking/addressing that are not comprended in the normal bottom-up processes of the RIR system. In your words, "avoid the adminisrative/cost overhead with entering(maintaining) a relationship with the RIRs" I see this proposal as a vector for inovative change. --bill From dsparro at gmail.com Wed Apr 21 12:53:26 2010 From: dsparro at gmail.com (Dave Sparro) Date: Wed, 21 Apr 2010 13:53:26 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCEF3B7.8050102@jsbc.cc> References: <20100420193147.C69612B2128@mx5.roble.com> <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> <20100421080821.7339acae@opy.nosense.org> <66C49CF3-0719-4E03-A657-9F380668F3D6@delong.com> <20100421200826.4c815743@opy.nosense.org> <4BCEF3B7.8050102@jsbc.cc> Message-ID: <4BCF3B96.4020802@gmail.com> On 4/21/2010 8:46 AM, Jim Burwell wrote: > > Despite it doing the job it was intended to do, I've always seen NAT > as a bit of an ugly hack, with potential to get even uglier with LSN > and multi-level NAT in the future. I personally welcome a return to a > NAT-less world with IPv6. :) > Don't you get all of the same problems when there is a properly restrictive SPI firewall at both ends of the connection regardless of weather NAT is used as well. From james.cutler at consultant.com Wed Apr 21 12:57:00 2010 From: james.cutler at consultant.com (Cutler James R) Date: Wed, 21 Apr 2010 13:57:00 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCF3B96.4020802@gmail.com> References: <20100420193147.C69612B2128@mx5.roble.com> <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> <20100421080821.7339acae@opy.nosense.org> <66C49CF3-0719-4E03-A657-9F380668F3D6@delong.com> <20100421200826.4c815743@opy.nosense.org> <4BCEF3B7.8050102@jsbc.cc> <4BCF3B96.4020802@gmail.com> Message-ID: <030A2092-3665-44AB-841A-EB69E6EDC452@consultant.com> No. You get a different set of problems, mostly administrative. On Apr 21, 2010, at 1:53 PM, Dave Sparro wrote: > On 4/21/2010 8:46 AM, Jim Burwell wrote: >> >> Despite it doing the job it was intended to do, I've always seen NAT >> as a bit of an ugly hack, with potential to get even uglier with LSN >> and multi-level NAT in the future. I personally welcome a return to a >> NAT-less world with IPv6. :) >> > > Don't you get all of the same problems when there is a properly restrictive SPI firewall at both ends of the connection regardless of weather NAT is used as well. > James R. Cutler james.cutler at consultant.com From bill at herrin.us Wed Apr 21 13:24:37 2010 From: bill at herrin.us (William Herrin) Date: Wed, 21 Apr 2010 14:24:37 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <1271813655.6417.431.camel@karl> References: <20100420193147.C69612B2128@mx5.roble.com> <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> <1271813655.6417.431.camel@karl> Message-ID: On Tue, Apr 20, 2010 at 9:34 PM, Karl Auer wrote: > On Tue, 2010-04-20 at 12:59 -0700, Owen DeLong wrote: >> On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote: >> > NAT _always_ fails-closed >> Stateful Inspection can be implemented fail-closed. > > Not to take issue with either statement in particular, but I think there > needs to be some consideration of what "fail" means. Fail means that an inexperienced admin drops a router in place of the firewall to work around a priority problem while the senior engineer is on vacation. With NAT protecting unroutable addresses, that failure mode fails closed. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jbates at brightok.net Wed Apr 21 15:05:42 2010 From: jbates at brightok.net (Jack Bates) Date: Wed, 21 Apr 2010 15:05:42 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BCF3B96.4020802@gmail.com> References: <20100420193147.C69612B2128@mx5.roble.com> <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> <20100421080821.7339acae@opy.nosense.org> <66C49CF3-0719-4E03-A657-9F380668F3D6@delong.com> <20100421200826.4c815743@opy.nosense.org> <4BCEF3B7.8050102@jsbc.cc> <4BCF3B96.4020802@gmail.com> Message-ID: <4BCF5A96.9080508@brightok.net> Dave Sparro wrote: > > Don't you get all of the same problems when there is a properly > restrictive SPI firewall at both ends of the connection regardless of > weather NAT is used as well. If you mean, "do we still need protocols similar to uPNP" the answer is yes. Of course, uPNP is designed with a SPI in mind. However, we simplify a lot of problems when we remove address mangling from the equation. That's not to say there won't be NAT for IPv6. Fact is, businesses will ask and firewall vendors will give. Of course, business needs are often different than general usage (and especially home usage) needs. Jack From randy at psg.com Wed Apr 21 15:22:47 2010 From: randy at psg.com (Randy Bush) Date: Wed, 21 Apr 2010 15:22:47 -0500 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <20100421043432.GB25523@vacation.karoshi.com.> Message-ID: > if you think something like this is a good idea, worth > persuing, I'd like to hear from you. and for those of us who think this whack-a-mole is still a stupid idea, where do we write? randy From randy at psg.com Wed Apr 21 15:23:27 2010 From: randy at psg.com (Randy Bush) Date: Wed, 21 Apr 2010 15:23:27 -0500 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: Message-ID: > I see a need for stable, permanent blocks of addresses within an > organization. yep. unicast ipv6 address space will do just fine. randy From bmanning at vacation.karoshi.com Wed Apr 21 16:21:32 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 21 Apr 2010 21:21:32 +0000 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> Message-ID: <20100421212132.GA2186@vacation.karoshi.com.> On Wed, Apr 21, 2010 at 03:22:47PM -0500, Randy Bush wrote: > > if you think something like this is a good idea, worth > > persuing, I'd like to hear from you. > > and for those of us who think this whack-a-mole is still a stupid idea, > where do we write? > > randy apparently the same place! thanks Randy. --bill From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Apr 21 16:47:20 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 22 Apr 2010 07:17:20 +0930 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> Message-ID: <20100422071720.7f7403b5@opy.nosense.org> On Wed, 21 Apr 2010 09:25:46 -0400 Christopher Morrow wrote: > On Wed, Apr 21, 2010 at 1:29 AM, Owen DeLong wrote: > > While I think this is an improvement, unless the distribution of ULA-C is no cheaper > > and no easier to get than GUA, I still think there is reason to believe that it is likely > > ULA-C will become de facto GUA over the long term. > > > > As such, I still think the current draft is a bad idea absent appropriate protections in > > RIR policy. > > I agree with owen, mostly... except I think we should just push RIR's > to make GUA accessible to folks that need ipv6 adress space, > regardless of connectiivty to thegreater 'internet' (for some > definition of that thing). > > ULA of all types causes headaches on hosts, routers, etc. There is no > reason to go down that road, just use GUA (Globally Unique Addresses). > So what happens when you change providers? How are you going to keep using globals that now aren't yours? I'm also curious about these headaches. What are they? > -Chris > From jakob at kirei.se Wed Apr 21 16:56:07 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 21 Apr 2010 23:56:07 +0200 Subject: Mail Submission Protocol In-Reply-To: <20100421141359.GA20980@apia.perrit.net> References: <20100421141359.GA20980@apia.perrit.net> Message-ID: <81FFCA35-D531-411F-8C12-392D6FAB7E87@kirei.se> On 21 apr 2010, at 16.14, Leen Besselink wrote: > We added SSL to our SMTP-service and tell our customers to use SSL (not TLS) > with authentication and have the mailserver listen on the TCP-ports which > the mailclients pick for that (of which their are a few if I'm not mistaken). Assuming that you by SSL refer to a "raw" SSL-wrapped SMTP connection and with TLS refer to STARTTLS as described in RFC 3207, I would recommend against using "raw" SSL-wrapped SMTP. Although there are some email clients that do this (and they usually use the unregistered port 465 for this), setting this up with Message Submission for Mail (as described in RFC 4409) and STARTTLS will likely give your customers a more joyful experience thanks to reasonable defaults in most modern email clients. jakob From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Apr 21 17:00:51 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 22 Apr 2010 07:30:51 +0930 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <961575C7-19B1-4EA8-886B-8C8D522A59AA@virtualized.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <22565F5E-D9B8-48A4-AE08-C0BE94A7D6C2@virtualized.org> <961575C7-19B1-4EA8-886B-8C8D522A59AA@virtualized.org> Message-ID: <20100422073051.624e1ab8@opy.nosense.org> On Wed, 21 Apr 2010 09:11:38 -0700 David Conrad wrote: > On Apr 21, 2010, at 7:56 AM, Christopher Morrow wrote: > > yes... for those less willing to search: "Unique Addresses are Good" > > ... > > This does seem to be pretty much exactly my point (their point I suppose) > > Yup. Back in the day, the folks who ran the RIRs (at the time) were a bit distressed at that IAB statement as we had seen the writing on the wall and were telling customers that due to the limited nature of IPv4, if you didn't want to connect to the Internet, you should use private addressing. It was a bit of a "War of RFCs" (1597, 1627, 1814, 1918). > > My impression, which may be wrong, is that the primary driver for ULA-C is to avoid the administrative/cost overhead with entering into a relationship with the RIRs, particularly if there is no interest in connecting (directly) to the Internet. I guess I don't really see the harm... > That's not what I recollect when the site-local/ULA discussions were going on in 2002. Specifically, ULA-Cs were to address the concern of some people that the statistical possibility of collisions was too high, and therefore they wanted to be assured of global ULA uniqueness via central registry. The chance of collision is quite low - from RFC4193, section 3.2.3, " The following table shows the probability of a collision for a range of connections using a 40-bit Global ID field. Connections Probability of Collision 2 1.81*10^-12 10 4.54*10^-11 100 4.54*10^-09 1000 4.54*10^-07 10000 4.54*10^-05 Based on this analysis, the uniqueness of locally generated Global IDs is adequate for sites planning a small to moderate amount of inter-site communication using locally generated Global IDs." with 'connections' meaning backdoor links. Traditional, non-ULA-Cs would do the job your talking about fine. Regards, Mark. From bmanning at vacation.karoshi.com Wed Apr 21 17:05:01 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 21 Apr 2010 22:05:01 +0000 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <20100422071720.7f7403b5@opy.nosense.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> Message-ID: <20100421220501.GC2186@vacation.karoshi.com.> On Thu, Apr 22, 2010 at 07:17:20AM +0930, Mark Smith wrote: > On Wed, 21 Apr 2010 09:25:46 -0400 > Christopher Morrow wrote: > > > On Wed, Apr 21, 2010 at 1:29 AM, Owen DeLong wrote: > > > While I think this is an improvement, unless the distribution of ULA-C is no cheaper > > > and no easier to get than GUA, I still think there is reason to believe that it is likely > > > ULA-C will become de facto GUA over the long term. > > > > > > As such, I still think the current draft is a bad idea absent appropriate protections in > > > RIR policy. > > > > I agree with owen, mostly... except I think we should just push RIR's > > to make GUA accessible to folks that need ipv6 adress space, > > regardless of connectiivty to thegreater 'internet' (for some > > definition of that thing). > > > > ULA of all types causes headaches on hosts, routers, etc. There is no > > reason to go down that road, just use GUA (Globally Unique Addresses). > > > > So what happens when you change providers? How are you going to keep > using globals that now aren't yours? > > I'm also curious about these headaches. What are they? > I'm so not creative enough to compose this whole missive in TLAs... perhaps some day. Some bright blub got tired of typing out "Globally Unique Addresses) and so started using the TLA/GUA. Which eventually got me to thinking. Technically, all IP addresses are globally unique. There is only one of them. 172.14.3.42/32 is a GUA. There are however, two other vectors which the community seems to want and we talk around them a whole bunch. Perhaps we should explicitly make them part of the conversation. ) A GUA has a single authoritative chain of custody... e.g. the community recognizes that only Bill Manning's Bait and Sushi shoppe (AS 66,666) is authorized to inject routes for and sink traffic to 172.14.3.0/24 The whole rPKI construct is built to support this idea. Now some prefixes are defined to -NOT- have a single authoriative chain of custody, witness RFC 1918. And NAT makes matters "fuzzier" ... bringing scoping into the mix - but I'll stick by the postualte that this single authoritative chain of custody is a key point in understanding how folk think of IP stewardship ... and (THIS IS IMPORTANT) ... there is this strong idea that a short custody chain is prefered over a long one. ) A GUA is temporally bound**... e.g. the community recognizes that for any given GUA, there is a temporal bounding on the chain of custody. DHCP is a canonical example for end/leaf sites, where GUAs are leased out for (comparitavely) brief time periods. ISPs lease space to their clients for longer periods, and RIRs are (mostly) binding a chain of custody to annual cycles. For some legacy space, the temporal binding is of -much- longer duration. so... I might argue that the IANA/RIR/LIR/Enterprise chain has the renumbering concern that you raise, while a IPR/Enterprise chain is much shorter and has a smaller renumbering concern. and -IF- the permise and details of the draft are to be beleived, then a delegation from that space is just as much assured of global uniqueness than space from an RIR. ** The Temporaly Unique Address/TUA !!! From dhc2 at dcrocker.net Wed Apr 21 17:17:28 2010 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Wed, 21 Apr 2010 15:17:28 -0700 Subject: Mail Submission Protocol In-Reply-To: References: Message-ID: <4BCF7978.9080908@dcrocker.net> On 4/21/2010 6:49 AM, Claudio Lapidus wrote: > So we are considering ways to further filter this traffic. We are evaluating > implementation of MSA through port 587. RFC 5068, Email Submission Operations: Access and Accountability Requirements, is a BCP. It specifies authenticated port 587 for email submission across the net. As others have noted, it works well through a wide variety of access environments. I don't remember the last time I found it blocked. I use it over TLS, of course. Blocking of outbound port 25 for all hosts not explicitly authorized has become common. The fact that 587 default to authenticated is the win. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From marquis at roble.com Wed Apr 21 17:26:28 2010 From: marquis at roble.com (Roger Marquis) Date: Wed, 21 Apr 2010 15:26:28 -0700 (PDT) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: Message-ID: <20100421222628.993782B2121@mx5.roble.com> William Herrin wrote: >> Not to take issue with either statement in particular, but I think there >> needs to be some consideration of what "fail" means. > > Fail means that an inexperienced admin drops a router in place of the > firewall to work around a priority problem while the senior engineer > is on vacation. With NAT protecting unroutable addresses, that failure > mode fails closed. In addition to fail-closed NAT also means: * search engines and and connectivity providers cannot (easily) differentiate and/or monitor your internal hosts, and * multiple routes do not have to be announced or otherwise accommodated by internal re-addressing. Roger Marquis From marquis at roble.com Wed Apr 21 17:33:55 2010 From: marquis at roble.com (Roger Marquis) Date: Wed, 21 Apr 2010 15:33:55 -0700 (PDT) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: Message-ID: <20100421223355.92E742B2121@mx5.roble.com> Jack Bates wrote: > If you mean, "do we still need protocols similar to uPNP" the answer is > yes. Of course, uPNP is designed with a SPI in mind. However, we > simplify a lot of problems when we remove address mangling from the > equation. Let's not forget why UPNP is what it is and why it should go away. UPNP was Microsoft's answer to Sun's JINI. It was never intended to provide security. All MS wanted do with UPNP was derail a competing vendor's (vastly superior) technology. Not particularly different than MS' recent efforts around OOXML. Roger Marquis From schampeo at hesketh.com Wed Apr 21 17:39:14 2010 From: schampeo at hesketh.com (Steven Champeon) Date: Wed, 21 Apr 2010 18:39:14 -0400 Subject: Reverse DNS Question In-Reply-To: References: Message-ID: <20100421223914.GA10253@hesketh.com> on Tue, Apr 20, 2010 at 11:39:11PM -0500, James Hess wrote: > EXCEPT.... that is just an example, don't actually use a hostname > like "ip192-0-0-1.example.com." in real life. > > [*] Certain overly aggressive blacklists assume that the host must be > a dynamic / dial-up user due to the presence of "192-0-0-1", which > is recognized to be an IP address, so be careful. While I don't consider my project to be "over-aggressive", you should be aware that many antispam filtering systems do classify hostnames as a class by their naming convention (in my case, I have ~52K patterns for naming conventions in around 27K domains, classified by assignment and other types and where possible by the technology in use eg static/dsl, dynamic/dialup) and use those classifications to determine policy. So, if you're intending to do the right thing here WRT your PTR naming, it'd behoove you to indicate at the very least whether these are to be used by end users (who are more likely to be infected with bots), whether they're dynamically or statically assigned, whether they're legit sources of mail, etc. Best current practice is to allow customers running mail servers to assign custom and appropriate names to said hosts (including PTR, not just A). Also, to make it easier for folks running older MTAs without decent regex support to block unwanted bot mail try to keep the most significant token to the right hand side, a la 1-2-3-4.raleigh.nc.dsl.dyn.example.net instead of dsl-1-2-3-4-dynamic.nc.raleigh.example.net So they can block all mail from dynamics with a simple 'dyn.example.net' instead of having to collect access.db entries for every city you happen to provide access to. The rest of the Internet thanks you in advance ;-) Having some comment or memo in your SWIP for the block that indicates what the block's IPs are to be used for is also helpful, as when the PTR is obscure and unhelpful rwhois is the next obvious place to turn for enlightenment. I've written up some tips and hints here: http://enemieslist.com/news/archives/2009/06/principles.html http://enemieslist.com/news/archives/2009/06/basic_principle.html http://enemieslist.com/news/archives/2009/06/basic_principle_1.html http://enemieslist.com/news/archives/2009/06/basic_principle_2.html http://enemieslist.com/news/archives/2009/07/a_passionate_cr.html http://enemieslist.com/news/archives/2009/07/why_we_suspect.html Comments welcome. As for those supposed blacklists that treat n-n-n-n as an obvious dialup, they're going to run into a lot of trouble if they try to classify any of these hosts that way (they are in all likelihood MXen or outbounds): 203-214-65-42.mail2.fft.com.au 189-17-23-133.alpinet.com.br mx-189-108-118-122.compertratores.com.br 200-206-157-155.mail.eletti.com.br 200-148-137-195.fundecitrus.com.br 200-206-216-150.corpmail.panini.com.br 200-204-147-132.smtp-gw.scanbrasil.com.br gate-193-85-144-1.e-one.cz 63-145-232-66.accessintel.com 24-43-168-100.biz.aceweb.com mm-notify-out-72-21-209-53.amazon.com 69-20-71-3.clearrequest.com mx-82-102-77-85.infocreditgroup.com 84-45-12-85.interparcel.com 64-128-133-217.static.ithikon.com s199-126-14-180.local1111.com adsl-66-139-110-100.midwestrug.com sm-70-42-226-219.quepasa.com so-63-131-152-52.serviceobjects.com 216-139-224-52.aus.us.siteprotect.com 151-204-36-17.smtpusa.com mx-119-92-80-10.theorchardgolf.com 203-214-65-56.mail.thomsettinternational.com antispam-213-183-191-209.ewe-ip-backbone.de 11-176-40-206-reverse.brazosport.edu 209-184-246-217.labette.edu 124-247-238-41.mail.ashwath.in 186-227-63-74.reverse.wirepressnewsalerts.info 77-49-165-194.celeo.net mail-36-244-187-78.imzahost.net 66-50-173-37.masso.net 35-225-63-74.reverse.wirepresswirenewsalerts.net mx-213-48-133-164.aclt.org host84-233-131-230.19.co.uk 207-193-177-11.crowley.k12.tx.us HTH, Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/ From jeroen at mompl.net Wed Apr 21 17:59:02 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 21 Apr 2010 15:59:02 -0700 Subject: iabelle francois In-Reply-To: References: Message-ID: <4BCF8336.4020102@mompl.net> Charles Morris wrote: > http://www.os-bc.de/home.php This is spam by the way. The url redirects to a Canadian med site. The original sender may check if he has any malware running... -- http://goldmark.org/jeff/stupid-disclaimers/ From franck at genius.com Wed Apr 21 18:07:44 2010 From: franck at genius.com (Franck Martin) Date: Thu, 22 Apr 2010 11:07:44 +1200 (MAGST) Subject: Mail Submission Protocol In-Reply-To: <4BCF7978.9080908@dcrocker.net> Message-ID: <31470988.940.1271891259837.JavaMail.franck@franck-martins-macbook-pro.local> Consider also smtps port which should be treated like smtp port and not like submission port, or simply do not listen on smtps as TLS is available on smtp port via esmtp. A lot of providers are now blocking smtp traffic from dynamic/residential IPs, and all clients support to enter submission port instead of smtp port. The advantage of this config, when you have a roaming user, they don't need to configure their email client depending on the network they are connecting to. If you want to see the extend of the problem on your network just go to http://www.uceprotect.net/en/rblcheck.php and enter your AS/network and see how many of your clients are spamming due to mainly botnets. ----- Original Message ----- From: "Dave CROCKER" To: nanog at nanog.org Sent: Thursday, 22 April, 2010 10:17:28 AM Subject: Re: Mail Submission Protocol On 4/21/2010 6:49 AM, Claudio Lapidus wrote: > So we are considering ways to further filter this traffic. We are > evaluating implementation of MSA through port 587. RFC 5068, Email Submission Operations: Access and Accountability Requirements, is a BCP. It specifies authenticated port 587 for email submission across the net. As others have noted, it works well through a wide variety of access environments. I don't remember the last time I found it blocked. I use it over TLS, of course. Blocking of outbound port 25 for all hosts not explicitly authorized has become common. The fact that 587 default to authenticated is the win. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From chris at nmedia.net Wed Apr 21 18:14:22 2010 From: chris at nmedia.net (Chris Cappuccio) Date: Wed, 21 Apr 2010 16:14:22 -0700 Subject: Mikrotik RouterOS In-Reply-To: <1271120175.15669.35.camel@ub-g-d2> References: <4BC36C83.7040200@freedomnet.co.nz> <4BC36E27.4000005@gmail.com> <4BC37928.5030004@Janoszka.pl> <4BC37D55.6050806@freedomnet.co.nz> <1271120175.15669.35.camel@ub-g-d2> Message-ID: <20100421231422.GD5371@ref.nmedia.net> gordon b slater [gordslater at ieee.org] wrote: > On Mon, 2010-04-12 at 16:06 -0400, James Jones wrote: > > kind of....routerOS supports MPLS, linux does not > > Likewise the FreeBSD MPLS effort, though this seems to be more like > familiar territory for BSD-heads, but, as ever, funding and equipment > are sorely needed. > OpenBSD post-4.7 (current) is about to get a full BGP MPLS VPN implementation and has ldp working too. Yeah baby From ops.lists at gmail.com Wed Apr 21 20:35:56 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 22 Apr 2010 07:05:56 +0530 Subject: Mail Submission Protocol In-Reply-To: <1271859483.3681.25.camel@akamiru> References: <1271859483.3681.25.camel@akamiru> Message-ID: Log and monitor all that you can. And watch for a large number of IPs logging into an account over a day (over a set limit - even across country - that takes into account "home - blackberry - airport lounge - airport lounge in another country - hotel - RIPE meeting venue" type scenarios). And especially watch for and/or firewall off logins from areas from where you see particularly high levels of smtp auth abuse / logins to compromised accounts --srs 2010/4/21 Alex Kamiru : >>>Inside customers, we have not changed to force port 587 and >>>authentication for email clients, but the topic has come up in >>>discussions. ?This won't of course, stop spammers if they are hijacking >>>the users local email client settings. > > How best would you stop spammers hijacking local users email clients > > -Mike From Valdis.Kletnieks at vt.edu Wed Apr 21 20:35:28 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 21 Apr 2010 21:35:28 -0400 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: Your message of "Thu, 22 Apr 2010 07:30:51 +0930." <20100422073051.624e1ab8@opy.nosense.org> References: <20100421043432.GB25523@vacation.karoshi.com> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <22565F5E-D9B8-48A4-AE08-C0BE94A7D6C2@virtualized.org> <961575C7-19B1-4EA8-886B-8C8D522A59AA@virtualized.org> <20100422073051.624e1ab8@opy.nosense.org> Message-ID: <9031.1271900128@localhost> On Thu, 22 Apr 2010 07:30:51 +0930, Mark Smith said: > " The following table shows the probability of a collision for a range > of connections using a 40-bit Global ID field. > > Connections Probability of Collision > > 2 1.81*10^-12 > 10 4.54*10^-11 > 100 4.54*10^-09 > 1000 4.54*10^-07 > 10000 4.54*10^-05 > > Based on this analysis, the uniqueness of locally generated Global > IDs is adequate for sites planning a small to moderate amount of > inter-site communication using locally generated Global IDs." There is a measured rate by RIRs and the like on the order of 10^-6 for accidentally issuing duplicate integers (roughly approximated by 2 cases of duplicate ASNs out of (300K routes + 30K ASNs). In other words, unless you have over 1,000 or so backdoor links, you're more likely to get screwed over by an administrative drone fscking up your paperwork than you are of a statistical collision. -------------- 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 Wed Apr 21 21:54:37 2010 From: franck at genius.com (Franck Martin) Date: Thu, 22 Apr 2010 14:54:37 +1200 (MAGST) Subject: Mail Submission Protocol In-Reply-To: Message-ID: <31682932.1060.1271904876633.JavaMail.franck@franck-martins-macbook-pro.local> If you have left port 25 open, this is a good place to start. http://www.uceprotect.net/en/rblcheck.php I suspect any decent IDS will tell you which machine has weird traffic. I suppose you can put rules based on the IDS result to redirect them to a special web page to tell them, they have to do something. The main issue, it not to know which machines are hijacked, but to support these machines. ----- Original Message ----- From: "Suresh Ramasubramanian" To: "Alex Kamiru" Cc: nanog at nanog.org Sent: Thursday, 22 April, 2010 1:35:56 PM Subject: Re: Mail Submission Protocol Log and monitor all that you can. And watch for a large number of IPs logging into an account over a day (over a set limit - even across country - that takes into account "home - blackberry - airport lounge - airport lounge in another country - hotel - RIPE meeting venue" type scenarios). And especially watch for and/or firewall off logins from areas from where you see particularly high levels of smtp auth abuse / logins to compromised accounts --srs 2010/4/21 Alex Kamiru : >>>Inside customers, we have not changed to force port 587 and >>>authentication for email clients, but the topic has come up in >>>discussions. This won't of course, stop spammers if they are >>>hijacking the users local email client settings. > > How best would you stop spammers hijacking local users email clients > > -Mike From ops.lists at gmail.com Wed Apr 21 22:16:18 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 22 Apr 2010 08:46:18 +0530 Subject: Mail Submission Protocol In-Reply-To: <31682932.1060.1271904876633.JavaMail.franck@franck-martins-macbook-pro.local> References: <31682932.1060.1271904876633.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: No. UCEProtect is certainly not a decent or any other kind of place to start. The MAAWG BCPs have far more available than one of the worst maintained blacklists that has ever been in existence. If you want FAQs from blocklists - there is much that's available on the spamhaus.org website On Thu, Apr 22, 2010 at 8:24 AM, Franck Martin wrote: > If you have left port 25 open, this is a good place to start. > > http://www.uceprotect.net/en/rblcheck.php > > I suspect any decent IDS will tell you which machine has weird traffic. I suppose you can put rules based on the IDS result to redirect them to a special web page to tell them, they have to do something. > > The main issue, it not to know which machines are hijacked, but to support these machines. > > ----- Original Message ----- > From: "Suresh Ramasubramanian" > To: "Alex Kamiru" > Cc: nanog at nanog.org > Sent: Thursday, 22 April, 2010 1:35:56 PM > Subject: Re: Mail Submission Protocol > > Log and monitor all that you can. And watch for a large number of IPs > logging into an account over a day (over a set limit - even across > country - that takes into account "home - blackberry - airport lounge > - airport lounge in another country - hotel - RIPE meeting venue" > type scenarios). > > And especially watch for and/or firewall off logins from areas from > where you see particularly high levels of smtp auth abuse / logins to > compromised accounts > > --srs > > 2010/4/21 Alex Kamiru : >>>>Inside customers, we have not changed to force port 587 and >>>>authentication for email clients, but the topic has come up in >>>>discussions. This won't of course, stop spammers if they are >>>>hijacking the users local email client settings. >> >> How best would you stop spammers hijacking local users email clients >> >> -Mike > -- Suresh Ramasubramanian (ops.lists at gmail.com) From owen at delong.com Wed Apr 21 22:31:09 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 21 Apr 2010 20:31:09 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100421222628.993782B2121@mx5.roble.com> References: <20100421222628.993782B2121@mx5.roble.com> Message-ID: <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> On Apr 21, 2010, at 3:26 PM, Roger Marquis wrote: > William Herrin wrote: >>> Not to take issue with either statement in particular, but I think there >>> needs to be some consideration of what "fail" means. >> >> Fail means that an inexperienced admin drops a router in place of the >> firewall to work around a priority problem while the senior engineer >> is on vacation. With NAT protecting unroutable addresses, that failure >> mode fails closed. > > In addition to fail-closed NAT also means: > > * search engines and and connectivity providers cannot (easily) > differentiate and/or monitor your internal hosts, and > Right, because nobody has figured out Javascript and Cookies. > * multiple routes do not have to be announced or otherwise accommodated > by internal re-addressing. > I fail to see how NAT even affects this in a properly structured network. Owen From morrowc.lists at gmail.com Thu Apr 22 00:48:18 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 22 Apr 2010 01:48:18 -0400 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <20100422071720.7f7403b5@opy.nosense.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> Message-ID: On Wed, Apr 21, 2010 at 5:47 PM, Mark Smith wrote: > On Wed, 21 Apr 2010 09:25:46 -0400 > Christopher Morrow wrote: > >> On Wed, Apr 21, 2010 at 1:29 AM, Owen DeLong wrote: >> > While I think this is an improvement, unless the distribution of ULA-C is no cheaper >> > and no easier to get than GUA, I still think there is reason to believe that it is likely >> > ULA-C will become de facto GUA over the long term. >> > >> > As such, I still think the current draft is a bad idea absent appropriate protections in >> > RIR policy. >> >> I agree with owen, mostly... except I think we should just push RIR's >> to make GUA accessible to folks that need ipv6 adress space, >> regardless of connectiivty to thegreater 'internet' (for some >> definition of that thing). >> >> ULA of all types causes headaches on hosts, routers, etc. There is no >> reason to go down that road, just use GUA (Globally Unique Addresses). >> > > So what happens when you change providers? How are you going to keep > using globals that now aren't yours? use pi space, request it from your local friendly RIR. > I'm also curious about these headaches. What are they? do I use that ula-* address to talk to someone or another GUA address? how do I decide? what about to business partners? one address... much simpler, much less to screw up. -chris > >> -Chris >> > From morrowc.lists at gmail.com Thu Apr 22 00:51:51 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 22 Apr 2010 01:51:51 -0400 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <9031.1271900128@localhost> References: <20100421043432.GB25523@vacation.karoshi.com> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <22565F5E-D9B8-48A4-AE08-C0BE94A7D6C2@virtualized.org> <961575C7-19B1-4EA8-886B-8C8D522A59AA@virtualized.org> <20100422073051.624e1ab8@opy.nosense.org> <9031.1271900128@localhost> Message-ID: On Wed, Apr 21, 2010 at 9:35 PM, wrote: > On Thu, 22 Apr 2010 07:30:51 +0930, Mark Smith said: > >> " ?The following table shows the probability of a collision for a range >> ? ?of connections using a 40-bit Global ID field. >> >> ? ? ? Connections ? ? ?Probability of Collision >> >> ? ? ? ? ? 2 ? ? ? ? ? ? ? ?1.81*10^-12 >> ? ? ? ? ?10 ? ? ? ? ? ? ? ?4.54*10^-11 >> ? ? ? ? 100 ? ? ? ? ? ? ? ?4.54*10^-09 >> ? ? ? ?1000 ? ? ? ? ? ? ? ?4.54*10^-07 >> ? ? ? 10000 ? ? ? ? ? ? ? ?4.54*10^-05 >> >> ? ?Based on this analysis, the uniqueness of locally generated Global >> ? ?IDs is adequate for sites planning a small to moderate amount of >> ? ?inter-site communication using locally generated Global IDs." > > There is a measured rate by RIRs and the like on the order of 10^-6 for > accidentally issuing duplicate integers (roughly approximated by 2 cases of > duplicate ASNs out of (300K routes + 30K ASNs). ?In other words, unless you > have over 1,000 or so backdoor links, you're more likely to get screwed over by > an administrative drone fscking up your paperwork than you are of a statistical > collision. it's not about the frequency of collision, it's about the cost to rectify one/two/some. and the complexity this adds to every host/router/device in/around the network (dns, firewalls, acls, etc... icky) -chris From franck at genius.com Thu Apr 22 01:10:10 2010 From: franck at genius.com (Franck Martin) Date: Thu, 22 Apr 2010 18:10:10 +1200 (MAGST) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> Message-ID: <21703879.1086.1271916609912.JavaMail.franck@franck-martins-macbook-pro.local> The whole thread made me thought about this: http://www.ipinc.net/IPv4.GIF The energy that people are willing to spend to fix it (NAT, LSN), rather than bite the bullet is amazing. From dot at dotat.at Thu Apr 22 06:07:49 2010 From: dot at dotat.at (Tony Finch) Date: Thu, 22 Apr 2010 12:07:49 +0100 Subject: Mail Submission Protocol Message-ID: <90AFE804-3CC3-4FE1-A6D6-FD0F79B4AD10@dotat.at> On 22 Apr 2010, at 00:07, Franck Martin wrote: > Consider also smtps port which should be treated like smtp port and > not like submission port, or simply do not listen on smtps as TLS is > available on smtp port via esmtp. Er, no. TLS-on-connect aka smtps (as opposed to STARTTLS) is only used to support Microsoft MUAs that are more than a couple of years old. They only supported STARTTLS on port 25 and insisted on using the deprecated TLS-on-connect mode on all other ports. This meant they could not support standard Message Submission on port 587. Therefore you should treat smtps (TLS-on-connect on port 465) as the special Microsoft version of RFC 4409 message submission. That is, treat the protocols exactly the same wrt authentication, authorization, firewalls, address validation, etc. Tony. -- f.anthony.n.finch http://dotat.at/ From bill at herrin.us Thu Apr 22 06:18:18 2010 From: bill at herrin.us (William Herrin) Date: Thu, 22 Apr 2010 07:18:18 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> Message-ID: On Wed, Apr 21, 2010 at 11:31 PM, Owen DeLong wrote: > On Apr 21, 2010, at 3:26 PM, Roger Marquis wrote: >> William Herrin wrote: >>>> Not to take issue with either statement in particular, but I think there >>>> needs to be some consideration of what "fail" means. >>> >>> Fail means that an inexperienced admin drops a router in place of the >>> firewall to work around a priority problem while the senior engineer >>> is on vacation. With NAT protecting unroutable addresses, that failure >>> mode fails closed. >> >> In addition to fail-closed NAT also means: >> >> ?* search engines and and connectivity providers cannot (easily) >> ?differentiate and/or monitor your internal hosts, and >> > Right, because nobody has figured out Javascript and Cookies. Having worked for comScore, I can tell you that having a fixed address in the lower 64 bits would make their jobs oh so much easier. Cookies and javascript are of very limited utility. On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes. Even if there is no such draft, it wouldn't exactly be hard to implement. It won't take NAT to anonymize the PCs on a LAN with IPv6. >> ?* multiple routes do not have to be announced or otherwise accommodated >> ?by internal re-addressing. > > I fail to see how NAT even affects this in a properly structured network. That's your failure, not Roger's. As delivered, IPv6 is capable of dynamically assigning addresses from multiple subnets to a PC, but that's where the support for multiple-PA multihoming stops. PCs don't do so well at using more than one of those addresses at a time for outbound connections. As a number of vendors have done with IPv4, an IPv6 NAT box at the network border can spread outbound connections between multiply addressed upstream links. On Thu, Apr 22, 2010 at 2:10 AM, Franck Martin wrote: > http://www.ipinc.net/IPv4.GIF > The energy that people are willing to spend to fix it (NAT, LSN), > rather than bite the bullet is amazing. A friend of mine drives a 1976 Cadillac El Dorado. I asked him why once. He explained that even at 8 miles to the gallon and even after having to find 1970's parts for it, he can't get anything close to as luxurious a car from the more modern offerings at anything close to the comparatively small amount of money he spends. The thing has plush leather seats that feel like sinking in to a comfy couch and an engine with more horsepower than my mustang gt. It isn't hard to see his point. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From r.bhatia at ipax.at Thu Apr 22 06:26:03 2010 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Thu, 22 Apr 2010 13:26:03 +0200 Subject: Mail Submission Protocol In-Reply-To: <90AFE804-3CC3-4FE1-A6D6-FD0F79B4AD10@dotat.at> References: <90AFE804-3CC3-4FE1-A6D6-FD0F79B4AD10@dotat.at> Message-ID: <4BD0324B.3010805@ipax.at> On 22.04.2010 13:07, Tony Finch wrote: > Er, no. TLS-on-connect aka smtps (as opposed to STARTTLS) is only used > to support Microsoft MUAs that are more than a couple of years old. They > only supported STARTTLS on port 25 and insisted on using the deprecated > TLS-on-connect mode on all other ports. This meant they could not > support standard Message Submission on port 587. Therefore you should > treat smtps (TLS-on-connect on port 465) as the special Microsoft > version of RFC 4409 message submission. That is, treat the protocols > exactly the same wrt authentication, authorization, firewalls, address > validation, etc. i recently had the problem that an lotus notes server insisted on sending emails to one of our clients via port 465. so having mandatory authentication there actually broke delivery for an exchange sender. > X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 > X-MIMETrack: Serialize by Router on smtp2/xxxxx(Release 6.5.4|March 27, 2005) ..... cheers, raoul From bmanning at vacation.karoshi.com Thu Apr 22 06:30:39 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 22 Apr 2010 11:30:39 +0000 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> Message-ID: <20100422113039.GA8190@vacation.karoshi.com.> > > On the other hand, I could swear I've seen a draft where the PC picks > up random unused addresses in the lower 64 for each new outbound > connection for anonymity purposes. Even if there is no such draft, it > wouldn't exactly be hard to implement. It won't take NAT to anonymize > the PCs on a LAN with IPv6. the idea is covered by one or more patents held by cisco. --bill > Regards, > Bill Herrin From bill at herrin.us Thu Apr 22 06:46:50 2010 From: bill at herrin.us (William Herrin) Date: Thu, 22 Apr 2010 07:46:50 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100422113039.GA8190@vacation.karoshi.com.> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <20100422113039.GA8190@vacation.karoshi.com.> Message-ID: On Thu, Apr 22, 2010 at 7:30 AM, wrote: >> On the other hand, I could swear I've seen a draft where the PC picks >> up random unused addresses in the lower 64 for each new outbound >> connection for anonymity purposes. Even if there is no such draft, it >> wouldn't exactly be hard to implement. It won't take NAT to anonymize >> the PCs on a LAN with IPv6. > > ? ? ? ?the idea is covered by one or more patents held by cisco. Won't stop the worms from using it to hide which PC they're living on. -Bill -- 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 Thu Apr 22 06:52:31 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 22 Apr 2010 11:52:31 +0000 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <20100422113039.GA8190@vacation.karoshi.com.> Message-ID: <20100422115231.GA8376@vacation.karoshi.com.> On Thu, Apr 22, 2010 at 07:46:50AM -0400, William Herrin wrote: > On Thu, Apr 22, 2010 at 7:30 AM, wrote: > >> On the other hand, I could swear I've seen a draft where the PC picks > >> up random unused addresses in the lower 64 for each new outbound > >> connection for anonymity purposes. Even if there is no such draft, it > >> wouldn't exactly be hard to implement. It won't take NAT to anonymize > >> the PCs on a LAN with IPv6. > > > > the idea is covered by one or more patents held by cisco. > > Won't stop the worms from using it to hide which PC they're living on. > no... but then you just block the /32 and your fine... :) kind of like how people now block /8s for ranges that are "messy" --bill From fw at deneb.enyo.de Thu Apr 22 07:03:43 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 22 Apr 2010 14:03:43 +0200 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <20100421043432.GB25523@vacation.karoshi.com.> (bmanning@vacation.karoshi.com's message of "Wed, 21 Apr 2010 04:34:32 +0000") References: <20100421043432.GB25523@vacation.karoshi.com.> Message-ID: <87wrvzpucg.fsf@mid.deneb.enyo.de> > a few questions. > > IPv6 on your radar? > Looking at options for addressing your future v6 needs? > > Have you looked at the IETF/ID in the subject line? ULA looks always interesting, but tends to end up in obscurity because the right folks don't buy in. Anyway, the proposal brings IPv6 down to about 40 globally routable bits, compared to 21 to 24 in IPv4. That's still a lot, though. A further simplification would replace the Global ID with the AS number. A real improvement over IPv4 would embed distinct IDs for location and identity of any subnet, but that would probably mean that subnets receive less than 64 bits. From simon.perreault at viagenie.ca Thu Apr 22 07:34:20 2010 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Thu, 22 Apr 2010 08:34:20 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> Message-ID: <4BD0424C.8090000@viagenie.ca> On 2010-04-22 07:18, William Herrin wrote: > On the other hand, I could swear I've seen a draft where the PC picks > up random unused addresses in the lower 64 for each new outbound > connection for anonymity purposes. That's probably RFC 4941. It's available in pretty much all operating systems. I don't think there's any IPR issue to be afraid of. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From tglassey at earthlink.net Thu Apr 22 07:54:03 2010 From: tglassey at earthlink.net (todd glassey) Date: Thu, 22 Apr 2010 05:54:03 -0700 Subject: Looking for an Admin at the IANA... In-Reply-To: <21703879.1086.1271916609912.JavaMail.franck@franck-martins-macbook-pro.local> References: <21703879.1086.1271916609912.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4BD046EB.2010407@earthlink.net> I am looking for a technical contact inside the IANA regarding their internal network if anyone knows one. Todd Glassey -------------- next part -------------- A non-text attachment was scrubbed... Name: tglassey.vcf Type: text/x-vcard Size: 133 bytes Desc: not available URL: From jimb at jsbc.cc Thu Apr 22 07:55:46 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Thu, 22 Apr 2010 05:55:46 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD0424C.8090000@viagenie.ca> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> Message-ID: <4BD04752.9050602@jsbc.cc> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/22/2010 05:34, Simon Perreault wrote: > On 2010-04-22 07:18, William Herrin wrote: >> On the other hand, I could swear I've seen a draft where the PC >> picks up random unused addresses in the lower 64 for each new >> outbound connection for anonymity purposes. > > That's probably RFC 4941. It's available in pretty much all > operating systems. I don't think there's any IPR issue to be afraid > of. > > Simon I think this is different. They're talking about using a new IPv6 for each connection. RFC4941 just changes it over time IIRC. IMHO that's still pretty good privacy, at least on par with a NATed IPv4 from the outside perspective, especially if you rotated through temporary IPv6s fairly frequently. Of course, for browsers, as someone else mentioned, it's somewhat moot because of cookies. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvQR1IACgkQ2fXFxl4S7sT0agCglqjxX9d2kYuadrreIqPo5+rN FMAAniW1GodHwArieT/Czd96aMGQTgEF =xYjP -----END PGP SIGNATURE----- From bmanning at vacation.karoshi.com Thu Apr 22 08:22:55 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 22 Apr 2010 13:22:55 +0000 Subject: Looking for an Admin at the IANA... In-Reply-To: <4BD046EB.2010407@earthlink.net> References: <21703879.1086.1271916609912.JavaMail.franck@franck-martins-macbook-pro.local> <4BD046EB.2010407@earthlink.net> Message-ID: <20100422132255.GA8526@vacation.karoshi.com.> iana at iana.org or... 310.823.9358 On Thu, Apr 22, 2010 at 05:54:03AM -0700, todd glassey wrote: > I am looking for a technical contact inside the IANA regarding their > internal network if anyone knows one. > > Todd Glassey From mohacsi at niif.hu Thu Apr 22 08:37:19 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 22 Apr 2010 15:37:19 +0200 (CEST) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> Message-ID: On Thu, 22 Apr 2010, William Herrin wrote: > On Wed, Apr 21, 2010 at 11:31 PM, Owen DeLong wrote: >> On Apr 21, 2010, at 3:26 PM, Roger Marquis wrote: >>> William Herrin wrote: >>>>> Not to take issue with either statement in particular, but I think there >>>>> needs to be some consideration of what "fail" means. >>>> >>>> Fail means that an inexperienced admin drops a router in place of the >>>> firewall to work around a priority problem while the senior engineer >>>> is on vacation. With NAT protecting unroutable addresses, that failure >>>> mode fails closed. >>> >>> In addition to fail-closed NAT also means: >>> >>> ?* search engines and and connectivity providers cannot (easily) >>> ?differentiate and/or monitor your internal hosts, and >>> >> Right, because nobody has figured out Javascript and Cookies. > > Having worked for comScore, I can tell you that having a fixed address > in the lower 64 bits would make their jobs oh so much easier. Cookies > and javascript are of very limited utility. > > On the other hand, I could swear I've seen a draft where the PC picks > up random unused addresses in the lower 64 for each new outbound > connection for anonymity purposes. Even if there is no such draft, it > wouldn't exactly be hard to implement. It won't take NAT to anonymize > the PCs on a LAN with IPv6. See RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6. Regards, Janos Mohacsi From bmanning at vacation.karoshi.com Thu Apr 22 09:34:03 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 22 Apr 2010 14:34:03 +0000 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD0424C.8090000@viagenie.ca> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> Message-ID: <20100422143403.GB8526@vacation.karoshi.com.> On Thu, Apr 22, 2010 at 08:34:20AM -0400, Simon Perreault wrote: > On 2010-04-22 07:18, William Herrin wrote: > >On the other hand, I could swear I've seen a draft where the PC picks > >up random unused addresses in the lower 64 for each new outbound > >connection for anonymity purposes. > > That's probably RFC 4941. It's available in pretty much all operating > systems. I don't think there's any IPR issue to be afraid of. not RFC4941... think abt applying Heddy Lamars patents on spread-spectrum to source address selection. --bill From richard.barnes at gmail.com Thu Apr 22 09:58:44 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Thu, 22 Apr 2010 10:58:44 -0400 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <20100422071720.7f7403b5@opy.nosense.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> Message-ID: Isn't "global addresses you can take with you when you change providers" kind of the definition of Provider Independent address space? If you want to keep the same addresses when you change providers, you just need to get a PI allocation. --Richard On Wed, Apr 21, 2010 at 5:47 PM, Mark Smith wrote: > On Wed, 21 Apr 2010 09:25:46 -0400 > Christopher Morrow wrote: > >> On Wed, Apr 21, 2010 at 1:29 AM, Owen DeLong wrote: >> > While I think this is an improvement, unless the distribution of ULA-C is no cheaper >> > and no easier to get than GUA, I still think there is reason to believe that it is likely >> > ULA-C will become de facto GUA over the long term. >> > >> > As such, I still think the current draft is a bad idea absent appropriate protections in >> > RIR policy. >> >> I agree with owen, mostly... except I think we should just push RIR's >> to make GUA accessible to folks that need ipv6 adress space, >> regardless of connectiivty to thegreater 'internet' (for some >> definition of that thing). >> >> ULA of all types causes headaches on hosts, routers, etc. There is no >> reason to go down that road, just use GUA (Globally Unique Addresses). >> > > So what happens when you change providers? How are you going to keep > using globals that now aren't yours? > > I'm also curious about these headaches. What are they? > > >> -Chris >> > > From jlightfoot at gmail.com Thu Apr 22 10:04:54 2010 From: jlightfoot at gmail.com (John Lightfoot) Date: Thu, 22 Apr 2010 11:04:54 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100422143403.GB8526@vacation.karoshi.com.> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <20100422143403.GB8526@vacation.karoshi.com.> Message-ID: <006901cae22d$2b1ce4c0$8156ae40$@gmail.com> That's Hedley. -----Original Message----- From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] Sent: Thursday, April 22, 2010 10:34 AM To: Simon Perreault Cc: nanog at nanog.org Subject: Re: Rate of growth on IPv6 not fast enough? On Thu, Apr 22, 2010 at 08:34:20AM -0400, Simon Perreault wrote: > On 2010-04-22 07:18, William Herrin wrote: > >On the other hand, I could swear I've seen a draft where the PC picks > >up random unused addresses in the lower 64 for each new outbound > >connection for anonymity purposes. > > That's probably RFC 4941. It's available in pretty much all operating > systems. I don't think there's any IPR issue to be afraid of. not RFC4941... think abt applying Heddy Lamars patents on spread-spectrum to source address selection. --bill From mhuff at ox.com Thu Apr 22 10:10:50 2010 From: mhuff at ox.com (Matthew Huff) Date: Thu, 22 Apr 2010 11:10:50 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <006901cae22d$2b1ce4c0$8156ae40$@gmail.com> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <20100422143403.GB8526@vacation.karoshi.com.> <006901cae22d$2b1ce4c0$8156ae40$@gmail.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F9E2BEEC6D62@PUR-EXCH07.ox.com> Actually, no. Not from the Mel Brooks movie. Hedy Lamarr http://en.wikipedia.org/wiki/Hedy_Lamarr Hedy Lamarr (November 9, 1914 - January 19, 2000) was an Austrian-born American actress and engineer. Though known primarily for her film career as a major contract star of MGM's "Golden Age", she also co-invented an early form of spread spectrum communications technology, a key to modern wireless communication.[1] ---- Matthew Huff?????? | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 > -----Original Message----- > From: John Lightfoot [mailto:jlightfoot at gmail.com] > Sent: Thursday, April 22, 2010 11:05 AM > To: bmanning at vacation.karoshi.com; 'Simon Perreault' > Cc: nanog at nanog.org > Subject: RE: Rate of growth on IPv6 not fast enough? > > That's Hedley. > > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > Sent: Thursday, April 22, 2010 10:34 AM > To: Simon Perreault > Cc: nanog at nanog.org > Subject: Re: Rate of growth on IPv6 not fast enough? > > On Thu, Apr 22, 2010 at 08:34:20AM -0400, Simon Perreault wrote: > > On 2010-04-22 07:18, William Herrin wrote: > > >On the other hand, I could swear I've seen a draft where the PC picks > > >up random unused addresses in the lower 64 for each new outbound > > >connection for anonymity purposes. > > > > That's probably RFC 4941. It's available in pretty much all operating > > systems. I don't think there's any IPR issue to be afraid of. > > not RFC4941... think abt applying Heddy Lamars > patents on spread-spectrum to source address selection. > > --bill > > -------------- next part -------------- A non-text attachment was scrubbed... Name: Matthew Huff.vcf Type: text/x-vcard Size: 1612 bytes Desc: Matthew Huff.vcf URL: From LarrySheldon at cox.net Thu Apr 22 10:13:49 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 22 Apr 2010 10:13:49 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <006901cae22d$2b1ce4c0$8156ae40$@gmail.com> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <20100422143403.GB8526@vacation.karoshi.com.> <006901cae22d$2b1ce4c0$8156ae40$@gmail.com> Message-ID: <4BD067AD.4030602@cox.net> On 4/22/2010 10:04, John Lightfoot wrote: > That's Hedley. > > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > Sent: Thursday, April 22, 2010 10:34 AM > To: Simon Perreault > Cc: nanog at nanog.org > Subject: Re: Rate of growth on IPv6 not fast enough? > > On Thu, Apr 22, 2010 at 08:34:20AM -0400, Simon Perreault wrote: >> On 2010-04-22 07:18, William Herrin wrote: >>> On the other hand, I could swear I've seen a draft where the PC picks >>> up random unused addresses in the lower 64 for each new outbound >>> connection for anonymity purposes. >> >> That's probably RFC 4941. It's available in pretty much all operating >> systems. I don't think there's any IPR issue to be afraid of. > > not RFC4941... think abt applying Heddy Lamars > patents on spread-spectrum to source address selection. Hedwig Eva Maria Kiesler aka Hedy Lamarr -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From w3yni1 at gmail.com Thu Apr 22 10:17:56 2010 From: w3yni1 at gmail.com (Charles Mills) Date: Thu, 22 Apr 2010 11:17:56 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9E2BEEC6D62@PUR-EXCH07.ox.com> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <20100422143403.GB8526@vacation.karoshi.com.> <006901cae22d$2b1ce4c0$8156ae40$@gmail.com> <483E6B0272B0284BA86D7596C40D29F9E2BEEC6D62@PUR-EXCH07.ox.com> Message-ID: I think he was actually quoting the movie. They always called Harvey Korman's character "Hedy" and he'd always correct them with "That's Hedley" in a most disapproving tone. You had to have watched that movie way too many times (much to my wife's chagrin) to catch the subtle joke. On Thu, Apr 22, 2010 at 11:10 AM, Matthew Huff wrote: > Actually, no. > > Not from the Mel Brooks movie. > > Hedy Lamarr > > http://en.wikipedia.org/wiki/Hedy_Lamarr > > Hedy Lamarr (November 9, 1914 - January 19, 2000) was an Austrian-born American actress and engineer. Though known primarily for her film career as a major contract star of MGM's "Golden Age", she also co-invented an early form of spread spectrum communications technology, a key to modern wireless communication.[1] > > > ---- > Matthew Huff?????? | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > http://www.ox.com ?| Phone: 914-460-4039 > aim: matthewbhuff? | Fax:?? 914-460-4139 > > > >> -----Original Message----- >> From: John Lightfoot [mailto:jlightfoot at gmail.com] >> Sent: Thursday, April 22, 2010 11:05 AM >> To: bmanning at vacation.karoshi.com; 'Simon Perreault' >> Cc: nanog at nanog.org >> Subject: RE: Rate of growth on IPv6 not fast enough? >> >> That's Hedley. >> >> -----Original Message----- >> From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] >> Sent: Thursday, April 22, 2010 10:34 AM >> To: Simon Perreault >> Cc: nanog at nanog.org >> Subject: Re: Rate of growth on IPv6 not fast enough? >> >> On Thu, Apr 22, 2010 at 08:34:20AM -0400, Simon Perreault wrote: >> > On 2010-04-22 07:18, William Herrin wrote: >> > >On the other hand, I could swear I've seen a draft where the PC picks >> > >up random unused addresses in the lower 64 for each new outbound >> > >connection for anonymity purposes. >> > >> > That's probably RFC 4941. It's available in pretty much all operating >> > systems. I don't think there's any IPR issue to be afraid of. >> >> ? ? ? not RFC4941... think abt applying Heddy Lamars >> ? ? ? patents on spread-spectrum to source address selection. >> >> --bill >> >> > > From tme at americafree.tv Thu Apr 22 10:25:24 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 22 Apr 2010 11:25:24 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <006901cae22d$2b1ce4c0$8156ae40$@gmail.com> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <20100422143403.GB8526@vacation.karoshi.com.> <006901cae22d$2b1ce4c0$8156ae40$@gmail.com> Message-ID: <120252AE-C717-4CF3-89AB-5A3E652992F9@americafree.tv> On Apr 22, 2010, at 11:04 AM, John Lightfoot wrote: > That's Hedley. > I believe that he is talking about Hedy Lamarr, the co-inventor of frequency hopping spread spectrum. Regards Marshall > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com > ] > Sent: Thursday, April 22, 2010 10:34 AM > To: Simon Perreault > Cc: nanog at nanog.org > Subject: Re: Rate of growth on IPv6 not fast enough? > > On Thu, Apr 22, 2010 at 08:34:20AM -0400, Simon Perreault wrote: >> On 2010-04-22 07:18, William Herrin wrote: >>> On the other hand, I could swear I've seen a draft where the PC >>> picks >>> up random unused addresses in the lower 64 for each new outbound >>> connection for anonymity purposes. >> >> That's probably RFC 4941. It's available in pretty much all operating >> systems. I don't think there's any IPR issue to be afraid of. > > not RFC4941... think abt applying Heddy Lamars > patents on spread-spectrum to source address selection. > > --bill > > > > From LarrySheldon at cox.net Thu Apr 22 10:25:43 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 22 Apr 2010 10:25:43 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <20100422143403.GB8526@vacation.karoshi.com.> <006901cae22d$2b1ce4c0$8156ae40$@gmail.com> <483E6B0272B0284BA86D7596C40D29F9E2BEEC6D62@PUR-EXCH07.ox.com> Message-ID: <4BD06A77.3080401@cox.net> On 4/22/2010 10:17, Charles Mills wrote: > I think he was actually quoting the movie. They always called Harvey > Korman's character "Hedy" and he'd always correct them with "That's > Hedley" in a most disapproving tone. Oh. The only thing I watch less-of than TV is movies. Say....did they ever make a sequel to "Crocodile Dundee"? -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From drc at virtualized.org Thu Apr 22 10:03:52 2010 From: drc at virtualized.org (David Conrad) Date: Thu, 22 Apr 2010 08:03:52 -0700 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> Message-ID: On Apr 21, 2010, at 10:48 PM, Christopher Morrow wrote: >> So what happens when you change providers? How are you going to keep >> using globals that now aren't yours? > use pi space, request it from your local friendly RIR. And don't forget to invest in memory manufacturers and router vendors :-) Regards, -drc From bogstad at pobox.com Thu Apr 22 11:13:07 2010 From: bogstad at pobox.com (Bill Bogstad) Date: Thu, 22 Apr 2010 12:13:07 -0400 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> Message-ID: On Thu, Apr 22, 2010 at 11:03 AM, David Conrad wrote: > On Apr 21, 2010, at 10:48 PM, Christopher Morrow wrote: >>> So what happens when you change providers? How are you going to keep >>> using globals that now aren't yours? >> use pi space, request it from your local friendly RIR. > > And don't forget to invest in memory manufacturers and router vendors :-) Only required if those addresses are advertised to the Internet. Which is apparently NOT what people want to do with it. In addition, it seems like the RIRs frown on not publishing your IPv6 PI allocations. If you go this route, be sure to 'justify' as large an allocation as you could ever possibly imagine using because you'll only get one bite from that apple. Or maybe someone could offer to advertise these deliberately unreachable addresses for a small fee and then null route any stray packets that happen to want to get there. Would this satisfy the letter (if not the spirit) for justifying PI space? Bill Bogstad From surfer at mauigateway.com Thu Apr 22 12:23:42 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 22 Apr 2010 10:23:42 -0700 Subject: Rate of growth on IPv6 not fast enough? Message-ID: <20100422102342.53A1DD3@resin17.mta.everyone.net> --- jimb at jsbc.cc wrote: From: Jim Burwell I think this is different. They're talking about using a new IPv6 for each connection. RFC4941 just changes it over time IIRC. IMHO that's still pretty good privacy, at least on par with a NATed IPv4 from the outside perspective, especially if you rotated through temporary IPv6s fairly frequently. Of course, for browsers, as someone else mentioned, it's somewhat moot because of cookies. -------------------------------------------- Manage your cookies. preferences => privacy & security => cookies => select "ask for each cookie" Noisy in the beginning and then settles down after a while. Surprising, though, in what is tracked, so it's worth doing for a while just to observe. Oh, yeah, also manage your Flash cookies: http://macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html scott From morrowc.lists at gmail.com Thu Apr 22 13:23:23 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 22 Apr 2010 14:23:23 -0400 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> Message-ID: On Thu, Apr 22, 2010 at 12:13 PM, Bill Bogstad wrote: > On Thu, Apr 22, 2010 at 11:03 AM, David Conrad wrote: >> On Apr 21, 2010, at 10:48 PM, Christopher Morrow wrote: >>>> So what happens when you change providers? How are you going to keep >>>> using globals that now aren't yours? >>> use pi space, request it from your local friendly RIR. >> >> And don't forget to invest in memory manufacturers and router vendors :-) > > Only required if those addresses are advertised to the Internet. > Which is apparently NOT > what people want to do with it. ? In addition, it seems like the RIRs > frown on not publishing your IPv6 PI allocations. ?If you go this this is commonly held up as a reason that getting allocations is hard, but the infrastructure micro-allocations are never to be seen in the global table. It woudl be super nice if some kind RIR people could comment here, I believe in the ARIN region all you NEED to do is provide a spreadsheet showing your utilization, checking for the routes in the 'DFZ' (bmanning-summons) isn't relevant for additional requests. > route, be sure to 'justify' as large an allocation as you could ever > possibly imagine using because you'll only get one bite from that > apple. see previous comment, I believe this is a red-herring. > > Or maybe someone could offer to advertise these deliberately > unreachable addresses for a small fee and then null route any stray > packets that happen to want to get > there. ? Would this satisfy the letter (if not the spirit) for > justifying PI space? you still have to provide SWIP, RWHOIS or some other accounting of the usage (spreadsheet/csvfile seems to be historically acceptable) -chris > Bill Bogstad > > From bmanning at vacation.karoshi.com Thu Apr 22 14:09:30 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 22 Apr 2010 19:09:30 +0000 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> Message-ID: <20100422190930.GB12268@vacation.karoshi.com.> > believe in the ARIN region all you NEED to do is provide a spreadsheet > showing your utilization, checking for the routes in the 'DFZ' > (bmanning-summons) isn't relevant for additional requests. "... all circuits are busy, please call back later..." > -chris --bill From dhc2 at dcrocker.net Thu Apr 22 14:39:15 2010 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Thu, 22 Apr 2010 12:39:15 -0700 Subject: Mail Submission Protocol In-Reply-To: References: <31682932.1060.1271904876633.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4BD0A5E3.3070405@dcrocker.net> On 4/21/2010 8:16 PM, Suresh Ramasubramanian wrote: > The MAAWG BCPs have far more available than one of the worst > maintained blacklists that has ever been in existence. For example: d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From if at xip.at Thu Apr 22 17:26:57 2010 From: if at xip.at (Ingo Flaschberger) Date: Fri, 23 Apr 2010 00:26:57 +0200 (CEST) Subject: sync attack from cox.net Message-ID: Hi, can please someone from cox.net contact me? I receive now since more tha 24 hours a syn-attack from their network - and abuse contact does not react. Kind regards, ingo flaschberger geschaeftsleitung ____________________________________ crossip communications gmbh A-1020 Wien, Sebastian Kneipp Gasse 1 Tel: +43-1-7261522-0 Fax: +43-1-726 15 22-111 www.crossip.net _______________________________________________________________________________ crossip communications gmbh Sitz der Gesellschaft: 1020 Wien, Oesterreich Firmenbuchgericht: Handelsgericht Wien, FN 269698 s Umsatzsteueridentifikationsnummer (UID): ATU62080367 Diese Nachricht ist fuer die crossip communications gmbh rechtsunverbindlich und ausschliesslich fuer den/die oben bezeichneten Adressaten bestimmt und enthaelt moeglicherweise vertrauliche Informationen. Sollten Sie nicht der oben bezeichnete Adressat sein oder diese Nachricht irrtuemlich erhalten haben, ersuchen wir Sie, diese Nachricht nicht weiterzugeben, zu kopieren oder im Vertrauen darauf zu handeln, sondern den Absender zu verstaendigen und diese Nachricht samt allfaelliger Anlagen sofort zu loeschen. Vielen Dank. This message is not legally binding upon crossip communications gbmbh and is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee, you should not disseminate, copy, or take any action in reliance on it. If you have received this message in error, please immediately notify the sender and delete this message and any attachment. Thank you. From eric.carroll at acm.org Thu Apr 22 22:22:53 2010 From: eric.carroll at acm.org (Eric Carroll) Date: Thu, 22 Apr 2010 23:22:53 -0400 Subject: iabelle francois In-Reply-To: <4BCF8336.4020102@mompl.net> References: <4BCF8336.4020102@mompl.net> Message-ID: <4BD1128D.5090505@acm.org> On 10-04-21 06:59 PM, Jeroen van Aart wrote: > The url redirects to a Canadian med site. Just FYI, it's not a real Canadian med site. It is high probability not even Canadian. The site appears to be a referral round robin over many domain names, including: - www.yourtabletrxhealth.com/ - traceroute to AS12880 "Data communication Company of Iran" - www.superstorepills.net/ - traceroute to AS9737 TOT Public Company Limited - www.bargainpillsstore.net - traceroute to AS4134 CHINANET-BACKBONE - www.losspillssite.net - traceroute to AS4837 CHINA169-Backbone etc. The www.yourtabletrxhealth.com domain name was created April 5 of 2010 and has Russian contact address information. http://whois.domaintools.com/yourtabletrxhealth.com Parts of the www.yourtabletrxhealth.com web pages are pulled in from all over, including AS9486, AS9737. The "license" at the bottom is fake. The controlling professional body in Ontario is the Ontario College of Pharmacists not "College of Pharmacists of Ontario". In Ontario, the language is that Pharmacies are accredited, not licensed. Pharmacists are licensed. The Verisign click-through is fake. OCP has no record of this company by name, location or number. See https://members.ocpinfo.com/ocpsearch/ The CEO is claimed to be affiliated with University of Western Ontario. Can't find them. Feel free to check out Kingston ON in Google street view for added amusement. And its listed in spamwiki. Regards, Eric Carroll From ml-nanog090304q at elcsplace.com Thu Apr 22 23:33:00 2010 From: ml-nanog090304q at elcsplace.com (Ted Cooper) Date: Fri, 23 Apr 2010 14:33:00 +1000 Subject: iabelle francois In-Reply-To: <4BD1128D.5090505@acm.org> References: <4BCF8336.4020102@mompl.net> <4BD1128D.5090505@acm.org> Message-ID: <1271997180.3980.413.camel@ubuntu.ubuntu-domain> On Thu, 2010-04-22 at 23:22 -0400, Eric Carroll wrote: > On 10-04-21 06:59 PM, Jeroen van Aart wrote: > > The url redirects to a Canadian med site. > Just FYI, it's not a real Canadian med site. It is high probability > not > even Canadian. Posting so many URLs which either are or should be listed in domain block lists to a list with as many subscribers as this is probably not wise. I'm guessing you just caused a wonderful bounce storm as the NANOG servers attempted to send that out, depending of course on how many people whitelist NANOG to URI filtering. yourtabletrxhealth[dot]com - URIBL black 2010-04-22 00:07:14 GMT superstorepills[dot]net - URLBL black 2010-04-21 20:47:31 GMT bargainpillsstore[dot]net - URLBL black 2010-04-15 20:41:59 GMT losspillssite[dot]net - URLBL black 2010-04-21 20:45:09 GMT The analysis of the domain is solid though, so good work there. Perhaps NANOG is not the correct forum though? Spam-L seems like a better fit. From owen at delong.com Thu Apr 22 23:29:49 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Apr 2010 21:29:49 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100422113039.GA8190@vacation.karoshi.com.> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <20100422113039.GA8190@vacation.karoshi.com.> Message-ID: <3FAFA554-8CF3-4329-9B8A-D3CC02175B97@delong.com> On Apr 22, 2010, at 4:30 AM, bmanning at vacation.karoshi.com wrote: >> >> On the other hand, I could swear I've seen a draft where the PC picks >> up random unused addresses in the lower 64 for each new outbound >> connection for anonymity purposes. Even if there is no such draft, it >> wouldn't exactly be hard to implement. It won't take NAT to anonymize >> the PCs on a LAN with IPv6. > > the idea is covered by one or more patents held by cisco. > > --bill > >> Regards, >> Bill Herrin It's default behavior in Windows 7 and is specified in an RFC. Look for IPv6 Privacy Addressing. Owen From owen at delong.com Fri Apr 23 00:00:35 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Apr 2010 22:00:35 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD04752.9050602@jsbc.cc> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <4BD04752.9050602@jsbc.cc> Message-ID: On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 4/22/2010 05:34, Simon Perreault wrote: >> On 2010-04-22 07:18, William Herrin wrote: >>> On the other hand, I could swear I've seen a draft where the PC >>> picks up random unused addresses in the lower 64 for each new >>> outbound connection for anonymity purposes. >> >> That's probably RFC 4941. It's available in pretty much all >> operating systems. I don't think there's any IPR issue to be afraid >> of. >> >> Simon > I think this is different. They're talking about using a new IPv6 for > each connection. RFC4941 just changes it over time IIRC. IMHO that's > still pretty good privacy, at least on par with a NATed IPv4 from the > outside perspective, especially if you rotated through temporary IPv6s > fairly frequently. 4941 specified changing over time as one possibility. It does allow for per flow or any other host based determination of when it needs a new address. Owen From owen at delong.com Fri Apr 23 00:07:21 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Apr 2010 22:07:21 -0700 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> Message-ID: <8586A86B-1999-47EB-9EEA-3D90C2BCF96C@delong.com> On Apr 22, 2010, at 9:13 AM, Bill Bogstad wrote: > On Thu, Apr 22, 2010 at 11:03 AM, David Conrad wrote: >> On Apr 21, 2010, at 10:48 PM, Christopher Morrow wrote: >>>> So what happens when you change providers? How are you going to keep >>>> using globals that now aren't yours? >>> use pi space, request it from your local friendly RIR. >> >> And don't forget to invest in memory manufacturers and router vendors :-) > > Only required if those addresses are advertised to the Internet. > Which is apparently NOT > what people want to do with it. In addition, it seems like the RIRs > frown on not publishing your IPv6 PI allocations. If you go this > route, be sure to 'justify' as large an allocation as you could ever > possibly imagine using because you'll only get one bite from that > apple. > We're working on policy to address that within the ARIN region. I suspect it will get addressed elsewhere as well. The bigger concern (and original intent of the phrases driving that concern) was that it be advertised as a single prefix and not multiple prefixes hitting the DFZ. Owen From matthew at matthew.at Fri Apr 23 00:18:56 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 22 Apr 2010 22:18:56 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <4BD04752.9050602@jsbc.cc> Message-ID: <4BD12DC0.6080004@matthew.at> Owen DeLong wrote: > On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote: > > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 4/22/2010 05:34, Simon Perreault wrote: >> >>> On 2010-04-22 07:18, William Herrin wrote: >>> >>>> On the other hand, I could swear I've seen a draft where the PC >>>> picks up random unused addresses in the lower 64 for each new >>>> outbound connection for anonymity purposes. >>>> >>> That's probably RFC 4941. It's available in pretty much all >>> operating systems. I don't think there's any IPR issue to be afraid >>> of. >>> >>> Simon >>> >> I think this is different. They're talking about using a new IPv6 for >> each connection. RFC4941 just changes it over time IIRC. IMHO that's >> still pretty good privacy, at least on par with a NATed IPv4 from the >> outside perspective, especially if you rotated through temporary IPv6s >> fairly frequently. >> > > 4941 specified changing over time as one possibility. It does allow > for per flow or any other host based determination of when it needs a new > address. > > Owen > > > But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from. Matthew Kaufman From jimb at jsbc.cc Fri Apr 23 00:21:09 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Thu, 22 Apr 2010 22:21:09 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <4BD04752.9050602@jsbc.cc> Message-ID: <4BD12E45.4060606@jsbc.cc> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/22/2010 22:00, Owen DeLong wrote: > > On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 4/22/2010 05:34, Simon Perreault wrote: >>> On 2010-04-22 07:18, William Herrin wrote: >>>> On the other hand, I could swear I've seen a draft where the >>>> PC picks up random unused addresses in the lower 64 for each >>>> new outbound connection for anonymity purposes. >>> >>> That's probably RFC 4941. It's available in pretty much all >>> operating systems. I don't think there's any IPR issue to be >>> afraid of. >>> >>> Simon >> I think this is different. They're talking about using a new >> IPv6 for each connection. RFC4941 just changes it over time >> IIRC. IMHO that's still pretty good privacy, at least on par >> with a NATed IPv4 from the outside perspective, especially if you >> rotated through temporary IPv6s fairly frequently. > > 4941 specified changing over time as one possibility. It does > allow for per flow or any other host based determination of when it > needs a new address. > > Owen K. Can't say I've read the RFC all the way through (skimmed it). Current implementations do the time thing. XP, Vista, and 7 seem to have it turned on by default. *nix has support via the "net.ipv6.conf.all.use_tempaddr=2" variable, typically not on by default. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvRLkUACgkQ2fXFxl4S7sQ2YgCg3uSkp1GNxcgjCDVc1jxnDv7s DtoAniXH8nND7+r6xEFJXGHrRJ77CBkZ =eSHI -----END PGP SIGNATURE----- From jimb at jsbc.cc Fri Apr 23 00:29:15 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Thu, 22 Apr 2010 22:29:15 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD12DC0.6080004@matthew.at> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <4BD04752.9050602@jsbc.cc> <4BD12DC0.6080004@matthew.at> Message-ID: <4BD1302B.9040008@jsbc.cc> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/22/2010 22:18, Matthew Kaufman wrote: > Owen DeLong wrote: >> On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote: >> >> >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 4/22/2010 05:34, Simon Perreault wrote: >>> >>>> On 2010-04-22 07:18, William Herrin wrote: >>>> >>>>> On the other hand, I could swear I've seen a draft where >>>>> the PC picks up random unused addresses in the lower 64 for >>>>> each new outbound connection for anonymity purposes. >>>>> >>>> That's probably RFC 4941. It's available in pretty much all >>>> operating systems. I don't think there's any IPR issue to be >>>> afraid of. >>>> >>>> Simon >>>> >>> I think this is different. They're talking about using a new >>> IPv6 for each connection. RFC4941 just changes it over time >>> IIRC. IMHO that's still pretty good privacy, at least on par >>> with a NATed IPv4 from the outside perspective, especially if >>> you rotated through temporary IPv6s fairly frequently. >>> >> >> 4941 specified changing over time as one possibility. It does >> allow for per flow or any other host based determination of when >> it needs a new address. >> >> Owen >> >> >> > But none of this does what NAT does for a big enterprise, which is > to *hide internal topology*. Yes, addressing the privacy concerns > that come from using lower-64-bits-derived-from-MAC-address is > required, but it is also necessary (for some organizations) to > make it impossible to tell that this host is on the same subnet as > that other host, as that would expose information like which host > you might want to attack in order to get access to the financial > or medical records, as well as whether or not the executive floor > is where these interesting website hits came from. > > Matthew Kaufman Yeh that information leak is one reason I can think of for supporting NAT for IPv6. One of the inherent security issues with unique addresses I suppose. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvRMCsACgkQ2fXFxl4S7sShwACgpZEd1rQD+/+dxonkOVpwPaUj oBIAoOJ78A5Yvftfz+JPjGWWQoVhb6F8 =oQHv -----END PGP SIGNATURE----- From nanog2 at adns.net Fri Apr 23 01:04:50 2010 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Fri, 23 Apr 2010 01:04:50 -0500 Subject: iabelle francois References: <4BCF8336.4020102@mompl.net> <4BD1128D.5090505@acm.org> <1271997180.3980.413.camel@ubuntu.ubuntu-domain> Message-ID: ----- Original Message ----- From: "Ted Cooper" To: Sent: Thursday, April 22, 2010 11:33 PM Subject: Re: iabelle francois .... > Posting so many URLs which either are or should be listed in domain > block lists to a list with as many subscribers as this is probably not > wise. I'm guessing you just caused a wonderful bounce storm as the NANOG > servers attempted to send that out, depending of course on how many > people whitelist NANOG to URI filtering. > ... > The analysis of the domain is solid though, so good work there. Perhaps > NANOG is not the correct forum though? Spam-L seems like a better fit. > Spam-watch.com is the proper place for it. From steve at ibctech.ca Fri Apr 23 01:50:23 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 23 Apr 2010 02:50:23 -0400 Subject: Connectivity to an IPv6-only site Message-ID: <4BD1432F.4070406@ibctech.ca> This is a no-brainer, because I know that everyone who reads this will visit the link. All I request is an off-list message stating if you could get there or not (it won't be possible to parse my weblogs for those who can't): http://onlyv6.com Operationally, I want to personally take a very rough inventory on the number of people who can get to the site, and who can't. The purpose of this is so that I can gain deeper insight into troubles that the inevitable v6 only networks are going to face, and what impact will occur to an ISP that is currently thinking that v6 is not for them. All findings will be publicly posted. Steve From thomas at habets.pp.se Fri Apr 23 02:26:10 2010 From: thomas at habets.pp.se (Thomas Habets) Date: Fri, 23 Apr 2010 09:26:10 +0200 (CEST) Subject: Mikrotik RouterOS In-Reply-To: <20100421231422.GD5371@ref.nmedia.net> References: <4BC36C83.7040200@freedomnet.co.nz> <4BC36E27.4000005@gmail.com> <4BC37928.5030004@Janoszka.pl> <4BC37D55.6050806@freedomnet.co.nz> <1271120175.15669.35.camel@ub-g-d2> <20100421231422.GD5371@ref.nmedia.net> Message-ID: On Wed, 21 Apr 2010, Chris Cappuccio wrote: > OpenBSD post-4.7 (current) is about to get a full BGP MPLS VPN > implementation and has ldp working too. Yeah baby I wouldn't run MPLS with OpenBSD in production quite yet though. Until I sent in a patch earlier this month it sent out implicit null (label 3) over the wire, for example. There are other bugs still there, but CVS doesn't exactly invite outside help. Hint hint, BSD folks. --------- typedef struct me_s { char name[] = { "Thomas Habets" }; char email[] = { "thomas at habets.pp.se" }; char kernel[] = { "Linux" }; char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt" }; char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854" }; char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" }; } me_t; From mohacsi at niif.hu Fri Apr 23 02:28:09 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Fri, 23 Apr 2010 09:28:09 +0200 (CEST) Subject: Connectivity to an IPv6-only site In-Reply-To: <4BD1432F.4070406@ibctech.ca> References: <4BD1432F.4070406@ibctech.ca> Message-ID: Hi, What is your method to discover who cannot connect to your webserver? Regards, Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Fri, 23 Apr 2010, Steve Bertrand wrote: > This is a no-brainer, because I know that everyone who reads this will > visit the link. All I request is an off-list message stating if you > could get there or not (it won't be possible to parse my weblogs for > those who can't): > > http://onlyv6.com > > Operationally, I want to personally take a very rough inventory on the > number of people who can get to the site, and who can't. > > The purpose of this is so that I can gain deeper insight into troubles > that the inevitable v6 only networks are going to face, and what impact > will occur to an ISP that is currently thinking that v6 is not for them. > > All findings will be publicly posted. > > Steve > > From steve at ibctech.ca Fri Apr 23 02:30:30 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 23 Apr 2010 03:30:30 -0400 Subject: Connectivity to an IPv6-only site In-Reply-To: <4BD1432F.4070406@ibctech.ca> References: <4BD1432F.4070406@ibctech.ca> Message-ID: <4BD14C96.1040100@ibctech.ca> On 2010.04.23 02:50, Steve Bertrand wrote: > This is a no-brainer, because I know that everyone who reads this will > visit the link. All I request is an off-list message stating if you > could get there or not (it won't be possible to parse my weblogs for > those who can't): > > http://onlyv6.com > > Operationally, I want to personally take a very rough inventory on the > number of people who can get to the site, and who can't. > > The purpose of this is so that I can gain deeper insight into troubles > that the inevitable v6 only networks are going to face, and what impact > will occur to an ISP that is currently thinking that v6 is not for them. Even though this is the middle of the night, I am being inundated with responses (which is fantastic by the way). Let me expand on my request quickly, and I'll post a 'why I think it's breaking for some of you' immediately after. If you could, if you have an IPv6 address, include that in your message, and if possible, your AS as well. This information will not be made public, but will help tremendously with my personal research. Thanks, Steve From LarrySheldon at cox.net Fri Apr 23 02:35:54 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 23 Apr 2010 02:35:54 -0500 Subject: Connectivity to an IPv6-only site In-Reply-To: <4BD1432F.4070406@ibctech.ca> References: <4BD1432F.4070406@ibctech.ca> Message-ID: <4BD14DDA.4010505@cox.net> On 4/23/2010 01:50, Steve Bertrand wrote: > This is a no-brainer, because I know that everyone who reads this will > visit the link. All I request is an off-list message stating if you > could get there or not (it won't be possible to parse my weblogs for > those who can't): > > http://onlyv6.com > > Operationally, I want to personally take a very rough inventory on the > number of people who can get to the site, and who can't. > > The purpose of this is so that I can gain deeper insight into troubles > that the inevitable v6 only networks are going to face, and what impact > will occur to an ISP that is currently thinking that v6 is not for them. > > All findings will be publicly posted. >From my PC at home (Cox in Omaha) I can't even get a nameserver that knows the site. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Fri Apr 23 02:39:21 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 23 Apr 2010 02:39:21 -0500 Subject: Connectivity to an IPv6-only site In-Reply-To: <4BD14DDA.4010505@cox.net> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> Message-ID: <4BD14EA9.7090709@cox.net> On 4/23/2010 02:35, Larry Sheldon wrote: >>From my PC at home (Cox in Omaha) I can't even get a nameserver that > knows the site. I should point out that I am really stupid about v6--I don't know if I should be able to find a nameserver or not. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From steve at ibctech.ca Fri Apr 23 02:41:15 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 23 Apr 2010 03:41:15 -0400 Subject: Connectivity to an IPv6-only site In-Reply-To: References: <4BD1432F.4070406@ibctech.ca> Message-ID: <4BD14F1B.5060309@ibctech.ca> On 2010.04.23 03:28, Mohacsi Janos wrote: > Hi, > What is your method to discover who cannot connect to your webserver? No. It's not *who* but *why*. This is a personal research project. I'm trying to identify where breakage happens when trying to connect to an IPv6-only network. There are so many places within the Internet that this could happen, I just thought that I'd test it for myself, and then try to attract traffic to the site from across the globe so I could identify edge-cases that I hadn't thought about. This blog post describes the basics of why most sites won't be able to traverse the IPv6 network, even if they are v6 enabled locally: http://ipv6canada.com/?p=92 I'd be glad to get into much deeper detail than this... I'm just a bit caught up at 0400 hrs est when I need to be up in two hours. Reminds me a bit of the ARIN meeting ;) Keep the feedback coming...please. Steve ps. During the time I was setting up this test case, I somehow broke my email server (even though that is a completely different box), so some of my email isn't going out (from what I can tell, this might have included some that were destined for someone on the ARIN BoT. If you have seen weird gaps in conversation, this is likely why). From steve at ibctech.ca Fri Apr 23 02:57:45 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 23 Apr 2010 03:57:45 -0400 Subject: Connectivity to an IPv6-only site In-Reply-To: <4BD14EA9.7090709@cox.net> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD14EA9.7090709@cox.net> Message-ID: <4BD152F9.9000106@ibctech.ca> On 2010.04.23 03:39, Larry Sheldon wrote: > On 4/23/2010 02:35, Larry Sheldon wrote: > >> >From my PC at home (Cox in Omaha) I can't even get a nameserver that >> knows the site. > > I should point out that I am really stupid about v6--I don't know if I > should be able to find a nameserver or not. Has nothing to do about being stupid... let's rephrase your statement and put a positive spin on it as such: "I've heard about IPv6, but don't know very much about it. I think that I should know more, but am a bit confused as to where to begin. What do I do first?". Then I'd say: "As a start, go to http://www.getipv6.info/index.php/Main_Page . If that doesn't get you going, then let the rest of the community start posting the resources that they know about, ranging from beginner up to the advanced.". Steve From franck at genius.com Fri Apr 23 03:00:41 2010 From: franck at genius.com (Franck Martin) Date: Fri, 23 Apr 2010 20:00:41 +1200 Subject: Connectivity to an IPv6-only site In-Reply-To: <4BD152F9.9000106@ibctech.ca> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD14EA9.7090709@cox.net> <4BD152F9.9000106@ibctech.ca> Message-ID: Go get an airport express, install it get your Internet then click ipv6 enable box and that's it. Seriously! Toute connaissance est une r?ponse ? une question On 23/04/2010, at 19:57, Steve Bertrand wrote: > On 2010.04.23 03:39, Larry Sheldon wrote: >> On 4/23/2010 02:35, Larry Sheldon wrote: >> >>>> From my PC at home (Cox in Omaha) I can't even get a nameserver >>>> that >>> knows the site. >> >> I should point out that I am really stupid about v6--I don't know >> if I >> should be able to find a nameserver or not. > > Has nothing to do about being stupid... let's rephrase your statement > and put a positive spin on it as such: > > "I've heard about IPv6, but don't know very much about it. I think > that > I should know more, but am a bit confused as to where to begin. What > do > I do first?". > > Then I'd say: > > "As a start, go to http://www.getipv6.info/index.php/Main_Page . If > that > doesn't get you going, then let the rest of the community start > posting > the resources that they know about, ranging from beginner up to the > advanced.". > > Steve > From ford at isoc.org Fri Apr 23 03:15:03 2010 From: ford at isoc.org (Matthew Ford) Date: Fri, 23 Apr 2010 09:15:03 +0100 Subject: Connectivity to an IPv6-only site In-Reply-To: References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD14EA9.7090709@cox.net> <4BD152F9.9000106@ibctech.ca> Message-ID: <629E4FD5-1E5B-499F-A221-68A4EFEB59CE@isoc.org> On 23 Apr 2010, at 09:00, Franck Martin wrote: > Go get an airport express, install it get your Internet then click ipv6 enable box and that's it. Seriously! > Hmm. Then why did I just replace my airport and my ISP to get functioning IPv6? Hint: 6to4 != IPv6. Mat From ml-nanog090304q at elcsplace.com Fri Apr 23 03:19:39 2010 From: ml-nanog090304q at elcsplace.com (Ted Cooper) Date: Fri, 23 Apr 2010 18:19:39 +1000 Subject: iabelle francois In-Reply-To: References: <4BCF8336.4020102@mompl.net> <4BD1128D.5090505@acm.org> <1271997180.3980.413.camel@ubuntu.ubuntu-domain> Message-ID: <1272010779.3980.437.camel@ubuntu.ubuntu-domain> On Fri, 2010-04-23 at 01:04 -0500, John Palmer (NANOG Acct) wrote: > Spam-watch.com >From the website: About Spam-watch - This list is meant as a replacement for the SPAM-L list which was abruptly shut down in May 2009. On the contrary - Spam-l.com continues on different hosting with different moderators with an emphasis on collegial behaviour of participants. >From the website: Spam-L.com was created as a cooperative effort to replace the original Spam-L forum which ran for a decade and a half on L-Soft servers. When the original was abandoned on 11 May 2009, this list was set up to keep the forum alive. Hopefully this might now point some people in the right direction? Fin for me. From steve at ibctech.ca Fri Apr 23 03:26:41 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 23 Apr 2010 04:26:41 -0400 Subject: Connectivity to an IPv6-only site In-Reply-To: <4BD14DDA.4010505@cox.net> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> Message-ID: <4BD159C1.2090307@ibctech.ca> On 2010.04.23 03:35, Larry Sheldon wrote: >>From my PC at home (Cox in Omaha) I can't even get a nameserver that > knows the site. Larry... let me explain why. Although you might not understand, others will, and you may remember this as something when you do use IPv6. Believe me, nobody can remember everything, and what I'm trying to achieve here is isolating easy-to-document issues. It may be above your head at this time, but my objective is to find out the rough edges, that net ops will be able to identify quickly when problems arise... much like looking for reckless filtering of ICMP on an IPv6 network. Why you can't get a name server... because this is how the domain is configured: - in WHOIS, I have ns1 and ns2.onlyv6.com listed as the authoritative name servers - both of these servers *only* have IPv6 addresses - the domain registry translates my authoritative name server names into IPv6 addresses, so: Domain servers in listed order: NS1.ONLYV6.COM NS2.ONLYV6.COM - effectively is: ns1.onlyv6.com. 172602 IN AAAA 2607:f118:8c0:800::64 ns2.onlyv6.com. 172591 IN AAAA 2001:470:b086:1::53 - there is absolutely no way that these servers can be contacted over v4. There is no v4 A record available...anywhere. There are two obvious causes of why you can't see me: - you (your ISP) is not v6 enabled - the DNS box that you use for recursion is not properly v6 connected There is a middle ground that I've seen that I believe is as scary as not having IPv6 at all. I've been in environments where an ISP is claiming to be v6 enabled, but only have it geared up toward their clients and to the Internet. Their DNS servers (and other services) are not v6 enabled, so the access clients run into a situation eerily similar to one that I'm trying to document. This is a personal research project, in which I want to learn about the health of connectivity, and about other situations that causes breakage that I haven't considered before. I'd be absolutely pleased to provide IPv6 learning resources, and discuss this further with you off list. Steve From mohacsi at niif.hu Fri Apr 23 03:53:01 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Fri, 23 Apr 2010 10:53:01 +0200 (CEST) Subject: Connectivity to an IPv6-only site In-Reply-To: <629E4FD5-1E5B-499F-A221-68A4EFEB59CE@isoc.org> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD14EA9.7090709@cox.net> <4BD152F9.9000106@ibctech.ca> <629E4FD5-1E5B-499F-A221-68A4EFEB59CE@isoc.org> Message-ID: On Fri, 23 Apr 2010, Matthew Ford wrote: > > On 23 Apr 2010, at 09:00, Franck Martin wrote: > >> Go get an airport express, install it get your Internet then click ipv6 enable box and that's it. Seriously! >> > > Hmm. Then why did I just replace my airport and my ISP to get functioning IPv6? Hint: 6to4 != IPv6. even bridged mode broadband service != broadband service (i.e:airport express 6to4 not working on PPPoE) From steve at ibctech.ca Fri Apr 23 04:21:21 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 23 Apr 2010 05:21:21 -0400 Subject: Connectivity to an IPv6-only site In-Reply-To: References: <4BD1432F.4070406@ibctech.ca> Message-ID: <4BD16691.1070905@ibctech.ca> On 2010.04.23 03:28, Mohacsi Janos wrote: > Hi, > What is your method to discover who cannot connect to your webserver? Earlier, in haste, I mistook your "What" for 'why' the first time I read your question. My method to discover is very clear cut... either you can get to the site, or you can't. Just like when the situation happens in practice, I'll need to be notified via email (unlikely if all of my services are on v6) or phone if you can't reach the website. This is why I requested off-list feedback. Steve From cjeker at diehard.n-r-g.com Fri Apr 23 04:31:49 2010 From: cjeker at diehard.n-r-g.com (Claudio Jeker) Date: Fri, 23 Apr 2010 11:31:49 +0200 Subject: Mikrotik RouterOS In-Reply-To: References: <4BC36C83.7040200@freedomnet.co.nz> <4BC36E27.4000005@gmail.com> <4BC37928.5030004@Janoszka.pl> <4BC37D55.6050806@freedomnet.co.nz> <1271120175.15669.35.camel@ub-g-d2> <20100421231422.GD5371@ref.nmedia.net> Message-ID: <20100423093149.GC19151@diehard.n-r-g.com> On Fri, Apr 23, 2010 at 09:26:10AM +0200, Thomas Habets wrote: > On Wed, 21 Apr 2010, Chris Cappuccio wrote: > >OpenBSD post-4.7 (current) is about to get a full BGP MPLS VPN > >implementation and has ldp working too. Yeah baby > > I wouldn't run MPLS with OpenBSD in production quite yet though. > Until I sent in a patch earlier this month it sent out implicit null > (label 3) over the wire, for example. > Yes, there are still issues, any help sending in bug reports or diffs is welcome. The plan is to have a good MPLS stack in the next release. Still lot to do... > There are other bugs still there, but CVS doesn't exactly invite > outside help. Hint hint, BSD folks. > Common, cvs checkout, modify file, test and when happy cvs diff | mail -s "mpls diff for this and that" tech at openbsd.org isn't too hard. There is a good reason we only have one tree instead of a jungle of unfinished and halfway done stuff. There is no need to figure out which branch or developer flavor you want to test today. Makes testing a hell of a lot simpler. -- :wq Claudio From steve at ibctech.ca Fri Apr 23 04:42:50 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 23 Apr 2010 05:42:50 -0400 Subject: Connectivity to an IPv6-only site In-Reply-To: <4BD1432F.4070406@ibctech.ca> References: <4BD1432F.4070406@ibctech.ca> Message-ID: <4BD16B9A.9090100@ibctech.ca> On 2010.04.23 02:50, Steve Bertrand wrote: > http://onlyv6.com ...email me with your v6 addr/AS whether you can/can't get to that site. I want to thank everyone thus far for all of the feedback. I've received at least four dozen off list replies, and expect many more after the actual North American people wake up. This is, after all, an ops group, so I did expect a somewhat high success rate, but without counting, so far it's about 60%. I'd like to see at least 300 hits. I'm off today to be concerned about something other than being close to email, so I'll just hopefully have lots to read when I get back. The most productive part of this project so far, has been that I've suckered in three people that mailed me privately out of the ARIN lists that I believe are now convinced that v6 is the right way to proceed, and one or two more who emailed on-list ;) One network at a time. Thanks all, Steve From davehart at gmail.com Fri Apr 23 04:49:52 2010 From: davehart at gmail.com (Dave Hart) Date: Fri, 23 Apr 2010 09:49:52 +0000 Subject: Connectivity to an IPv6-only site In-Reply-To: <4BD159C1.2090307@ibctech.ca> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> Message-ID: On Fri, Apr 23, 2010 at 08:26 UTC, Steve Bertrand wrote: > - in WHOIS, I have ns1 and ns2.onlyv6.com listed as the authoritative > name servers > > - both of these servers *only* have IPv6 addresses Which seems a bit far afield from reality to me. Yes, there are lots of folks with IPv6 connectivity and v4-only recursive DNS servers. I don't think ISPs will have problems setting aside a handful of IPv4 addresses for authoritative DNS infrastructure to work around this until v6 transport in recursive DNS servers is common enough. Cheers, Dave Hart From tim at pelican.org Fri Apr 23 06:38:21 2010 From: tim at pelican.org (Tim Franklin) Date: Fri, 23 Apr 2010 11:38:21 +0000 (GMT) Subject: Connectivity to an IPv6-only site In-Reply-To: Message-ID: <17850162.101272022701294.JavaMail.root@jennyfur.pelican.org> > Which seems a bit far afield from reality to me. Yes, there are lots > of folks with IPv6 connectivity and v4-only recursive DNS servers. I > don't think ISPs will have problems setting aside a handful of IPv4 > addresses for authoritative DNS infrastructure to work around this > until v6 transport in recursive DNS servers is common enough. Assuming your ISP is providing your DNS. What if I, as a new start-up in the IPv4-exhausted world, want to buy pure bit-pipes from my ISP, and be responsible for *everything* further up the stack? I don't believe this is entirely uncommon. Regards, Tim. From davehart at gmail.com Fri Apr 23 06:57:47 2010 From: davehart at gmail.com (Dave Hart) Date: Fri, 23 Apr 2010 11:57:47 +0000 Subject: Connectivity to an IPv6-only site In-Reply-To: <17850162.101272022701294.JavaMail.root@jennyfur.pelican.org> References: <17850162.101272022701294.JavaMail.root@jennyfur.pelican.org> Message-ID: On Fri, Apr 23, 2010 at 11:38 UTC, Tim Franklin wrote: > Assuming your ISP is providing your DNS. ?What if I, as a new start-up > in the IPv4-exhausted world, want to buy pure bit-pipes from my ISP, > and be responsible for *everything* further up the stack? ?I don't believe > this is entirely uncommon. Then you're going to either accept the hit to reachability, or you're going to use at least one third-party authoritative DNS service provider who can slave your zone over v6 and serve it over v4. puck.nether.net likely fits the bill and is free of charge. Cheers, Dave Hart From isabeldias1 at yahoo.com Fri Apr 23 07:03:07 2010 From: isabeldias1 at yahoo.com (isabel dias) Date: Fri, 23 Apr 2010 05:03:07 -0700 (PDT) Subject: Connectivity to an IPv6-only site In-Reply-To: <17850162.101272022701294.JavaMail.root@jennyfur.pelican.org> References: <17850162.101272022701294.JavaMail.root@jennyfur.pelican.org> Message-ID: <158474.72490.qm@web52607.mail.re2.yahoo.com> 1- http://onlyv6.com?is not resolving ..... 2- why would anyone be interested in buying "bit-pipes" from you if you don't own fiber or ports in a switch? 3- why would anyone be interested in buying ip address space if?they can do it from SP's themselfs or apply for that ripe allocation? 4- ICIN 2009 highlighted the fact the SP#s are interested in rolling out new ethernet services?- that has been happening for the past years! 5- http://www.potaroo.net/tools/ipv4/index.html?shows the?V4 exhaustion - the depletion of the IPv4 allocation pool has been a concern however is still in use. Understanding the v6 migration is driving the change. http://www.usipv6.com/6sense/2006/mar/pdf/UnderstandingIPv4AddressExhaustion.pdf just seems that it follows the switchover to digital?(2012) ??? ??? ??? ??? ??? http://www.eurescom.eu/Public/Projects/P1900-series/P1952/default.asp ? ? ----- Original Message ---- From: Tim Franklin To: NANOG Sent: Fri, April 23, 2010 12:38:21 PM Subject: Re: Connectivity to an IPv6-only site > Which seems a bit far afield from reality to me.? Yes, there are lots > of folks with IPv6 connectivity and v4-only recursive DNS servers.? I > don't think ISPs will have problems setting aside a handful of IPv4 > addresses for authoritative DNS infrastructure to work around this > until v6 transport in recursive DNS servers is common enough. Assuming your ISP is providing your DNS.? What if I, as a new start-up in the IPv4-exhausted world, want to buy pure bit-pipes from my ISP, and be responsible for *everything* further up the stack?? I don't believe this is entirely uncommon. Regards, Tim. From isabeldias1 at yahoo.com Fri Apr 23 07:10:34 2010 From: isabeldias1 at yahoo.com (isabel dias) Date: Fri, 23 Apr 2010 05:10:34 -0700 (PDT) Subject: Connectivity to an IPv6-only site In-Reply-To: References: <17850162.101272022701294.JavaMail.root@jennyfur.pelican.org> Message-ID: <545336.82352.qm@web52607.mail.re2.yahoo.com> Godzilla vs. the Smog Monster ----- Original Message ---- From: Dave Hart To: Tim Franklin Cc: NANOG Sent: Fri, April 23, 2010 12:57:47 PM Subject: Re: Connectivity to an IPv6-only site On Fri, Apr 23, 2010 at 11:38 UTC, Tim Franklin wrote: > Assuming your ISP is providing your DNS. ?What if I, as a new start-up > in the IPv4-exhausted world, want to buy pure bit-pipes from my ISP, > and be responsible for *everything* further up the stack? ?I don't believe > this is entirely uncommon. Then you're going to either accept the hit to reachability, or you're going to use at least one third-party authoritative DNS service provider who can slave your zone over v6 and serve it over v4. puck.nether.net likely fits the bill and is free of charge. Cheers, Dave Hart From andy at nosignal.org Fri Apr 23 07:30:02 2010 From: andy at nosignal.org (Andy Davidson) Date: Fri, 23 Apr 2010 13:30:02 +0100 Subject: Connectivity to an IPv6-only site In-Reply-To: <4BD1432F.4070406@ibctech.ca> References: <4BD1432F.4070406@ibctech.ca> Message-ID: <5EC8E91C-141A-4BB4-82BC-D8E9AEA5A1DD@nosignal.org> On 23 Apr 2010, at 07:50, Steve Bertrand wrote: > http://onlyv6.com Its a shame there is not a pair of images on this site - one originated from a v4 only box, one a v6 only box. The img src= could point to the image with a query string that was an automatically incrementing counter. Then you could have demonstrated statistics about v4 only, v6 only, and dual stack visitors. Alas, it looks like a neat bit of research in any case, hope it helps some folk debug their v6 into a working state too. Andy From jared at puck.nether.net Fri Apr 23 07:42:41 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 23 Apr 2010 08:42:41 -0400 Subject: Connectivity to an IPv6-only site In-Reply-To: References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> Message-ID: <95E29521-7CCB-4142-9718-8A3F4F9D3621@puck.nether.net> On Apr 23, 2010, at 5:49 AM, Dave Hart wrote: > On Fri, Apr 23, 2010 at 08:26 UTC, Steve Bertrand wrote: >> - in WHOIS, I have ns1 and ns2.onlyv6.com listed as the authoritative >> name servers >> >> - both of these servers *only* have IPv6 addresses > > Which seems a bit far afield from reality to me. Yes, there are lots > of folks with IPv6 connectivity and v4-only recursive DNS servers. I > don't think ISPs will have problems setting aside a handful of IPv4 > addresses for authoritative DNS infrastructure to work around this > until v6 transport in recursive DNS servers is common enough. Not really, having your nameservers be IPv6 enabled is a reasonable thing to do. FYI: on comcast I see SERVFAIL, meaning their recursives do not have IPv6 transport. (I know we have that at my employer on our customer-facing recursives). ; <<>> DiG 9.6.0-APPLE-P2 <<>> any www.onlyv6.com. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54773 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.onlyv6.com. IN ANY ;; Query time: 1605 msec ;; SERVER: 68.87.72.130#53(68.87.72.130) ;; WHEN: Fri Apr 23 08:41:08 2010 ;; MSG SIZE rcvd: 32 From major at mhtx.net Fri Apr 23 07:49:26 2010 From: major at mhtx.net (Major Hayden) Date: Fri, 23 Apr 2010 07:49:26 -0500 Subject: Recommendations for DDOS detection software? Message-ID: <8E411935-7AE3-4BDD-8C5A-280DE4F3D079@mhtx.net> Hello there, Does anyone have any recommendations for DDOS detection software which runs on Linux? We're currently testing out Network Probe: http://objectplanet.com/probe/ We've written some custom "top talkers" scripts to analyze tcpdump data, but we'd like a more elegant solution with some basic alarm functionality. Thanks! -- Major Hayden From john at sackheads.org Fri Apr 23 07:51:15 2010 From: john at sackheads.org (John Payne) Date: Fri, 23 Apr 2010 08:51:15 -0400 Subject: Connectivity to an IPv6-only site In-Reply-To: <95E29521-7CCB-4142-9718-8A3F4F9D3621@puck.nether.net> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> <95E29521-7CCB-4142-9718-8A3F4F9D3621@puck.nether.net> Message-ID: <321E2AE7-A09B-4AD2-AF9D-D810B271ECF7@sackheads.org> On Apr 23, 2010, at 8:42 AM, Jared Mauch wrote: > > On Apr 23, 2010, at 5:49 AM, Dave Hart wrote: > >> On Fri, Apr 23, 2010 at 08:26 UTC, Steve Bertrand wrote: >>> - in WHOIS, I have ns1 and ns2.onlyv6.com listed as the authoritative >>> name servers >>> >>> - both of these servers *only* have IPv6 addresses >> >> Which seems a bit far afield from reality to me. Yes, there are lots >> of folks with IPv6 connectivity and v4-only recursive DNS servers. I >> don't think ISPs will have problems setting aside a handful of IPv4 >> addresses for authoritative DNS infrastructure to work around this >> until v6 transport in recursive DNS servers is common enough. > > Not really, having your nameservers be IPv6 enabled is a reasonable thing to do. But (particularly in an enterprise environment) less important than getting the end-user machines IPv6 enabled. At least I haven't been convinced otherwise yet... yes, it's reasonable, but at least in my situation it'll probably be after all user facing segments are done. Also, so far, all IPv6 content whitelisting has been done on the IPv4 address of nameservers... so really, no rush. > FYI: on comcast I see SERVFAIL, meaning their recursives do not have IPv6 transport. > > (I know we have that at my employer on our customer-facing recursives). > > ; <<>> DiG 9.6.0-APPLE-P2 <<>> any www.onlyv6.com. > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54773 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.onlyv6.com. IN ANY > > ;; Query time: 1605 msec > ;; SERVER: 68.87.72.130#53(68.87.72.130) > ;; WHEN: Fri Apr 23 08:41:08 2010 > ;; MSG SIZE rcvd: 32 > > > From matthias.flittner at de-cix.net Fri Apr 23 07:53:15 2010 From: matthias.flittner at de-cix.net (Matthias Flittner) Date: Fri, 23 Apr 2010 14:53:15 +0200 Subject: Recommendations for DDOS detection software? In-Reply-To: <8E411935-7AE3-4BDD-8C5A-280DE4F3D079@mhtx.net> References: <8E411935-7AE3-4BDD-8C5A-280DE4F3D079@mhtx.net> Message-ID: <4BD1983B.9090902@de-cix.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Major, You could do this easly with http://www.snort.org/ . regards, matthias -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL0Zg7AAoJEIZn8Rym6s4AzdIH/3nSNnk6yVpWsA8aCqqAWynH KeAC+OoIDlu7BSZXtTJvDfHnoXiTirrkwAe0nHp/GFIztRrzIwhyWD2pnnSio44P AWMFK1dfIPUBL/OpmxuA7HJ8M5Jxmc4yd0MiehffP3SZEwL7nSC4MYypysNiIOqT UYpFngfI3FKkoVDjWDqAZFZP4EUEiI8G+gLBkUelBnI5C4DRBrd0WIT4hZRHaUjH cNWGhZvCIEBJzXZCyJ9O7l07z8NRw0+tfiVFKPAVSTb6wUmN1sUnbWe9/vcbjEPK jjb176IL736gIje9Ev4/gssdfE6Png1P9z6HC+ue3nPMUw1wdxuHb7ewawJvm+o= =V0Se -----END PGP SIGNATURE----- From cluestore at gmail.com Fri Apr 23 08:17:56 2010 From: cluestore at gmail.com (Clue Store) Date: Fri, 23 Apr 2010 08:17:56 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD12E45.4060606@jsbc.cc> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <4BD04752.9050602@jsbc.cc> <4BD12E45.4060606@jsbc.cc> Message-ID: > But none of this does what NAT does for a big enterprise, which is > to *hide internal topology*. Yes, addressing the privacy concerns > that come from using lower-64-bits-derived-from-MAC-address is > required, but it is also necessary (for some organizations) to > make it impossible to tell that this host is on the same subnet as > that other host, as that would expose information like which host > you might want to attack in order to get access to the financial > or medical records, as well as whether or not the executive floor > is where these interesting website hits came from. > > Matthew Kaufman > Yeh that information leak is one reason I can think of for supporting > NAT for IPv6. One of the inherent security issues with unique > addresses I suppose. What makes you think that not using NAT exposes internal topology?? I have many cases where either filtering at layer-2 or NAT'ing a /48 for itself (or proxy-arp for those that do not have kits that can NAT IP blocks as itself) does NOT expose internal topology. Get your filtering correctly setup, and there is no use for NAT/PAT in v6. NAT was designed with one puropose in mind ..... extending the life of v4... period! The so called security that most think NAT gives them is a side effect. NAT/PAT also breaks several protocols (PASV FTP, H.323, etc) and I for one will be happy to see it go. I think it's a mistake to include NAT in v6 because there are other methodologies of accomplishing all of the side effects that everyone is use to seeing NAT provide without having to actually translate IP's or ports. I for one (as well as alot of other folks I know) am not/will not be using any kind of NAT moving forward. From jbates at brightok.net Fri Apr 23 08:17:32 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 23 Apr 2010 08:17:32 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD12DC0.6080004@matthew.at> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <4BD04752.9050602@jsbc.cc> <4BD12DC0.6080004@matthew.at> Message-ID: <4BD19DEC.1080805@brightok.net> Matthew Kaufman wrote: > But none of this does what NAT does for a big enterprise, which is to > *hide internal topology*. Yes, addressing the privacy concerns that come > from using lower-64-bits-derived-from-MAC-address is required, but it is > also necessary (for some organizations) to make it impossible to tell > that this host is on the same subnet as that other host, as that would > expose information like which host you might want to attack in order to > get access to the financial or medical records, as well as whether or > not the executive floor is where these interesting website hits came from. > Which is why some firewalls already support NAT for IPv6 in some form or fashion. These same firewalls will also usually have layer 7 proxy/filtering support as well. The concerns and breakage of a corporate network are extreme compared to non-corporate networks. Jack From jimb at jsbc.cc Fri Apr 23 08:19:34 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Fri, 23 Apr 2010 06:19:34 -0700 Subject: Connectivity to an IPv6-only site In-Reply-To: <95E29521-7CCB-4142-9718-8A3F4F9D3621@puck.nether.net> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> <95E29521-7CCB-4142-9718-8A3F4F9D3621@puck.nether.net> Message-ID: <4BD19E66.9050500@jsbc.cc> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/23/2010 05:42, Jared Mauch wrote: > > On Apr 23, 2010, at 5:49 AM, Dave Hart wrote: > >> On Fri, Apr 23, 2010 at 08:26 UTC, Steve Bertrand >> wrote: >>> - in WHOIS, I have ns1 and ns2.onlyv6.com listed as the >>> authoritative name servers >>> >>> - both of these servers *only* have IPv6 addresses >> >> Which seems a bit far afield from reality to me. Yes, there are >> lots of folks with IPv6 connectivity and v4-only recursive DNS >> servers. I don't think ISPs will have problems setting aside a >> handful of IPv4 addresses for authoritative DNS infrastructure to >> work around this until v6 transport in recursive DNS servers is >> common enough. > > Not really, having your nameservers be IPv6 enabled is a reasonable > thing to do. > > FYI: on comcast I see SERVFAIL, meaning their recursives do not > have IPv6 transport. > > (I know we have that at my employer on our customer-facing > recursives). > > ; <<>> DiG 9.6.0-APPLE-P2 <<>> any www.onlyv6.com. ;; global > options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: > SERVFAIL, id: 54773 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, > AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: ;www.onlyv6.com. IN ANY > > ;; Query time: 1605 msec ;; SERVER: 68.87.72.130#53(68.87.72.130) > ;; WHEN: Fri Apr 23 08:41:08 2010 ;; MSG SIZE rcvd: 32 > > You'll see a lot of this. I've done my own little tests on a few friends' systems, and on public wifi, etc, establishing some sort of IPv6 connectivity, and trying to resolve a subdomaiin of mine with a IPv6 only DNS server. Many ISP recursive NS don't have IPv6 transport yet, so they choke getting to my NS. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvRnmUACgkQ2fXFxl4S7sTfJwCfaKEB8juoXkHsgX7N+F+HNrEC PDwAoJm+Hn8NhBi6LKcX00T9JTEA35ma =nzM5 -----END PGP SIGNATURE----- From jbates at brightok.net Fri Apr 23 08:28:19 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 23 Apr 2010 08:28:19 -0500 Subject: Connectivity to an IPv6-only site In-Reply-To: References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD14EA9.7090709@cox.net> <4BD152F9.9000106@ibctech.ca> <629E4FD5-1E5B-499F-A221-68A4EFEB59CE@isoc.org> Message-ID: <4BD1A073.6090807@brightok.net> Mohacsi Janos wrote: > > > > On Fri, 23 Apr 2010, Matthew Ford wrote: > >> >> On 23 Apr 2010, at 09:00, Franck Martin wrote: >> >>> Go get an airport express, install it get your Internet then click >>> ipv6 enable box and that's it. Seriously! >>> >> >> Hmm. Then why did I just replace my airport and my ISP to get >> functioning IPv6? Hint: 6to4 != IPv6. > > even bridged mode broadband service != broadband service (i.e:airport > express 6to4 not working on PPPoE) > Bleh, actually it does, and I've never been happier to have not deployed PPPoE or cpe modems in router mode than dealing with IPv6. Yeah, some of the networks I manage but don't make decisions on have breaks for IPv6 (router based modems installed, dslams that are smart and filter bad customer traffic including IPv6, etc). My main vlan per customer layout (or atm per customer depending on equipment management domain) fully bridged to customer works great with IPv6, including my house where I have a linux box which does DHCPv6-PD and despite poor options at least passes out networks. Still having large issues on transit peers, but they'll fix it eventually, or I'll eventually get circuits to someone who does. Meanwhile, the tunnel works for the limited traffic generated by DNS, a few 6to4 people (generally p2p) and my home and office. Jack From owen at delong.com Fri Apr 23 08:27:00 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 23 Apr 2010 06:27:00 -0700 Subject: Connectivity to an IPv6-only site In-Reply-To: <4BD152F9.9000106@ibctech.ca> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD14EA9.7090709@cox.net> <4BD152F9.9000106@ibctech.ca> Message-ID: On Apr 23, 2010, at 12:57 AM, Steve Bertrand wrote: > On 2010.04.23 03:39, Larry Sheldon wrote: >> On 4/23/2010 02:35, Larry Sheldon wrote: >> >>>> From my PC at home (Cox in Omaha) I can't even get a nameserver that >>> knows the site. >> >> I should point out that I am really stupid about v6--I don't know if I >> should be able to find a nameserver or not. > > Has nothing to do about being stupid... let's rephrase your statement > and put a positive spin on it as such: > > "I've heard about IPv6, but don't know very much about it. I think that > I should know more, but am a bit confused as to where to begin. What do > I do first?". > > Then I'd say: > > "As a start, go to http://www.getipv6.info/index.php/Main_Page . If that > doesn't get you going, then let the rest of the community start posting > the resources that they know about, ranging from beginner up to the > advanced.". > Shameless plug: There's some decent IPv6 training at http://tunnelbroker.net You can also add IPv6 capabilities to your network using a tunnel from there. (Unless you're trapped in NAT hell). If you have the NAT problem, you can try http://www.sixxs.net and see if one of their solutions will get through your NAT. Owen (Full Disclosure, I work for the company (Hurricane Electric) that provides http://tunnelbroker.net ) From owen at delong.com Fri Apr 23 08:34:43 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 23 Apr 2010 06:34:43 -0700 Subject: Connectivity to an IPv6-only site In-Reply-To: References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> Message-ID: <538D27E2-4771-4420-821D-BA8879B6822A@delong.com> On Apr 23, 2010, at 2:49 AM, Dave Hart wrote: > On Fri, Apr 23, 2010 at 08:26 UTC, Steve Bertrand wrote: >> - in WHOIS, I have ns1 and ns2.onlyv6.com listed as the authoritative >> name servers >> >> - both of these servers *only* have IPv6 addresses > > Which seems a bit far afield from reality to me. Yes, there are lots > of folks with IPv6 connectivity and v4-only recursive DNS servers. I > don't think ISPs will have problems setting aside a handful of IPv4 > addresses for authoritative DNS infrastructure to work around this > until v6 transport in recursive DNS servers is common enough. > > Cheers, > Dave Hart It is likely a bit far from immediate future reality, but, i think it is a worth while exercise. Bottom line, if your ISP's resolvers cannot issue queries over IPv6, that is a problem that is relatively easy for them to solve. It is worth putting pressure on your ISP to solve that problem. Owen From jimb at jsbc.cc Fri Apr 23 08:40:13 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Fri, 23 Apr 2010 06:40:13 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <4BD04752.9050602@jsbc.cc> <4BD12E45.4060606@jsbc.cc> Message-ID: <4BD1A33D.60205@jsbc.cc> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/23/2010 06:17, Clue Store wrote: > > >> But none of this does what NAT does for a big enterprise, which >> is to *hide internal topology*. Yes, addressing the privacy >> concerns that come from using >> lower-64-bits-derived-from-MAC-address is required, but it is >> also necessary (for some organizations) to make it impossible to >> tell that this host is on the same subnet as that other host, as >> that would expose information like which host you might want to >> attack in order to get access to the financial or medical >> records, as well as whether or not the executive floor is where >> these interesting website hits came from. >> >> Matthew Kaufman > >> Yeh that information leak is one reason I can think of for >> supporting NAT for IPv6. One of the inherent security issues >> with unique addresses I suppose. > > > > What makes you think that not using NAT exposes internal > topology?? I have many cases where either filtering at layer-2 or > NAT'ing a /48 for itself (or proxy-arp for those that do not have > kits that can NAT IP blocks as itself) does NOT expose internal > topology. Get your filtering correctly setup, and there is no use > for NAT/PAT in v6. > > NAT was designed with one puropose in mind ..... extending the > life of v4... period! The so called security that most think NAT > gives them is a side effect. NAT/PAT also breaks several protocols > (PASV FTP, H.323, etc) and I for one will be happy to see it go. I > think it's a mistake to include NAT in v6 because there are other > methodologies of accomplishing all of the side effects that > everyone is use to seeing NAT provide without having to actually > translate IP's or ports. > > I for one (as well as alot of other folks I know) am not/will not > be using any kind of NAT moving forward. > > I'm not really advocating NAT for v6. I'm just saying it's one valid security issue with using any sort of globally unique IP address (v4 or v6), in that analyzing a bunch of traffic from a particular netblock would allow one to build a topology map. It's easier with IPv6 since you can presume most if not all addresses are on /64s out of a /48 (so look to the fourth quad for the "subnet ID"). Obviously if someone is super concerned with revealing this sort of info there are other things besides NAT they can do, such as using a proxy server(s) for various internet applications, transparent proxies, etc. But it is a valid security concern for some. Also, is that your real name? ;-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvRozwACgkQ2fXFxl4S7sSACQCfeRfk5VmKjkW2SYkn/gZl53Ng Q0cAoKsQTGdTTBaEg1paE44yTNVy2OSQ =WAPA -----END PGP SIGNATURE----- From cluestore at gmail.com Fri Apr 23 08:54:58 2010 From: cluestore at gmail.com (Clue Store) Date: Fri, 23 Apr 2010 08:54:58 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD1A33D.60205@jsbc.cc> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <4BD04752.9050602@jsbc.cc> <4BD12E45.4060606@jsbc.cc> <4BD1A33D.60205@jsbc.cc> Message-ID: > > > > > I'm just saying it's one valid > > security issue with using any sort of globally unique IP address (v4 > > or v6), in that analyzing a bunch of traffic from a particular > > netblock would allow one to build a topology map. It's easier with > > IPv6 since you can presume most if not all addresses are on /64s out > > of a /48 (so look to the fourth quad for the "subnet ID"). > > I understand and totally agree. > > Obviously if someone is super concerned with revealing this sort of > > info there are other things besides NAT they can do, such as using a > > proxy server(s) for various internet applications, transparent > > proxies, etc. But it is a valid security concern for some. > > Could not agree more which is why I stated that there are other ways of > accomplishing the "hiding internal topology" using other methodoligies. > NAT/PAT has caused me many headaches which is why I am so opposed to using > it. > > Also, is that your real name? ;-) > No, but this list is great for buying and selling clue. In today's market, clue is equivalent to gold. :) From owen at delong.com Fri Apr 23 08:54:47 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 23 Apr 2010 06:54:47 -0700 Subject: Connectivity to an IPv6-only site In-Reply-To: <5EC8E91C-141A-4BB4-82BC-D8E9AEA5A1DD@nosignal.org> References: <4BD1432F.4070406@ibctech.ca> <5EC8E91C-141A-4BB4-82BC-D8E9AEA5A1DD@nosignal.org> Message-ID: On Apr 23, 2010, at 5:30 AM, Andy Davidson wrote: > > On 23 Apr 2010, at 07:50, Steve Bertrand wrote: > >> http://onlyv6.com > > Its a shame there is not a pair of images on this site - one originated from a v4 only box, one a v6 only box. The img src= could point to the image with a query string that was an automatically incrementing counter. Then you could have demonstrated statistics about v4 only, v6 only, and dual stack visitors. Alas, it looks like a neat bit of research in any case, hope it helps some folk debug their v6 into a working state too. > > Andy There are already sites conducting that experiment. This site is conducting a different experiment. Owen From Valdis.Kletnieks at vt.edu Fri Apr 23 09:07:15 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 23 Apr 2010 10:07:15 -0400 Subject: Connectivity to an IPv6-only site In-Reply-To: Your message of "Fri, 23 Apr 2010 06:34:43 PDT." <538D27E2-4771-4420-821D-BA8879B6822A@delong.com> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> <538D27E2-4771-4420-821D-BA8879B6822A@delong.com> Message-ID: <5598.1272031635@localhost> On Fri, 23 Apr 2010 06:34:43 PDT, Owen DeLong said: > Bottom line, if your ISP's resolvers cannot issue queries over IPv6, > that is a problem that is relatively easy for them to solve. It is worth > putting pressure on your ISP to solve that problem. Ours are currently intentionally configured to not issue queries over IPv6, because at one time, there were *so many* sites that listed unreachable quad-A NS records. Our DNS guy is more than willing to revisit that config switch. Anybody have some statistics on what the current situation is? -------------- 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 phaze.org Fri Apr 23 09:09:49 2010 From: nanog at phaze.org (Greg Estabrooks) Date: Fri, 23 Apr 2010 11:09:49 -0300 Subject: Hotmail bouncing email Message-ID: <4BD1AA2D.5020505@phaze.org> Is anyone else out there getting reports of hotmail randomly bouncing emails with just a message of "failed"? Over the last 2 weeks we've had a dozens of complaints of hosting customers spanning dozens of domains not receiving emails from hotmail users. Checking our logs shows the messages were never even attempted to be delivered and all forwarded in bounce messages literally just say "Delivery failed", yet we are still happily processing thousands of other emails from hotmail everyday. Now I'm wondering if this is restricted to us in someway or part of a larger problem. From owen at delong.com Fri Apr 23 09:04:49 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 23 Apr 2010 07:04:49 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD19DEC.1080805@brightok.net> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <4BD04752.9050602@jsbc.cc> <4BD12DC0.6080004@matthew.at> <4BD19DEC.1080805@brightok.net> Message-ID: On Apr 23, 2010, at 6:17 AM, Jack Bates wrote: > Matthew Kaufman wrote: >> But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from. > > Which is why some firewalls already support NAT for IPv6 in some form or fashion. These same firewalls will also usually have layer 7 proxy/filtering support as well. The concerns and breakage of a corporate network are extreme compared to non-corporate networks. > > > Jack That is sad news, indeed. Hopefully it won't lead to NAT-T becoming a common part of software as the ISVs catch on to IPv6. Owen From LarrySheldon at cox.net Fri Apr 23 09:37:50 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 23 Apr 2010 09:37:50 -0500 Subject: Connectivity to an IPv6-only site In-Reply-To: <4BD152F9.9000106@ibctech.ca> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD14EA9.7090709@cox.net> <4BD152F9.9000106@ibctech.ca> Message-ID: <4BD1B0BE.6030800@cox.net> On 4/23/2010 02:57, Steve Bertrand wrote: > On 2010.04.23 03:39, Larry Sheldon wrote: >> On 4/23/2010 02:35, Larry Sheldon wrote: >> >>> >From my PC at home (Cox in Omaha) I can't even get a nameserver that >>> knows the site. >> >> I should point out that I am really stupid about v6--I don't know if I >> should be able to find a nameserver or not. > > Has nothing to do about being stupid... let's rephrase your statement > and put a positive spin on it as such: > > "I've heard about IPv6, but don't know very much about it. I think that > I should know more, but am a bit confused as to where to begin. What do > I do first?". You are too kind. Since I no longer administer a network, I've gotten lazy about keeping up with developments. And that is stupid. > Then I'd say: > > "As a start, go to http://www.getipv6.info/index.php/Main_Page . If that > doesn't get you going, then let the rest of the community start posting > the resources that they know about, ranging from beginner up to the > advanced.". Good and useful advice. But the message I meant to convey at 0300 in a rainy morning when I couldn't sleep was "I don't know if a Windows XP (SP3, current patches) on a Cox Cable connection _should_ be able to connect, but my machine reported that it couldn't even *find* a name-server for the site." -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Fri Apr 23 09:43:29 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 23 Apr 2010 09:43:29 -0500 Subject: Connectivity to an IPv6-only site In-Reply-To: References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD14EA9.7090709@cox.net> <4BD152F9.9000106@ibctech.ca> Message-ID: <4BD1B211.7050103@cox.net> On 4/23/2010 03:00, Franck Martin wrote: > Go get an airport express, install it get your Internet then click > ipv6 enable box and that's it. Seriously! OK--I'll but that on the shopping list. (I'll also look around for something for the wired machinery as well. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From tme at americafree.tv Fri Apr 23 09:47:33 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 23 Apr 2010 10:47:33 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <4BD04752.9050602@jsbc.cc> <4BD12E45.4060606@jsbc.cc> Message-ID: On Apr 23, 2010, at 9:17 AM, Clue Store wrote: >> But none of this does what NAT does for a big enterprise, which is >> to *hide internal topology*. Yes, addressing the privacy concerns >> that come from using lower-64-bits-derived-from-MAC-address is >> required, but it is also necessary (for some organizations) to >> make it impossible to tell that this host is on the same subnet as >> that other host, as that would expose information like which host >> you might want to attack in order to get access to the financial >> or medical records, as well as whether or not the executive floor >> is where these interesting website hits came from. >> >> Matthew Kaufman > >> Yeh that information leak is one reason I can think of for supporting >> NAT for IPv6. One of the inherent security issues with unique >> addresses I suppose. > > > What makes you think that not using NAT exposes internal topology?? Or that internal topology cannot leak out through NAT's ? I have seen NATed enterprises become massively compromised. Regards Marshall > I have > many cases where either filtering at layer-2 or NAT'ing a /48 for > itself (or > proxy-arp for those that do not have kits that can NAT IP blocks as > itself) > does NOT expose internal topology. Get your filtering correctly > setup, and > there is no use for NAT/PAT in v6. > > NAT was designed with one puropose in mind ..... extending the life > of v4... > period! The so called security that most think NAT gives them is a > side > effect. NAT/PAT also breaks several protocols (PASV FTP, H.323, etc) > and I > for one will be happy to see it go. I think it's a mistake to > include NAT in > v6 because there are other methodologies of accomplishing all of the > side > effects that everyone is use to seeing NAT provide without having to > actually translate IP's or ports. > > I for one (as well as alot of other folks I know) am not/will not be > using > any kind of NAT moving forward. > > > From LarrySheldon at cox.net Fri Apr 23 09:57:05 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 23 Apr 2010 09:57:05 -0500 Subject: Connectivity to an IPv6-only site In-Reply-To: <4BD159C1.2090307@ibctech.ca> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> Message-ID: <4BD1B541.2000807@cox.net> On 4/23/2010 03:26, Steve Bertrand wrote: > On 2010.04.23 03:35, Larry Sheldon wrote: > >> >From my PC at home (Cox in Omaha) I can't even get a nameserver that >> knows the site. > > Larry... let me explain why. Although you might not understand, others > will, and you may remember this as something when you do use IPv6. > > Believe me, nobody can remember everything, and what I'm trying to > achieve here is isolating easy-to-document issues. > > It may be above your head at this time, but my objective is to find out > the rough edges, that net ops will be able to identify quickly when > problems arise... much like looking for reckless filtering of ICMP on an > IPv6 network. It actually all makes sense (not to be confused with "I have a deep and abiding understanding now"). > > Why you can't get a name server... because this is how the domain is > configured: I started to whine about the "misleading" error message I go, but when I did it again to copy it I see that it was a mix of not-understanding and of thinking I did: > Microsoft Windows XP [Version 5.1.2600] > (C) Copyright 1985-2001 Microsoft Corp. > > C:\Documents and Settings\Owner>tracert onlyv6.com > Unable to resolve target system name onlyv6.com. > > C:\Documents and Settings\Owner> That doesn't say "Unable to locate a nameserver" which I would have bet it said. I'll go away quietly now. Thanks for the explanation. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Fri Apr 23 10:05:21 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 23 Apr 2010 10:05:21 -0500 Subject: Connectivity to an IPv6-only site In-Reply-To: References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> Message-ID: <4BD1B731.8050705@cox.net> On 4/23/2010 04:49, Dave Hart wrote: > On Fri, Apr 23, 2010 at 08:26 UTC, Steve Bertrand wrote: >> - in WHOIS, I have ns1 and ns2.onlyv6.com listed as the authoritative >> name servers >> >> - both of these servers *only* have IPv6 addresses > > Which seems a bit far afield from reality to me. Yes, there are lots > of folks with IPv6 connectivity and v4-only recursive DNS servers. I > don't think ISPs will have problems setting aside a handful of IPv4 > addresses for authoritative DNS infrastructure to work around this > until v6 transport in recursive DNS servers is common enough. Wuulllll, wait a minute. I didn't get the notion that he was testing to see if a real-world configuration would work. Most engineering and science projects don't test the real world (less so now than in times past, and I don't mean global warming). It looks like he has designed an experiment to test a narrow range of conditions that look to be useful for piecing together what the larger (and largely un-testable) picture might look like. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From owen at delong.com Fri Apr 23 10:14:03 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 23 Apr 2010 08:14:03 -0700 Subject: Connectivity to an IPv6-only site In-Reply-To: <4BD1B211.7050103@cox.net> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD14EA9.7090709@cox.net> <4BD152F9.9000106@ibctech.ca> <4BD1B211.7050103@cox.net> Message-ID: <60F7471B-D928-445A-935B-F28411C8D7BF@delong.com> On Apr 23, 2010, at 7:43 AM, Larry Sheldon wrote: > On 4/23/2010 03:00, Franck Martin wrote: >> Go get an airport express, install it get your Internet then click >> ipv6 enable box and that's it. Seriously! > > OK--I'll but that on the shopping list. (I'll also look around for > something for the wired machinery as well. > In that case, get an Airport Extreme or Time Capsule. Owen From chris at uplogon.com Fri Apr 23 10:16:59 2010 From: chris at uplogon.com (Chris Gotstein) Date: Fri, 23 Apr 2010 10:16:59 -0500 Subject: Hotmail bouncing email In-Reply-To: <4BD1AA2D.5020505@phaze.org> References: <4BD1AA2D.5020505@phaze.org> Message-ID: <4BD1B9EB.1040609@uplogon.com> We had a customer of ours call and ask the same thing this week. They run their own Exchange server, and they were getting delivery failed or delayed to Hotmail account. Issues started on Monday and I as far as i know, the issue went away yesterday. ---- ---- ---- ---- Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP http://uplogon.com | +1 906 774 4847 | chris at uplogon.com On 4/23/2010 9:09 AM, Greg Estabrooks wrote: > > > Is anyone else out there getting reports of hotmail randomly bouncing > emails with just a message of "failed"? > > Over the last 2 weeks we've had a dozens of complaints of hosting > customers spanning dozens of domains not receiving emails from hotmail > users. Checking our logs shows the messages were never even attempted > to be delivered and all forwarded in bounce messages literally just say > "Delivery failed", yet we are still happily processing thousands of > other emails from hotmail everyday. > > Now I'm wondering if this is restricted to us in someway or part of a > larger problem. > > > From jgreco at ns.sol.net Fri Apr 23 10:28:52 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 23 Apr 2010 10:28:52 -0500 (CDT) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: from "Marshall Eubanks" at Apr 23, 2010 10:47:33 AM Message-ID: <201004231528.o3NFSqSs062819@aurora.sol.net> > > What makes you think that not using NAT exposes internal topology?? > > Or that internal topology cannot leak out through NAT's ? I have seen > NATed enterprises > become massively compromised. NAT allows people to become far too lazy. Your typical NAT allows connections outbound, typically configured without any audit trail, etc., so once a bad guy is inside the "secure NAT firewall," they're free to connect out to the 'net. In comparison, an actual real firewall can prohibit {most, all} outbound access and force the use of proxies. Proxies can provide logging, content scanning, etc., services. Many times, those who argue in favor of NAT as a "firewall" are the same ones who seem to actually be relying on the NAT as inbound protection, but who aren't really doing anything to control their outbound traffic, or IDS, etc. ... 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 pete at altadena.net Fri Apr 23 10:33:06 2010 From: pete at altadena.net (Pete Carah) Date: Fri, 23 Apr 2010 11:33:06 -0400 Subject: Connectivity to an IPv6-only site In-Reply-To: <4BD152F9.9000106@ibctech.ca> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD14EA9.7090709@cox.net> <4BD152F9.9000106@ibctech.ca> Message-ID: <4BD1BDB2.8060301@altadena.net> ... > Has nothing to do about being stupid... let's rephrase your statement > and put a positive spin on it as such: > > "I've heard about IPv6, but don't know very much about it. I think that > I should know more, but am a bit confused as to where to begin. What do > I do first?". > > Then I'd say: > > "As a start, go to http://www.getipv6.info/index.php/Main_Page . If that > doesn't get you going, then let the rest of the community start posting > the resources that they know about, ranging from beginner up to the > advanced.". > > I'd like to add that I learned a LOT going through HE's "certification" process, using it (as apparently intended) as a tutorial. -- Pete > Steve > > > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Apr 23 11:15:52 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 24 Apr 2010 01:45:52 +0930 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> Message-ID: <20100424014552.5fd13102@opy.nosense.org> On Thu, 22 Apr 2010 07:18:18 -0400 William Herrin wrote: > On Wed, Apr 21, 2010 at 11:31 PM, Owen DeLong wrote: > > On Apr 21, 2010, at 3:26 PM, Roger Marquis wrote: > >> William Herrin wrote: > >>>> Not to take issue with either statement in particular, but I think there > >>>> needs to be some consideration of what "fail" means. > >>> > >>> Fail means that an inexperienced admin drops a router in place of the > >>> firewall to work around a priority problem while the senior engineer > >>> is on vacation. With NAT protecting unroutable addresses, that failure > >>> mode fails closed. > >> > >> In addition to fail-closed NAT also means: > >> > >> ?* search engines and and connectivity providers cannot (easily) > >> ?differentiate and/or monitor your internal hosts, and > >> > > Right, because nobody has figured out Javascript and Cookies. > > Having worked for comScore, I can tell you that having a fixed address > in the lower 64 bits would make their jobs oh so much easier. Cookies > and javascript are of very limited utility. > > On the other hand, I could swear I've seen a draft where the PC picks > up random unused addresses in the lower 64 for each new outbound > connection for anonymity purposes. Even if there is no such draft, it > wouldn't exactly be hard to implement. It won't take NAT to anonymize > the PCs on a LAN with IPv6. > Might be this - "Transient addressing for related processes: Improved firewalling by using IPv6 and multiple addresses per host." by Peter M. Gleitz and Steven M. Bellovin (i.e. the Steven Bellovin who shows up on this list quite often) http://www.cs.columbia.edu/~smb/papers/tarp.pdf > > >> ?* multiple routes do not have to be announced or otherwise accommodated > >> ?by internal re-addressing. > > > > I fail to see how NAT even affects this in a properly structured network. > > That's your failure, not Roger's. As delivered, IPv6 is capable of > dynamically assigning addresses from multiple subnets to a PC, but > that's where the support for multiple-PA multihoming stops. PCs don't > do so well at using more than one of those addresses at a time for > outbound connections. As a number of vendors have done with IPv4, an > IPv6 NAT box at the network border can spread outbound connections > between multiply addressed upstream links. > > > On Thu, Apr 22, 2010 at 2:10 AM, Franck Martin wrote: > > http://www.ipinc.net/IPv4.GIF > > The energy that people are willing to spend to fix it (NAT, LSN), > > rather than bite the bullet is amazing. > > A friend of mine drives a 1976 Cadillac El Dorado. I asked him why > once. He explained that even at 8 miles to the gallon and even after > having to find 1970's parts for it, he can't get anything close to as > luxurious a car from the more modern offerings at anything close to > the comparatively small amount of money he spends. > > The thing has plush leather seats that feel like sinking in to a comfy > couch and an engine with more horsepower than my mustang gt. It isn't > hard to see his point. > > Regards, > Bill Herrin > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Apr 23 11:18:43 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 24 Apr 2010 01:48:43 +0930 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD06A77.3080401@cox.net> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <20100422143403.GB8526@vacation.karoshi.com.> <006901cae22d$2b1ce4c0$8156ae40$@gmail.com> <483E6B0272B0284BA86D7596C40D29F9E2BEEC6D62@PUR-EXCH07.ox.com> <4BD06A77.3080401@cox.net> Message-ID: <20100424014843.20f6c096@opy.nosense.org> On Thu, 22 Apr 2010 10:25:43 -0500 Larry Sheldon wrote: > On 4/22/2010 10:17, Charles Mills wrote: > > I think he was actually quoting the movie. They always called Harvey > > Korman's character "Hedy" and he'd always correct them with "That's > > Hedley" in a most disapproving tone. > > Oh. > > The only thing I watch less-of than TV is movies. > > Say....did they ever make a sequel to "Crocodile Dundee"? > -- Yep. Every Australian has probably seen that too. http://www.imdb.com/title/tt0092493/ (you have no idea how big our butter knives are these days, all because of that movie) > Somebody should have said: > A democracy is two wolves and a lamb voting on what to have for dinner. > > Freedom under a constitutional republic is a well armed lamb contesting > the vote. > > Requiescas in pace o email > Ex turpi causa non oritur actio > Eppure si rinfresca > > ICBM Targeting Information: http://tinyurl.com/4sqczs > http://tinyurl.com/7tp8ml > > > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Apr 23 11:11:28 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 24 Apr 2010 01:41:28 +0930 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <21703879.1086.1271916609912.JavaMail.franck@franck-martins-macbook-pro.local> References: <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <21703879.1086.1271916609912.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <20100424014128.0aae0009@opy.nosense.org> On Thu, 22 Apr 2010 18:10:10 +1200 (MAGST) Franck Martin wrote: > The whole thread made me thought about this: > > http://www.ipinc.net/IPv4.GIF > > The energy that people are willing to spend to fix it (NAT, LSN), rather than bite the bullet is amazing. > Probably and sadly, they don't remember the Internet before NAT. I think Brantley Colie has somewhat redeemed himself by inventing ATA over Ethernet. http://www.coraid.com/COMPANY/Management Also, sadly, even though I'm an strong IPv6 advocate, I think a period of LSN/GCN is inevitable. There's now not enough time to properly convert from IPv4 to IPv6, and, also sadly, Jon Postel isn't around anymore to make subtle and veiled threats of loss of connectivity .. (http://www.rfc-editor.org/in-notes/museum/tcp-ip-digest/tcp-ip-digest.v1n6.1) ------------------------------ From: POSTEL at USC-ISIF Subject: Disabling NCPs There has been some talk of "forcing" the move to TCP by various administrative and policy measures. There was also a claim that there was no technical way to force the abandonment of NCP. It should be pointed out that a quite simple modification to the IMP program would enable the IMPs to filter out and discard all NCP traffic. As far as i know, there has been no decision to do this, but you should be aware that it is technical feasible. --jon. ------------------------------ From marka at isc.org Fri Apr 23 11:45:05 2010 From: marka at isc.org (Mark Andrews) Date: Sat, 24 Apr 2010 02:45:05 +1000 Subject: Connectivity to an IPv6-only site In-Reply-To: Your message of "Fri, 23 Apr 2010 10:07:15 -0400." <5598.1272031635@localhost> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> <538D27E2-4771-4420-821D-BA8879B6822A@delong.com> <5598.1272031635@localhost> Message-ID: <201004231645.o3NGj5e5066388@drugs.dv.isc.org> In message <5598.1272031635 at localhost>, Valdis.Kletnieks at vt.edu writes: > On Fri, 23 Apr 2010 06:34:43 PDT, Owen DeLong said: > > > Bottom line, if your ISP's resolvers cannot issue queries over IPv6, > > that is a problem that is relatively easy for them to solve. It is worth > > putting pressure on your ISP to solve that problem. > > Ours are currently intentionally configured to not issue queries over IPv6, > because at one time, there were *so many* sites that listed unreachable quad- > A > NS records. Our DNS guy is more than willing to revisit that config switch. > > Anybody have some statistics on what the current situation is? Given I've been running dual stack nameservers for the last 7 years and never noticed any real problems I expect his problems are actually closer to home. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bruns at 2mbit.com Fri Apr 23 11:46:07 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 23 Apr 2010 10:46:07 -0600 Subject: Connectivity to an IPv6-only site In-Reply-To: References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> Message-ID: <4BD1CECF.3090708@2mbit.com> On 4/23/10 3:49 AM, Dave Hart wrote: > On Fri, Apr 23, 2010 at 08:26 UTC, Steve Bertrand wrote: >> - in WHOIS, I have ns1 and ns2.onlyv6.com listed as the authoritative >> name servers >> >> - both of these servers *only* have IPv6 addresses > > Which seems a bit far afield from reality to me. Yes, there are lots > of folks with IPv6 connectivity and v4-only recursive DNS servers. I > don't think ISPs will have problems setting aside a handful of IPv4 > addresses for authoritative DNS infrastructure to work around this > until v6 transport in recursive DNS servers is common enough. > Dave, I think part of the point of this is to discover gotchas with our current infrastructure. For example, while diagnosing why I couldn't get onlyv6.com to resolve on one of my name servers but the others worked fine, I discovered that PowerDNS Recursor won't use an IPv6 address for outgoing queries unless you actually give it: query-local-address6= One of my name servers had it, the other didn't, hence I was getting failures on one and success on the other. Its little config issues like that that can crop up weeks/months/years later and make life difficult. Now that I'm a Xen shop, I design domUs to last years at a time rather then rebuilding them constantly. Being able to shunt stable and reliable domU hosts to new dom0 machines when they come up is a great thing, and makes my life alot easier. :) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jared at puck.nether.net Fri Apr 23 11:47:05 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 23 Apr 2010 12:47:05 -0400 Subject: Connectivity to an IPv6-only site In-Reply-To: <201004231645.o3NGj5e5066388@drugs.dv.isc.org> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> <538D27E2-4771-4420-821D-BA8879B6822A@delong.com> <5598.1272031635@localhost> <201004231645.o3NGj5e5066388@drugs.dv.isc.org> Message-ID: <290C34F3-C05C-40D1-88D5-3852B69784E3@puck.nether.net> On Apr 23, 2010, at 12:45 PM, Mark Andrews wrote: > Given I've been running dual stack nameservers for the last 7 years > and never noticed any real problems I expect his problems are actually > closer to home. > > Mark I mirror this experience, I've not seen any issues having the nameservers dual-stacked. - Jared From bruns at 2mbit.com Fri Apr 23 11:56:44 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 23 Apr 2010 10:56:44 -0600 Subject: Connectivity to an IPv6-only site In-Reply-To: <290C34F3-C05C-40D1-88D5-3852B69784E3@puck.nether.net> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> <538D27E2-4771-4420-821D-BA8879B6822A@delong.com> <5598.1272031635@localhost> <201004231645.o3NGj5e5066388@drugs.dv.isc.org> <290C34F3-C05C-40D1-88D5-3852B69784E3@puck.nether.net> Message-ID: <4BD1D14C.1090703@2mbit.com> On 4/23/10 10:47 AM, Jared Mauch wrote: > > On Apr 23, 2010, at 12:45 PM, Mark Andrews wrote: > >> Given I've been running dual stack nameservers for the last 7 years >> and never noticed any real problems I expect his problems are actually >> closer to home. >> >> Mark > > I mirror this experience, I've not seen any issues having the nameservers dual-stacked. > > - Jared Don't quite remember when I started going dual stack on the server side of things, I think it was back in 2006 or 2007. I even have AHBL queries coming in over IPv6 now - of course they are for IPv4 hosts, but thats not the point. :-) Whats even more interesting, is that on my primary name server, people are sending ICMP echos to my IPv6 address on a fairly consistent basis, making me wonder if someone's using it for testing purposes. If so, makes me happy :) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From Valdis.Kletnieks at vt.edu Fri Apr 23 12:08:30 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 23 Apr 2010 13:08:30 -0400 Subject: Connectivity to an IPv6-only site In-Reply-To: Your message of "Sat, 24 Apr 2010 02:45:05 +1000." <201004231645.o3NGj5e5066388@drugs.dv.isc.org> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> <538D27E2-4771-4420-821D-BA8879B6822A@delong.com> <5598.1272031635@localhost> <201004231645.o3NGj5e5066388@drugs.dv.isc.org> Message-ID: <14793.1272042510@localhost> On Sat, 24 Apr 2010 02:45:05 +1000, Mark Andrews said: > Given I've been running dual stack nameservers for the last 7 years > and never noticed any real problems I expect his problems are actually > closer to home. No, the problems are probably further back in time. We first started turning up IPv6 back in 1997 or so. There's a *very* good chance that we turned it off a decade ago (or whenever people *first* started listing quad-A's in NS entries) due to breakage and never actually revisited it since then. This would have been in the era of early 6bone and "your IPv6 connection is probably tromboned through Tokyo". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From matthew at matthew.at Fri Apr 23 12:16:10 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 23 Apr 2010 10:16:10 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD19DEC.1080805@brightok.net> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <4BD04752.9050602@jsbc.cc> <4BD12DC0.6080004@matthew.at> <4BD19DEC.1080805@brightok.net> Message-ID: <4BD1D5DA.80202@matthew.at> Jack Bates wrote: > Matthew Kaufman wrote: >> But none of this does what NAT does for a big enterprise, which is to >> *hide internal topology*. Yes, addressing the privacy concerns that >> come from using lower-64-bits-derived-from-MAC-address is required, >> but it is also necessary (for some organizations) to make it >> impossible to tell that this host is on the same subnet as that other >> host, as that would expose information like which host you might want >> to attack in order to get access to the financial or medical records, >> as well as whether or not the executive floor is where these >> interesting website hits came from. >> > > Which is why some firewalls already support NAT for IPv6 in some form > or fashion. These same firewalls will also usually have layer 7 > proxy/filtering support as well. The concerns and breakage of a > corporate network are extreme compared to non-corporate networks. Agreed on the last point. And I'm following up mostly because I've received quite a few private messages that resulted from folks interpreting "hide internal topology" as "block access to internal topology" (which can be done with filters). What I mean when I say "hide internal topology" is that a passive observer on the outside, looking at something like web server access logs, cannot tell how many subnets are inside the corporation or which accesses come from which subnets. (And preferably, cannot tell whether or not two different accesses came from the same host or different hosts simply by examining the IP addresses... but yes, application-level cooperation -- in the form of a browser which keeps cookies, as an example -- can again expose that type of information) Matthew Kaufman From matthew at matthew.at Fri Apr 23 12:34:18 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 23 Apr 2010 10:34:18 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD1D5DA.80202@matthew.at> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <4BD04752.9050602@jsbc.cc> <4BD12DC0.6080004@matthew.at> <4BD19DEC.1080805@brightok.net> <4BD1D5DA.80202@matthew.at> Message-ID: <4BD1DA1A.8080203@matthew.at> Matthew Kaufman wrote: > Jack Bates wrote: >> Matthew Kaufman wrote: >>> But none of this does what NAT does for a big enterprise, which is >>> to *hide internal topology*. Yes, addressing the privacy concerns >>> that come from using lower-64-bits-derived-from-MAC-address is >>> required, but it is also necessary (for some organizations) to make >>> it impossible to tell that this host is on the same subnet as that >>> other host, as that would expose information like which host you >>> might want to attack in order to get access to the financial or >>> medical records, as well as whether or not the executive floor is >>> where these interesting website hits came from. >>> >> >> Which is why some firewalls already support NAT for IPv6 in some form >> or fashion. These same firewalls will also usually have layer 7 >> proxy/filtering support as well. The concerns and breakage of a >> corporate network are extreme compared to non-corporate networks. > Agreed on the last point. And I'm following up mostly because I've > received quite a few private messages that resulted from folks > interpreting "hide internal topology" as "block access to internal > topology" (which can be done with filters). What I mean when I say > "hide internal topology" is that a passive observer on the outside, > looking at something like web server access logs, cannot tell how many > subnets are inside the corporation or which accesses come from which > subnets. (And preferably, cannot tell whether or not two different > accesses came from the same host or different hosts simply by > examining the IP addresses... but yes, application-level cooperation > -- in the form of a browser which keeps cookies, as an example -- can > again expose that type of information) > And to further clarify, I don't think "hide internal topology" is actually something that needs to happen (and can show several ways in which it can be completely violated, including using the browser and/or browser plugins to extract the internal addresses and send them to a server somewhere which can map it all out). But it *is* present as a mandatory checklist item on at least one HIPPA and two SOX audit checklists I've seen,.. and IT departments in major corporations care much more these days about getting a clean SOX audit than they do about providing connectivity... and given how each affects the stock price, that's not surprising. Matthew Kaufman From sethm at rollernet.us Fri Apr 23 12:50:28 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 23 Apr 2010 10:50:28 -0700 Subject: Hotmail bouncing email In-Reply-To: <4BD1AA2D.5020505@phaze.org> References: <4BD1AA2D.5020505@phaze.org> Message-ID: <4BD1DDE4.1070505@rollernet.us> On 4/23/10 7:09 AM, Greg Estabrooks wrote: > > > Is anyone else out there getting reports of hotmail randomly bouncing > emails with just a message of "failed"? > > Over the last 2 weeks we've had a dozens of complaints of hosting > customers spanning dozens of domains not receiving emails from hotmail > users. Checking our logs shows the messages were never even attempted > to be delivered and all forwarded in bounce messages literally just say > "Delivery failed", yet we are still happily processing thousands of > other emails from hotmail everyday. > > Now I'm wondering if this is restricted to us in someway or part of a > larger problem. > I've had hotmail complaints lately too, except when I checked my logs the "error" has a 250 response. ~Seth From cscora at apnic.net Fri Apr 23 13:10:24 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 24 Apr 2010 04:10:24 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201004231810.o3NIAOl8030154@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. 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 24 Apr, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 319297 Prefixes after maximum aggregation: 147421 Deaggregation factor: 2.17 Unique aggregates announced to Internet: 154986 Total ASes present in the Internet Routing Table: 33849 Prefixes per ASN: 9.43 Origin-only ASes present in the Internet Routing Table: 29368 Origin ASes announcing only one prefix: 14321 Transit ASes present in the Internet Routing Table: 4481 Transit-only ASes present in the Internet Routing Table: 107 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (32374) 19 Prefixes from unregistered ASNs in the Routing Table: 551 Unregistered ASNs in the Routing Table: 130 Number of 32-bit ASNs allocated by the RIRs: 530 Prefixes from 32-bit ASNs in the Routing Table: 593 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 207 Number of addresses announced to Internet: 2232801984 Equivalent to 133 /8s, 21 /16s and 218 /24s Percentage of available address space announced: 60.2 Percentage of allocated address space announced: 66.2 Percentage of available address space allocated: 90.9 Percentage of address space in use by end-sites: 82.4 Total number of prefixes smaller than registry allocations: 153040 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 76246 Total APNIC prefixes after maximum aggregation: 26542 APNIC Deaggregation factor: 2.87 Prefixes being announced from the APNIC address blocks: 73091 Unique aggregates announced from the APNIC address blocks: 32073 APNIC Region origin ASes present in the Internet Routing Table: 4002 APNIC Prefixes per ASN: 18.26 APNIC Region origin ASes announcing only one prefix: 1098 APNIC Region transit ASes present in the Internet Routing Table: 629 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 510246208 Equivalent to 30 /8s, 105 /16s and 189 /24s Percentage of available APNIC address space announced: 76.0 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: 133660 Total ARIN prefixes after maximum aggregation: 68828 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 106521 Unique aggregates announced from the ARIN address blocks: 40566 ARIN Region origin ASes present in the Internet Routing Table: 13641 ARIN Prefixes per ASN: 7.81 ARIN Region origin ASes announcing only one prefix: 5259 ARIN Region transit ASes present in the Internet Routing Table: 1352 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 725747232 Equivalent to 43 /8s, 66 /16s and 6 /24s Percentage of available ARIN address space announced: 61.8 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: 73238 Total RIPE prefixes after maximum aggregation: 42689 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 66217 Unique aggregates announced from the RIPE address blocks: 43594 RIPE Region origin ASes present in the Internet Routing Table: 14395 RIPE Prefixes per ASN: 4.60 RIPE Region origin ASes announcing only one prefix: 7445 RIPE Region transit ASes present in the Internet Routing Table: 2152 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 422167200 Equivalent to 25 /8s, 41 /16s and 194 /24s Percentage of available RIPE address space announced: 78.6 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, 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, 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: 28362 Total LACNIC prefixes after maximum aggregation: 6743 LACNIC Deaggregation factor: 4.21 Prefixes being announced from the LACNIC address blocks: 26765 Unique aggregates announced from the LACNIC address blocks: 13820 LACNIC Region origin ASes present in the Internet Routing Table: 1270 LACNIC Prefixes per ASN: 21.07 LACNIC Region origin ASes announcing only one prefix: 413 LACNIC Region transit ASes present in the Internet Routing Table: 226 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 24 Number of LACNIC addresses announced to Internet: 72457408 Equivalent to 4 /8s, 81 /16s and 156 /24s Percentage of available LACNIC address space announced: 72.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6764 Total AfriNIC prefixes after maximum aggregation: 1783 AfriNIC Deaggregation factor: 3.79 Prefixes being announced from the AfriNIC address blocks: 5154 Unique aggregates announced from the AfriNIC address blocks: 1460 AfriNIC Region origin ASes present in the Internet Routing Table: 357 AfriNIC Prefixes per ASN: 14.44 AfriNIC Region origin ASes announcing only one prefix: 106 AfriNIC Region transit ASes present in the Internet Routing Table: 82 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC addresses announced to Internet: 14435328 Equivalent to 0 /8s, 220 /16s and 68 /24s Percentage of available AfriNIC address space announced: 43.0 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 1845 8406 479 Korea Telecom (KIX) 17488 1308 136 125 Hathway IP Over Cable Interne 4755 1295 291 148 TATA Communications formerly 7545 1145 205 109 TPG Internet Pty Ltd 17974 1010 281 18 PT TELEKOMUNIKASI INDONESIA 9583 985 72 485 Sify Limited 4134 938 20414 395 CHINANET-BACKBONE 24560 883 303 169 Bharti Airtel Ltd., Telemedia 4808 843 1587 215 CNCGROUP IP network: China169 9829 811 679 41 BSNL National Internet Backbo 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 4001 3837 296 bellsouth.net, inc. 4323 3830 1116 403 Time Warner Telecom 1785 1782 699 132 PaeTec Communications, Inc. 7018 1557 5741 989 AT&T WorldNet Services 20115 1512 1500 658 Charter Communications 2386 1309 585 927 AT&T Data Communications Serv 3356 1217 10924 423 Level 3 Communications, LLC 6478 1209 249 149 AT&T Worldnet Services 11492 1145 222 14 Cable One 22773 1143 2605 71 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 35805 616 56 6 United Telecom of Georgia 3292 449 1899 390 TDC Tele Danmark 30890 433 99 201 Evolva Telecom 702 416 1869 331 UUNET - Commercial IP service 8551 401 356 37 Bezeq International 8866 395 117 18 Bulgarian Telecommunication C 3301 365 1413 320 TeliaNet Sweden 3320 363 7072 316 Deutsche Telekom AG 3215 348 3238 104 France Telecom Transpac 12479 332 576 5 Uni2 Autonomous System 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 1544 2965 242 UniNet S.A. de C.V. 10620 1035 239 157 TVCABLE BOGOTA 28573 923 735 89 NET Servicos de Comunicao S.A 7303 705 363 103 Telecom Argentina Stet-France 22047 549 310 15 VTR PUNTO NET S.A. 6503 541 171 211 AVANTEL, S.A. 18881 532 268 11 Global Village Telecom 7738 477 922 30 Telecomunicacoes da Bahia S.A 3816 459 195 70 Empresa Nacional de Telecomun 14117 455 30 13 Telefonica del Sur S.A. 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 1054 189 9 TEDATA 24863 712 145 41 LINKdotNET AS number 36992 575 240 160 Etisalat MISR 3741 272 850 232 The Internet Solution 33776 219 12 14 Starcomms Nigeria Limited 2018 216 230 110 Tertiary Education Network 6713 176 167 12 Itissalat Al-MAGHRIB 29571 172 19 9 Ci Telecom Autonomous system 29975 133 506 14 Vodacom 5536 113 8 3 Internet Egypt Network 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 4001 3837 296 bellsouth.net, inc. 4323 3830 1116 403 Time Warner Telecom 4766 1845 8406 479 Korea Telecom (KIX) 1785 1782 699 132 PaeTec Communications, Inc. 7018 1557 5741 989 AT&T WorldNet Services 8151 1544 2965 242 UniNet S.A. de C.V. 20115 1512 1500 658 Charter Communications 2386 1309 585 927 AT&T Data Communications Serv 17488 1308 136 125 Hathway IP Over Cable Interne 4755 1295 291 148 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3830 3427 Time Warner Telecom 1785 1782 1650 PaeTec Communications, Inc. 4766 1845 1366 Korea Telecom (KIX) 8151 1544 1302 UniNet S.A. de C.V. 17488 1308 1183 Hathway IP Over Cable Interne 4755 1295 1147 TATA Communications formerly 11492 1145 1131 Cable One 22773 1143 1072 Cox Communications, Inc. 6478 1209 1060 AT&T Worldnet Services 18566 1059 1049 Covad Communications 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 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 1239 Sprint 26973 UNALLOCATED 12.39.154.0/23 1239 Sprint 26973 UNALLOCATED 12.39.155.0/24 1239 Sprint 26973 UNALLOCATED 12.39.159.0/24 1239 Sprint 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.0.0.0/8 38639 NTT Communications Corporatio 41.190.64.0/22 28683 Office des Postes et telecomm 41.190.66.0/24 37039 >>UNKNOWN<< 41.202.96.0/19 29571 Ci Telecom Autonomous system 41.220.144.0/20 36918 ORASCOM TELECOM ALGERIE VSAT 41.220.159.0/24 36918 ORASCOM TELECOM ALGERIE VSAT 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 26452 Local Communications Networks 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:66 /12:192 /13:396 /14:684 /15:1247 /16:11068 /17:5231 /18:8929 /19:18342 /20:22449 /21:22552 /22:29289 /23:28964 /24:166838 /25:977 /26:1225 /27:627 /28:141 /29:9 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2566 4001 bellsouth.net, inc. 4323 2340 3830 Time Warner Telecom 4766 1480 1845 Korea Telecom (KIX) 1785 1242 1782 PaeTec Communications, Inc. 17488 1060 1308 Hathway IP Over Cable Interne 11492 1056 1145 Cable One 18566 1040 1059 Covad Communications 8452 954 1054 TEDATA 10620 945 1035 TVCABLE BOGOTA 7018 936 1557 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:257 12:2001 13:10 15:23 16:3 17:8 20:25 24:1409 27:51 32:48 33:12 38:660 40:99 41:2141 44:3 46:1 47:25 52:6 55:7 56:2 57:24 58:711 59:535 60:427 61:1097 62:1011 63:1993 64:3852 65:2361 66:4137 67:1797 68:1057 69:2826 70:707 71:236 72:1814 73:2 74:2243 75:246 76:308 77:844 78:604 79:387 80:984 81:782 82:464 83:444 84:693 85:1038 86:441 87:692 88:327 89:1557 90:85 91:2719 92:460 93:1102 94:1385 95:577 96:229 97:306 98:545 99:26 109:450 110:313 111:473 112:247 113:273 114:390 115:599 116:1021 117:629 118:424 119:923 120:149 121:787 122:1427 123:872 124:1107 125:1293 128:209 129:204 130:163 131:558 132:245 133:17 134:195 135:44 136:227 137:171 138:255 139:92 140:487 141:136 142:374 143:389 144:465 145:53 146:416 147:169 148:586 149:289 150:150 151:180 152:277 153:168 154:2 155:328 156:184 157:328 158:107 159:368 160:315 161:179 162:268 163:168 164:405 165:528 166:507 167:405 168:801 169:160 170:729 171:50 172:1 173:662 174:653 175:75 178:66 180:419 182:36 183:247 184:35 186:365 187:300 188:1249 189:746 190:3628 192:5732 193:4673 194:3367 195:2777 196:1139 197:1 198:3563 199:3419 200:5326 201:1516 202:7922 203:8319 204:4053 205:2324 206:2542 207:3044 208:3955 209:3474 210:2513 211:1239 212:1717 213:1663 214:596 215:70 216:4574 217:1531 218:500 219:395 220:1109 221:383 222:313 End of report From ccaputo at alt.net Fri Apr 23 13:14:45 2010 From: ccaputo at alt.net (Chris Caputo) Date: Fri, 23 Apr 2010 18:14:45 +0000 (UTC) Subject: Mikrotik RouterOS In-Reply-To: References: <4BC36C83.7040200@freedomnet.co.nz> <4BC36E27.4000005@gmail.com> <4BC37928.5030004@Janoszka.pl> <4BC37D55.6050806@freedomnet.co.nz> <1271120175.15669.35.camel@ub-g-d2> <20100421231422.GD5371@ref.nmedia.net> Message-ID: > char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" }; Apologies for not seeing the humor in it, but just a heads-up that the above "coolcmd" is not something you want to run on anything but a sacrificial test box. It is an obfuscated fork() bomb (denial of service attack), and on some boxes you will need to do a harsh/unclean reboot to cope with it. Chris From owen at delong.com Fri Apr 23 13:14:16 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 23 Apr 2010 11:14:16 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD1DA1A.8080203@matthew.at> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <4BD04752.9050602@jsbc.cc> <4BD12DC0.6080004@matthew.at> <4BD19DEC.1080805@brightok.net> <4BD1D5DA.80202@matthew.at> <4BD1DA1A.8080203@matthew.at> Message-ID: <5770AEBA-164F-4D23-877C-7F0D8D2A2C39@delong.com> On Apr 23, 2010, at 10:34 AM, Matthew Kaufman wrote: > Matthew Kaufman wrote: >> Jack Bates wrote: >>> Matthew Kaufman wrote: >>>> But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from. >>>> >>> >>> Which is why some firewalls already support NAT for IPv6 in some form or fashion. These same firewalls will also usually have layer 7 proxy/filtering support as well. The concerns and breakage of a corporate network are extreme compared to non-corporate networks. >> Agreed on the last point. And I'm following up mostly because I've received quite a few private messages that resulted from folks interpreting "hide internal topology" as "block access to internal topology" (which can be done with filters). What I mean when I say "hide internal topology" is that a passive observer on the outside, looking at something like web server access logs, cannot tell how many subnets are inside the corporation or which accesses come from which subnets. (And preferably, cannot tell whether or not two different accesses came from the same host or different hosts simply by examining the IP addresses... but yes, application-level cooperation -- in the form of a browser which keeps cookies, as an example -- can again expose that type of information) >> > > And to further clarify, I don't think "hide internal topology" is actually something that needs to happen (and can show several ways in which it can be completely violated, including using the browser and/or browser plugins to extract the internal addresses and send them to a server somewhere which can map it all out). But it *is* present as a mandatory checklist item on at least one HIPPA and two SOX audit checklists I've seen,.. and IT departments in major corporations care much more these days about getting a clean SOX audit than they do about providing connectivity... and given how each affects the stock price, that's not surprising. > > Matthew Kaufman Yes, much education is required to the audit community. Owen From owen at delong.com Fri Apr 23 13:10:08 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 23 Apr 2010 11:10:08 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD1D5DA.80202@matthew.at> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <4BD04752.9050602@jsbc.cc> <4BD12DC0.6080004@matthew.at> <4BD19DEC.1080805@brightok.net> <4BD1D5DA.80202@matthew.at> Message-ID: On Apr 23, 2010, at 10:16 AM, Matthew Kaufman wrote: > Jack Bates wrote: >> Matthew Kaufman wrote: >>> But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from. >>> >> >> Which is why some firewalls already support NAT for IPv6 in some form or fashion. These same firewalls will also usually have layer 7 proxy/filtering support as well. The concerns and breakage of a corporate network are extreme compared to non-corporate networks. > Agreed on the last point. And I'm following up mostly because I've received quite a few private messages that resulted from folks interpreting "hide internal topology" as "block access to internal topology" (which can be done with filters). What I mean when I say "hide internal topology" is that a passive observer on the outside, looking at something like web server access logs, cannot tell how many subnets are inside the corporation or which accesses come from which subnets. (And preferably, cannot tell whether or not two different accesses came from the same host or different hosts simply by examining the IP addresses... but yes, application-level cooperation -- in the form of a browser which keeps cookies, as an example -- can again expose that type of information) > So can TCP fingerprinting and several other techniques. Finally, the belief that hiding the number of subnets or which hosts share subnets is a meaningful enhancement to security is dubious at best. Owen From matthew at matthew.at Fri Apr 23 13:40:34 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 23 Apr 2010 11:40:34 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <4BD04752.9050602@jsbc.cc> <4BD12DC0.6080004@matthew.at> <4BD19DEC.1080805@brightok.net> <4BD1D5DA.80202@matthew.at> Message-ID: <4BD1E9A2.3090203@matthew.at> Owen DeLong wrote: > On Apr 23, 2010, at 10:16 AM, Matthew Kaufman wrote: > > >> Jack Bates wrote: >> >>> Matthew Kaufman wrote: >>> >>>> But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from. >>>> >>>> >>> Which is why some firewalls already support NAT for IPv6 in some form or fashion. These same firewalls will also usually have layer 7 proxy/filtering support as well. The concerns and breakage of a corporate network are extreme compared to non-corporate networks. >>> >> Agreed on the last point. And I'm following up mostly because I've received quite a few private messages that resulted from folks interpreting "hide internal topology" as "block access to internal topology" (which can be done with filters). What I mean when I say "hide internal topology" is that a passive observer on the outside, looking at something like web server access logs, cannot tell how many subnets are inside the corporation or which accesses come from which subnets. (And preferably, cannot tell whether or not two different accesses came from the same host or different hosts simply by examining the IP addresses... but yes, application-level cooperation -- in the form of a browser which keeps cookies, as an example -- can again expose that type of information) >> >> > So can TCP fingerprinting and several other techniques. > > Finally, the belief that hiding the number of subnets or which hosts share subnets is a meaningful enhancement to security is dubious at best. > > Agreed, but see my own followup to myself. Entirely dubious, and yet entirely required by audit checklists which feed up into SEC reporting which affects stock prices. Matthew Kaufman From bicknell at ufp.org Fri Apr 23 14:33:21 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 23 Apr 2010 12:33:21 -0700 Subject: Connectivity to an IPv6-only site In-Reply-To: <14793.1272042510@localhost> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> <538D27E2-4771-4420-821D-BA8879B6822A@delong.com> <5598.1272031635@localhost> <201004231645.o3NGj5e5066388@drugs.dv.isc.org> <14793.1272042510@localhost> Message-ID: <20100423193321.GB68971@ussenterprise.ufp.org> In a message written on Fri, Apr 23, 2010 at 01:08:30PM -0400, Valdis.Kletnieks at vt.edu wrote: > No, the problems are probably further back in time. We first started turning up > IPv6 back in 1997 or so. There's a *very* good chance that we turned it off a > decade ago (or whenever people *first* started listing quad-A's in NS entries) > due to breakage and never actually revisited it since then. This would have > been in the era of early 6bone and "your IPv6 connection is probably tromboned > through Tokyo". Back in that era there was a very real problem of islands. That is, a group would set up IPv6 internally but never connect to the "Internet" (however you want to define that). So they got a AAAA and blackholed trying to reach it. When you look at the content providers (Yahoo and Google tend to speak about this) they are very concerned about this problem as end users can make themselves islands fairly easily (an island of your house, for instance). While the numbers are troubling for them, they are actually really good news. Depending on who's number you believe and when somewhere between 0.01% and 0.5% of end users are on unconnected islands. Now, when you serve a billion page views a day, dropping 0.5% is a huge concern; but it actually means the island problem has gotten really small. More importantly, those are end users who are islands. Someone who's airport is misconfigured making them appear to have IPv6 when they do not. Most of these folks don't run recursive name servers. While I don't know of any hard data, I would expect the number of nameservers in islands to be at least one, and perhaps two or three orders of magnitude less. So, in the context of publishing AAAA's for your nameservers, I think things are extremely safe at this point. If the recursive box on the other end has IPv6 at all and tries to use the AAAA there is a very good chance it will have working IPv6. In the context of publshing AAAA's for your services (e.g. WWW), you need to look at the Google and Yahoo stats network wide, look at your own user base, and determine what level of breakage is acceptable. Keep in mind that IPv4 doesn't always work, so 0% is an unachieveable goal. :) -- 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 franck at genius.com Fri Apr 23 14:38:50 2010 From: franck at genius.com (Franck Martin) Date: Sat, 24 Apr 2010 07:38:50 +1200 (MAGST) Subject: Connectivity to an IPv6-only site In-Reply-To: <20100423193321.GB68971@ussenterprise.ufp.org> Message-ID: <18717161.1494.1272051526147.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Leo Bicknell" > To: "NANOG" > Sent: Saturday, 24 April, 2010 7:33:21 AM > Subject: Re: Connectivity to an IPv6-only site > In a message written on Fri, Apr 23, 2010 at 01:08:30PM -0400, > Valdis.Kletnieks at vt.edu wrote: > > No, the problems are probably further back in time. We first started > > turning up > > IPv6 back in 1997 or so. There's a *very* good chance that we turned > > it off a > > decade ago (or whenever people *first* started listing quad-A's in > > NS entries) > > due to breakage and never actually revisited it since then. This > > would have > > been in the era of early 6bone and "your IPv6 connection is probably > > tromboned through Tokyo". > > Back in that era there was a very real problem of islands. That > is, a group would set up IPv6 internally but never connect to the > "Internet" (however you want to define that). So they got a AAAA > and blackholed trying to reach it. > > When you look at the content providers (Yahoo and Google tend to > speak about this) they are very concerned about this problem as end > users can make themselves islands fairly easily (an island of your > house, for instance). > > While the numbers are troubling for them, they are actually really > good news. Depending on who's number you believe and when somewhere > between 0.01% and 0.5% of end users are on unconnected islands. > Now, when you serve a billion page views a day, dropping 0.5% is a > huge concern; but it actually means the island problem has gotten > really small. > > More importantly, those are end users who are islands. Someone > who's airport is misconfigured making them appear to have IPv6 when > they do not. Most of these folks don't run recursive name servers. > While I don't know of any hard data, I would expect the number of > nameservers in islands to be at least one, and perhaps two or three > orders of magnitude less. > > So, in the context of publishing AAAA's for your nameservers, I think > things are extremely safe at this point. If the recursive box on the > other end has IPv6 at all and tries to use the AAAA there is a very > good chance it will have working IPv6. > > In the context of publshing AAAA's for your services (e.g. WWW), > you need to look at the Google and Yahoo stats network wide, look > at your own user base, and determine what level of breakage is > acceptable. Keep in mind that IPv4 doesn't always work, so 0% is > an unachieveable goal. :) Well google will not serve you an AAAA record if you are not registered with them. This to avoid all the issues above. Once you are registered, expect lot of IPv6 traffic! From fedorafans at gmail.com Fri Apr 23 15:19:37 2010 From: fedorafans at gmail.com (fedora fedora) Date: Fri, 23 Apr 2010 15:19:37 -0500 Subject: rACL vty and Juniper Message-ID: Greeting, I am looking up some ACL rules and there are something i am not quite sure, I know on cisco router, applying rACL will protect the router itself, no transit traffic will hit the rACL rules or router RP. So i guess it is safe i assume rACL only take control and management plane traffic. But how about Line vty access-class command? Does it only take management plane traffic? Do i need this if i have rACL defined? and on Juniper router, does it have similar concept? i am only aware of the input filter on the lo0 interface. so there is nothing like rACL? Thanks FD From tony at hoyle.me.uk Fri Apr 23 15:21:34 2010 From: tony at hoyle.me.uk (Tony Hoyle) Date: Fri, 23 Apr 2010 21:21:34 +0100 Subject: Connectivity to an IPv6-only site In-Reply-To: <4BD1432F.4070406@ibctech.ca> References: <4BD1432F.4070406@ibctech.ca> Message-ID: <4BD2014E.3080702@hoyle.me.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23/04/2010 07:50, Steve Bertrand wrote: > This is a no-brainer, because I know that everyone who reads this will > visit the link. All I request is an off-list message stating if you > could get there or not (it won't be possible to parse my weblogs for > those who can't): > > http://onlyv6.com > Works here.. I'd expect anyone with ipv6 connectivity should have no issues. The issues tend to be with dual stack sites where the ipv6 connectivity is broken but the client has (for some reason) picked up a default route... it takes several seconds for the v6 connect to fall back the site appears 'slow' to some users. I also setup an ipv6 only email address (tmh at goipv6.org.uk) primarily to see if it got any spam :p Nothing yet.. Tony -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL0gFOAAoJEJ1qCQ6ePCDUZBIH/1kVtmwc67QOfXE92nzM3xFS ytnwoafBKQK9Tm83NzGokVu8UTIOSboOuZ+3YV+83oRmZOnB55wN0cY+TSalwgi0 Qqexs4vxYv5FzrhZAdd6+au/lVERjBCIEmu9JXYFc8+N/KzLHtbmL68qZv3tC6F9 +NexdvK/tkvvjr1EeN7ltOSaMLayozafzOY0r8nmpmosmsikEDtwENPm5N07b9pm ccCu7UMSHPNycjBIX3+JbYxifgWLVCVCE0Anm5bikej3YYTOKNAJCDMbSlKgQNCm DKSvyjI+h3EdjlPtfwuAclBcjP6CW+t8qaHERtnOG0fEZfhoTrffpgwluLUWELY= =l9MS -----END PGP SIGNATURE----- From cidr-report at potaroo.net Fri Apr 23 17:00:04 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 Apr 2010 22:00:04 GMT Subject: BGP Update Report Message-ID: <201004232200.o3NM049v026204@wattle.apnic.net> BGP Update Report Interval: 15-Apr-10 -to- 22-Apr-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 17201 1.4% 28.8 -- BSNL-NIB National Internet Backbone 2 - AS38494 17096 1.4% 4274.0 -- BBGISA-AS-ID-AP PT. Bakrie & Brothers, Tbk 3 - AS44310 15948 1.3% 5316.0 -- NGS-AS JSC Novosibirsky Gorodskoi Site 4 - AS31148 13604 1.1% 51.3 -- FREENET-AS FreeNet ISP 5 - AS28477 11556 1.0% 1284.0 -- Universidad Autonoma del Esstado de Morelos 6 - AS14522 9829 0.8% 37.8 -- Satnet 7 - AS6298 9785 0.8% 12.7 -- ASN-CXA-PH-6298-CBS - Cox Communications Inc. 8 - AS22300 9393 0.8% 3131.0 -- WIKIA - Wikia, Inc. 9 - AS10620 9357 0.8% 8.7 -- Telmex Colombia S.A. 10 - AS8452 8852 0.7% 9.5 -- TEDATA TEDATA 11 - AS17488 8790 0.7% 7.0 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 12 - AS12479 8685 0.7% 310.2 -- UNI2-AS Uni2 - Lince telecomunicaciones 13 - AS26598 8618 0.7% 1231.1 -- Its Brasil Tecnologia 14 - AS26025 8559 0.7% 8559.0 -- COC - City of Calgary 15 - AS16569 8250 0.7% 8250.0 -- ASN-CITY-OF-CALGARY - City of Calgary 16 - AS25620 7297 0.6% 46.8 -- COTAS LTDA. 17 - AS17964 7053 0.6% 213.7 -- DXTNET Beijing Dian-Xin-Tong Network Technologies Co., Ltd. 18 - AS7018 6971 0.6% 12.3 -- ATT-INTERNET4 - AT&T WorldNet Services 19 - AS17974 6853 0.6% 13.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 20 - AS6478 6751 0.6% 7.7 -- ATT-INTERNET3 - AT&T WorldNet Services TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS26025 8559 0.7% 8559.0 -- COC - City of Calgary 2 - AS16569 8250 0.7% 8250.0 -- ASN-CITY-OF-CALGARY - City of Calgary 3 - AS49121 5422 0.5% 5422.0 -- ACADEMY-AS PE Pavlovskaya Natalia Leonidovna 4 - AS44310 15948 1.3% 5316.0 -- NGS-AS JSC Novosibirsky Gorodskoi Site 5 - AS38494 17096 1.4% 4274.0 -- BBGISA-AS-ID-AP PT. Bakrie & Brothers, Tbk 6 - AS8588 3629 0.3% 3629.0 -- JD_ABRA_EU-AS Abra S.A. 7 - AS22300 9393 0.8% 3131.0 -- WIKIA - Wikia, Inc. 8 - AS5691 2590 0.2% 2590.0 -- MITRE-AS-5 - The MITRE Corporation 9 - AS50531 2514 0.2% 2514.0 -- FAST-L-AS1 Limited Liabilily Company "FastLine" 10 - AS28477 11556 1.0% 1284.0 -- Universidad Autonoma del Esstado de Morelos 11 - AS26598 8618 0.7% 1231.1 -- Its Brasil Tecnologia 12 - AS38680 1224 0.1% 1224.0 -- CMBHK-AS-KR CMB 13 - AS28052 870 0.1% 870.0 -- Arte Radiotelevisivo Argentino 14 - AS3397 854 0.1% 854.0 -- DAVINCI - Davinci Broadband Inc. 15 - AS28671 1373 0.1% 686.5 -- Konecta Telecomunica??es Ltda 16 - AS17672 4617 0.4% 659.6 -- CHINATELECOM-HE-AS-AP asn for Hebei Provincial Net of CT 17 - AS8100 6508 0.5% 650.8 -- IPTELLIGENT - IPTelligent LLC 18 - AS30341 1902 0.2% 634.0 -- SCTA-ASN - South Central Telephone Association 19 - AS31688 613 0.1% 613.0 -- SPLIO-AS Splio AS Number 20 - AS18106 604 0.1% 604.0 -- VIEWQWEST-SG-AP Viewqwest Pte Ltd TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 200.13.36.0/24 11508 0.9% AS28477 -- Universidad Autonoma del Esstado de Morelos 2 - 208.98.231.0/24 8559 0.7% AS26025 -- COC - City of Calgary 3 - 208.98.230.0/24 8250 0.6% AS16569 -- ASN-CITY-OF-CALGARY - City of Calgary 4 - 96.47.228.0/23 6405 0.5% AS8100 -- IPTELLIGENT - IPTelligent LLC 5 - 91.212.142.0/24 5422 0.4% AS49121 -- ACADEMY-AS PE Pavlovskaya Natalia Leonidovna 6 - 195.93.186.0/24 5326 0.4% AS44310 -- NGS-AS JSC Novosibirsky Gorodskoi Site 7 - 195.93.187.0/24 5311 0.4% AS44310 -- NGS-AS JSC Novosibirsky Gorodskoi Site 8 - 195.93.186.0/23 5311 0.4% AS44310 -- NGS-AS JSC Novosibirsky Gorodskoi Site 9 - 216.83.57.0/24 4695 0.4% AS22300 -- WIKIA - Wikia, Inc. 10 - 216.83.58.0/24 4695 0.4% AS22300 -- WIKIA - Wikia, Inc. 11 - 123.176.127.0/24 4279 0.3% AS38494 -- BBGISA-AS-ID-AP PT. Bakrie & Brothers, Tbk 12 - 123.176.120.0/24 4279 0.3% AS38494 -- BBGISA-AS-ID-AP PT. Bakrie & Brothers, Tbk 13 - 123.176.121.0/24 4269 0.3% AS38494 -- BBGISA-AS-ID-AP PT. Bakrie & Brothers, Tbk 14 - 123.176.122.0/24 4269 0.3% AS38494 -- BBGISA-AS-ID-AP PT. Bakrie & Brothers, Tbk 15 - 153.23.252.0/22 3816 0.3% AS135 -- DNIC-AS-00135 - DoD Network Information Center 16 - 91.208.133.0/24 3629 0.3% AS8588 -- JD_ABRA_EU-AS Abra S.A. 17 - 206.184.16.0/24 2851 0.2% AS174 -- COGENT Cogent/PSI 18 - 85.60.194.0/23 2680 0.2% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 19 - 211.160.176.0/22 2661 0.2% AS9814 -- FIBRLINK Beijing FibrLINK Networks Co.,Ltd. 20 - 192.12.120.0/24 2590 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 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 Apr 23 17:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 Apr 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201004232200.o3NM00Jr026187@wattle.apnic.net> This report has been generated at Fri Apr 23 21:11:46 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 16-04-10 320934 198680 17-04-10 321912 198118 18-04-10 321198 198102 19-04-10 321287 198188 20-04-10 321395 198320 21-04-10 321711 198627 22-04-10 321875 198285 23-04-10 321746 198357 AS Summary 34227 Number of ASes in routing system 14575 Number of ASes announcing only one prefix 4426 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 97146464 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'). --- 23Apr10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 321712 198352 123360 38.3% All ASes AS6389 4001 301 3700 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4426 1379 3047 68.8% TWTC - tw telecom holdings, inc. AS4766 1845 493 1352 73.3% KIXS-AS-KR Korea Telecom AS22773 1141 76 1065 93.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 1059 33 1026 96.9% COVAD - Covad Communications Co. AS17488 1308 339 969 74.1% HATHWAY-NET-AP Hathway IP Over Cable Internet AS7545 1160 227 933 80.4% TPG-INTERNET-AP TPG Internet Pty Ltd AS8151 1543 644 899 58.3% Uninet S.A. de C.V. AS10620 1033 161 872 84.4% Telmex Colombia S.A. AS19262 1091 248 843 77.3% VZGNI-TRANSIT - Verizon Internet Services Inc. AS6478 1209 377 832 68.8% ATT-INTERNET3 - AT&T WorldNet Services AS4755 1289 463 826 64.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS8452 1054 390 664 63.0% TEDATA TEDATA AS24560 882 273 609 69.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS5668 808 201 607 75.1% AS-5668 - CenturyTel Internet Holdings, Inc. AS1785 1783 1181 602 33.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS4804 678 84 594 87.6% MPX-AS Microplex PTY LTD AS7303 705 111 594 84.3% Telecom Argentina S.A. AS4808 843 254 589 69.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS17908 654 83 571 87.3% TCISL Tata Communications AS7018 1558 992 566 36.3% ATT-INTERNET4 - AT&T WorldNet Services AS18101 669 113 556 83.1% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS3356 1218 689 529 43.4% LEVEL3 Level 3 Communications AS22047 549 50 499 90.9% VTR BANDA ANCHA S.A. AS4780 675 178 497 73.6% SEEDNET Digital United Inc. AS17676 573 81 492 85.9% GIGAINFRA Softbank BB Corp. AS28573 923 433 490 53.1% NET Servicos de Comunicao S.A. AS9443 555 74 481 86.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS27064 917 441 476 51.9% DNIC-ASBLK-27032-27159 - DoD Network Information Center AS35805 616 148 468 76.0% UTG-AS United Telecom AS Total 36765 10517 26248 71.4% Top 30 total Possible Bogus Routes 14.0.0.0/8 AS38639 HANABI NTT Communications Corporation 41.190.64.0/22 AS28683 BENINTELECOM 41.190.66.0/24 AS37039 41.202.96.0/19 AS29571 CITelecom-AS 41.220.144.0/20 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 41.220.159.0/24 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 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 AS26452 BRING-AS - BringCom, Inc. 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.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales Telesat S.A. 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 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 78.41.80.0/24 AS29158 DE-IP69 Tux-Service 78.41.81.0/24 AS29158 DE-IP69 Tux-Service 78.41.82.0/24 AS29158 DE-IP69 Tux-Service 78.41.83.0/24 AS29158 DE-IP69 Tux-Service 78.41.84.0/24 AS29158 DE-IP69 Tux-Service 78.41.86.0/24 AS29158 DE-IP69 Tux-Service 78.41.87.0/24 AS29158 DE-IP69 Tux-Service 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 82.199.128.0/19 AS33891 CORE-BACKBONE Core-Backbone GmbH 110.34.40.0/22 AS24399 ABN-PEERING-AS-AP Asia Broadcast Networks Peering 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. 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 119.42.144.0/21 AS45753 NETSEC-HK Unit 1205-1207 119.42.144.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.145.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.146.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.147.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.148.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.149.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.150.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.151.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.160.200.0/23 AS45122 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 178.23.136.0/21 AS8343 DORIS-AS DOnbass Regional Information System 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 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.45.0/24 AS2905 TICSA-ASN 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.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS 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 194.28.84.0/22 AS21219 DATAGROUP CJSC DATAGROUP 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.29.40.0/22 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 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.254.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 AS33052 VZUNET - Verizon Data Services 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.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 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 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.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - 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.52.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company 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.128.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 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.89.8.0/22 AS6648 BAYAN-TELECOMMUNICATIONS Bayan Telecommunications, Inc. 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.166.166.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 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 203.215.52.0/22 AS18101 RIL-IDC Reliance Infocom Ltd Internet Data Centre, 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.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 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.66.152.0/24 AS18499 208.66.153.0/24 AS18499 208.66.154.0/24 AS18499 208.66.155.0/24 AS18499 208.66.156.0/24 AS18499 208.66.157.0/24 AS18499 208.66.158.0/24 AS18499 208.66.159.0/24 AS18499 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.177.160.0/24 AS18499 209.177.161.0/24 AS18499 209.177.162.0/24 AS18499 209.177.163.0/24 AS18499 209.177.164.0/24 AS18499 209.177.165.0/24 AS18499 209.177.166.0/24 AS18499 209.177.167.0/24 AS18499 209.177.168.0/24 AS18499 209.177.169.0/24 AS18499 209.177.170.0/24 AS18499 209.177.171.0/24 AS18499 209.177.172.0/24 AS18499 209.177.173.0/24 AS18499 209.177.174.0/24 AS18499 209.177.175.0/24 AS18499 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.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, 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 223.0.0.0/8 AS38639 HANABI NTT Communications Corporation 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 nanogf at spoofer.com Fri Apr 23 21:16:52 2010 From: nanogf at spoofer.com (nanogf .) Date: Fri, 23 Apr 2010 19:16:52 -0700 Subject: Recommendations for DDOS detection software? Message-ID: <20100423191652.291D984F@resin07.mta.everyone.net> http://docs.google.com/viewer?url=http://www.andrisoft.com/files/WANGuard_Platform_Comparison.pdf --- major at mhtx.net wrote: From: Major Hayden To: nanog at nanog.org Subject: Recommendations for DDOS detection software? Date: Fri, 23 Apr 2010 07:49:26 -0500 Hello there, Does anyone have any recommendations for DDOS detection software which runs on Linux? We're currently testing out Network Probe: http://objectplanet.com/probe/ We've written some custom "top talkers" scripts to analyze tcpdump data, but we'd like a more elegant solution with some basic alarm functionality. Thanks! -- Major Hayden _____________________________________________________________ Get your own *free* email address like this one from www.OwnEmail.com From bbillon-ml at splio.fr Sat Apr 24 07:09:10 2010 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Sat, 24 Apr 2010 14:09:10 +0200 Subject: Hotmail bouncing email In-Reply-To: <4BD1DDE4.1070505@rollernet.us> References: <4BD1AA2D.5020505@phaze.org> <4BD1DDE4.1070505@rollernet.us> Message-ID: <4BD2DF66.3020909@splio.fr> "fail" or "soft fail"? Le 23/04/2010 19:50, Seth Mattinen a ?crit : > On 4/23/10 7:09 AM, Greg Estabrooks wrote: > >> >> Is anyone else out there getting reports of hotmail randomly bouncing >> emails with just a message of "failed"? >> >> Over the last 2 weeks we've had a dozens of complaints of hosting >> customers spanning dozens of domains not receiving emails from hotmail >> users. Checking our logs shows the messages were never even attempted >> to be delivered and all forwarded in bounce messages literally just say >> "Delivery failed", yet we are still happily processing thousands of >> other emails from hotmail everyday. >> >> Now I'm wondering if this is restricted to us in someway or part of a >> larger problem. >> >> > > I've had hotmail complaints lately too, except when I checked my logs > the "error" has a 250 response. > > ~Seth > > From gih at apnic.net Sat Apr 24 07:47:01 2010 From: gih at apnic.net (Geoff Huston) Date: Sat, 24 Apr 2010 22:47:01 +1000 Subject: Connectivity to an IPv6-only site In-Reply-To: <4BD159C1.2090307@ibctech.ca> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> Message-ID: On 23/04/2010, at 6:26 PM, Steve Bertrand wrote: > > This is a personal research project, in which I want to learn about the > health of connectivity, and about other situations that causes breakage > that I haven't considered before. > A very fine objective in my opinion. There are a few similar exercises underway -- the outputs from a similar set of IPv6 connectivity tests I've been doing is at http://www.potaroo.net/stats/1x1/ (yes, you can click on the graphs on that page to get larger images) (and yes, visiting this URL will run the tests of V6 DNS, V6 dual stack preference and capability to retrieve a V6 only object on your browser client) A discussion of the topic of IPv6 measurement work can be found at http://labs.ripe.net/node/ipv6-measurements Geoff From Bryan.Welch at arrisi.com Sat Apr 24 10:04:17 2010 From: Bryan.Welch at arrisi.com (Welch, Bryan) Date: Sat, 24 Apr 2010 08:04:17 -0700 Subject: level 3 issues this morning Message-ID: FYI.... There is some routing flakiness going on with Level 3 this morning, which L3 confirms. Some routes sent to their network are dying, some not. We are having reach ability issues over them on the west coast. Bypassing level 3 for the moment. Bryan From sethm at rollernet.us Sat Apr 24 11:01:00 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 24 Apr 2010 09:01:00 -0700 Subject: Hotmail bouncing email In-Reply-To: <4BD2DF66.3020909@splio.fr> References: <4BD1AA2D.5020505@phaze.org> <4BD1DDE4.1070505@rollernet.us> <4BD2DF66.3020909@splio.fr> Message-ID: <4BD315BC.3090900@rollernet.us> On 4/24/10 5:09 AM, Benjamin Billon wrote: > "fail" or "soft fail"? > Soft fail. Someone forwarding to their hotmail account. They also said a whole bunch of 250's with ID responses never made it to their inbox, and that it only started happening within the last week. ~Seth From john_brzozowski at cable.comcast.com Sat Apr 24 14:04:59 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Sat, 24 Apr 2010 15:04:59 -0400 Subject: Connectivity to an IPv6-only site In-Reply-To: <95E29521-7CCB-4142-9718-8A3F4F9D3621@puck.nether.net> Message-ID: FYI - Comcast has dual stacked enabled recursive name servers, see the following web site: http://dns.comcast.net/dns-ip-addresses3.php John On 4/23/10 8:42 AM, "Jared Mauch" wrote: > > > On Apr 23, 2010, at 5:49 AM, Dave Hart wrote: > >> On Fri, Apr 23, 2010 at 08:26 UTC, Steve Bertrand wrote: >>> - in WHOIS, I have ns1 and ns2.onlyv6.com listed as the authoritative >>> name servers >>> >>> - both of these servers *only* have IPv6 addresses >> >> Which seems a bit far afield from reality to me. Yes, there are lots >> of folks with IPv6 connectivity and v4-only recursive DNS servers. I >> don't think ISPs will have problems setting aside a handful of IPv4 >> addresses for authoritative DNS infrastructure to work around this >> until v6 transport in recursive DNS servers is common enough. > > Not really, having your nameservers be IPv6 enabled is a reasonable thing to > do. > > FYI: on comcast I see SERVFAIL, meaning their recursives do not have IPv6 > transport. > > (I know we have that at my employer on our customer-facing recursives). > > ; <<>> DiG 9.6.0-APPLE-P2 <<>> any www.onlyv6.com. > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54773 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.onlyv6.com. IN ANY > > ;; Query time: 1605 msec > ;; SERVER: 68.87.72.130#53(68.87.72.130) > ;; WHEN: Fri Apr 23 08:41:08 2010 > ;; MSG SIZE rcvd: 32 > > > ========================================= 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 joelja at bogus.com Sat Apr 24 14:07:00 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 24 Apr 2010 12:07:00 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <120252AE-C717-4CF3-89AB-5A3E652992F9@americafree.tv> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <20100422143403.GB8526@vacation.karoshi.com.> <006901cae22d$2b1ce4c0$8156ae40$@gmail.com> <120252AE-C717-4CF3-89AB-5A3E652992F9@americafree.tv> Message-ID: <4BD34154.6010408@bogus.com> On 04/22/2010 08:25 AM, Marshall Eubanks wrote: > > On Apr 22, 2010, at 11:04 AM, John Lightfoot wrote: > >> That's Hedley. >> > > I believe that he is talking about Hedy Lamarr, the co-inventor of > frequency hopping spread spectrum. The patent which bears her and George Antheil's name is by no means (and about 30 years) the earliest example of this technology. > Regards > Marshall > >> -----Original Message----- >> From: bmanning at vacation.karoshi.com >> [mailto:bmanning at vacation.karoshi.com] >> Sent: Thursday, April 22, 2010 10:34 AM >> To: Simon Perreault >> Cc: nanog at nanog.org >> Subject: Re: Rate of growth on IPv6 not fast enough? >> >> On Thu, Apr 22, 2010 at 08:34:20AM -0400, Simon Perreault wrote: >>> On 2010-04-22 07:18, William Herrin wrote: >>>> On the other hand, I could swear I've seen a draft where the PC picks >>>> up random unused addresses in the lower 64 for each new outbound >>>> connection for anonymity purposes. >>> >>> That's probably RFC 4941. It's available in pretty much all operating >>> systems. I don't think there's any IPR issue to be afraid of. >> >> not RFC4941... think abt applying Heddy Lamars >> patents on spread-spectrum to source address selection. >> >> --bill >> >> >> >> > > From LarrySheldon at cox.net Sat Apr 24 14:12:11 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 24 Apr 2010 14:12:11 -0500 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD34154.6010408@bogus.com> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <20100422143403.GB8526@vacation.karoshi.com.> <006901cae22d$2b1ce4c0$8156ae40$@gmail.com> <120252AE-C717-4CF3-89AB-5A3E652992F9@americafree.tv> <4BD34154.6010408@bogus.com> Message-ID: <4BD3428B.20703@cox.net> On 4/24/2010 14:07, Joel Jaeggli wrote: > The patent which bears her and George Antheil's name is by no means (and > about 30 years) the earliest example of this technology. Few patents are. I can't think of a one, but I suppose there must be one containing no prior art at all. Does a movie star of the startlingly attractive persuasion being an accomplished engineer bother you? -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From jbates at brightok.net Sat Apr 24 16:15:07 2010 From: jbates at brightok.net (Jack Bates) Date: Sat, 24 Apr 2010 16:15:07 -0500 Subject: Connectivity to an IPv6-only site In-Reply-To: <14793.1272042510@localhost> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> <538D27E2-4771-4420-821D-BA8879B6822A@delong.com> <5598.1272031635@localhost> <201004231645.o3NGj5e5066388@drugs.dv.isc.org> <14793.1272042510@localhost> Message-ID: <4BD35F5B.8060904@brightok.net> Valdis.Kletnieks at vt.edu wrote: > No, the problems are probably further back in time. We first started turning up > IPv6 back in 1997 or so. There's a *very* good chance that we turned it off a > decade ago (or whenever people *first* started listing quad-A's in NS entries) > due to breakage and never actually revisited it since then. This would have > been in the era of early 6bone and "your IPv6 connection is probably tromboned > through Tokyo". I periodically see issues with idiotic load balancers that don't respond to anything except A records for specific domains. This causes problems when requesting AAAA records and delays waiting for timeouts before going to A. newegg fixed theirs though, yipeee! :) Jack From joelja at bogus.com Sat Apr 24 19:47:41 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 24 Apr 2010 17:47:41 -0700 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> Message-ID: <4BD3912D.506@bogus.com> On 04/22/2010 11:23 AM, Christopher Morrow wrote: > On Thu, Apr 22, 2010 at 12:13 PM, Bill Bogstad wrote: >> On Thu, Apr 22, 2010 at 11:03 AM, David Conrad wrote: >>> On Apr 21, 2010, at 10:48 PM, Christopher Morrow wrote: >>>>> So what happens when you change providers? How are you going to keep >>>>> using globals that now aren't yours? >>>> use pi space, request it from your local friendly RIR. >>> >>> And don't forget to invest in memory manufacturers and router vendors :-) >> >> Only required if those addresses are advertised to the Internet. >> Which is apparently NOT >> what people want to do with it. In addition, it seems like the RIRs >> frown on not publishing your IPv6 PI allocations. If you go this > > this is commonly held up as a reason that getting allocations is hard, > but the infrastructure micro-allocations are never to be seen in the > global table. > > It woudl be super nice if some kind RIR people could comment here, I > believe in the ARIN region all you NEED to do is provide a spreadsheet > showing your utilization, checking for the routes in the 'DFZ' > (bmanning-summons) isn't relevant for additional requests. > >> route, be sure to 'justify' as large an allocation as you could ever >> possibly imagine using because you'll only get one bite from that >> apple. > > see previous comment, I believe this is a red-herring. An entity that I worked for in the arin recieved an ip6 micro-allocation (/43) under current arin policy. it was our understanding at the time that that 6.5.8.3 was current the criterion for additional assignments. while I could imagine other criterion for being applied the assignment of 4,771 /56 prefixes doesn't seem particularly onerous to document, even if as it happens, it's not particularly aligned with the initial assignment policy which was tied to the number of /48 site subnets that were assigned. >> >> Or maybe someone could offer to advertise these deliberately >> unreachable addresses for a small fee and then null route any stray >> packets that happen to want to get >> there. Would this satisfy the letter (if not the spirit) for >> justifying PI space? > > you still have to provide SWIP, RWHOIS or some other accounting of the > usage (spreadsheet/csvfile seems to be historically acceptable) > > -chris > >> Bill Bogstad >> >> > From joelja at bogus.com Sat Apr 24 19:56:17 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 24 Apr 2010 17:56:17 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD12DC0.6080004@matthew.at> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <4BD04752.9050602@jsbc.cc> <4BD12DC0.6080004@matthew.at> Message-ID: <4BD39331.6010300@bogus.com> On 04/22/2010 10:18 PM, Matthew Kaufman wrote: > Owen DeLong wrote: >> On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote: >> >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 4/22/2010 05:34, Simon Perreault wrote: >>> >>>> On 2010-04-22 07:18, William Herrin wrote: >>>> >>>>> On the other hand, I could swear I've seen a draft where the PC >>>>> picks up random unused addresses in the lower 64 for each new >>>>> outbound connection for anonymity purposes. >>>>> >>>> That's probably RFC 4941. It's available in pretty much all >>>> operating systems. I don't think there's any IPR issue to be afraid >>>> of. >>>> >>>> Simon >>>> >>> I think this is different. They're talking about using a new IPv6 for >>> each connection. RFC4941 just changes it over time IIRC. IMHO that's >>> still pretty good privacy, at least on par with a NATed IPv4 from the >>> outside perspective, especially if you rotated through temporary IPv6s >>> fairly frequently. >>> >> >> 4941 specified changing over time as one possibility. It does allow >> for per flow or any other host based determination of when it needs a new >> address. >> >> Owen >> >> >> > But none of this does what NAT does for a big enterprise, which is to > *hide internal topology*. Yes, addressing the privacy concerns that come > from using lower-64-bits-derived-from-MAC-address is required, but it is > also necessary (for some organizations) to make it impossible to tell > that this host is on the same subnet as that other host, as that would > expose information like which host you might want to attack in order to > get access to the financial or medical records, as well as whether or > not the executive floor is where these interesting website hits came from. Does your nat box reset or non-determisitically rewrite the ttl on the outgoing packet? ALGs are dramatically better topology hiding devices... > Matthew Kaufman > From buhr+nanog at asaurus.net Sat Apr 24 20:02:47 2010 From: buhr+nanog at asaurus.net (Kevin Buhr) Date: Sat, 24 Apr 2010 20:02:47 -0500 Subject: Connectivity to an IPv6-only site In-Reply-To: <5598.1272031635@localhost> (Valdis Kletnieks's message of "Fri, 23 Apr 2010 10:07:15 -0400") References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> <538D27E2-4771-4420-821D-BA8879B6822A@delong.com> <5598.1272031635@localhost> Message-ID: <87vdbg4a4o.fsf@doris.mad.asaurus.net> Valdis.Kletnieks at vt.edu writes: > > Ours are currently intentionally configured to not issue queries over IPv6, > because at one time, there were *so many* sites that listed unreachable quad-A > NS records. Our DNS guy is more than willing to revisit that config switch. > > Anybody have some statistics on what the current situation is? I just dredged a list of 570 one, two, and three-dot domains from a mailing list (a bunch of recent messages on debian-user). Digging them gave 919 unique nameserver domain names, and digging those gave 119 AAAA addresses. Of these, 106 responded to a DNS query (for the nameserver's own AAAA address) in some fashion, and 13 didn't. Of the 13, 5 were cogentco.com DNS servers and unreachable over my HE tunnel thanks to ongoing peering disputes. In all cases, the nameservers with AAAA addresses had A addresses as well. (I got similar results with a list of domains taken from recent NANOG postings, but then decided to look at the debian-user results in case NANOG was unrepresentative.) Anyway, it looks like bad IPv6 nameserver addresses are the exception rather than the rule. Whether to flip on IPv6 queries will sort of depend on how your resolvers behave when they receive a typical "bad" response with 2 broken IPv6 addresses and 2 working IPv4 addresses. -- Kevin From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Apr 24 20:29:57 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 25 Apr 2010 10:59:57 +0930 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD12DC0.6080004@matthew.at> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <4BD04752.9050602@jsbc.cc> <4BD12DC0.6080004@matthew.at> Message-ID: <20100425105957.07f6deac@opy.nosense.org> On Thu, 22 Apr 2010 22:18:56 -0700 Matthew Kaufman wrote: > Owen DeLong wrote: > > On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote: > > > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> On 4/22/2010 05:34, Simon Perreault wrote: > >> > >>> On 2010-04-22 07:18, William Herrin wrote: > >>> > >>>> On the other hand, I could swear I've seen a draft where the PC > >>>> picks up random unused addresses in the lower 64 for each new > >>>> outbound connection for anonymity purposes. > >>>> > >>> That's probably RFC 4941. It's available in pretty much all > >>> operating systems. I don't think there's any IPR issue to be afraid > >>> of. > >>> > >>> Simon > >>> > >> I think this is different. They're talking about using a new IPv6 for > >> each connection. RFC4941 just changes it over time IIRC. IMHO that's > >> still pretty good privacy, at least on par with a NATed IPv4 from the > >> outside perspective, especially if you rotated through temporary IPv6s > >> fairly frequently. > >> > > > > 4941 specified changing over time as one possibility. It does allow > > for per flow or any other host based determination of when it needs a new > > address. > > > > Owen > > > > > > > But none of this does what NAT does for a big enterprise, which is to > *hide internal topology*. > Yes, addressing the privacy concerns that come > from using lower-64-bits-derived-from-MAC-address is required, but it is > also necessary (for some organizations) to make it impossible to tell > that this host is on the same subnet as that other host, as that would > expose information like which host you might want to attack in order to > get access to the financial or medical records, as well as whether or > not the executive floor is where these interesting website hits came from. > Are you saying that hiding network topology is going to be your only security measure to protect these systems? Yikes! How about (a) having them authenticate people who try to use them (b) have those people use two factor authentication (c) not co-locating them on the same subnet (with a /48 you could give many of your vital hosts their own individaul subnet) i.e. fundamentally, don't use subnets as a security domain boundary (d) not setting reverse DNS names that give away what the hosts are for (e) not providing them with globally routable addresses in the first place Obscurity is a cheap and easy first level defence in depth measure. However it'll only fool the stupid and mostly uninterested attacker. Any attacker who's determined will easily bypass this obscurity, via malware, key sniffers, guessable passwords, black bag jobs, theats of violence and bribery. If obscurity is such an effective measure why are zebras also able to run fast and kick hard? From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Apr 24 21:01:06 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 25 Apr 2010 11:31:06 +0930 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> Message-ID: <20100425113106.6b12817c@opy.nosense.org> On Thu, 22 Apr 2010 01:48:18 -0400 Christopher Morrow wrote: > On Wed, Apr 21, 2010 at 5:47 PM, Mark Smith > wrote: > > On Wed, 21 Apr 2010 09:25:46 -0400 > > Christopher Morrow wrote: > > > >> On Wed, Apr 21, 2010 at 1:29 AM, Owen DeLong wrote: > >> > While I think this is an improvement, unless the distribution of ULA-C is no cheaper > >> > and no easier to get than GUA, I still think there is reason to believe that it is likely > >> > ULA-C will become de facto GUA over the long term. > >> > > >> > As such, I still think the current draft is a bad idea absent appropriate protections in > >> > RIR policy. > >> > >> I agree with owen, mostly... except I think we should just push RIR's > >> to make GUA accessible to folks that need ipv6 adress space, > >> regardless of connectiivty to thegreater 'internet' (for some > >> definition of that thing). > >> > >> ULA of all types causes headaches on hosts, routers, etc. There is no > >> reason to go down that road, just use GUA (Globally Unique Addresses). > >> > > > > So what happens when you change providers? How are you going to keep > > using globals that now aren't yours? > > use pi space, request it from your local friendly RIR. > I was hoping that wasn't going to be your answer. So do you expect every residential customer to get a PI from an RIR? Here's the scenario: I'm a typical, fairly near future residential customer. I have a NAS that I have movies stored on. My ISP delegates an IPv6 prefix to me with a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes (in my personal opinion, thats too small, but it's the ISP's address space, so I have to accept the lifetimes they give me). I start watching a 2 hour movie, delivered from my NAS to my TV over IPv6, using the GUA addresses (because you're saying I don't ULAs). 5 minutes into the movie, my Internet drops out. 1 hour, 35 minutes into movie, the movies drops out, because the IPv6 addresses used to deliver it can't be used anymore. Is that an acceptable customer networking experience? It won't happen in IPv4, because customers typically have stable RFC1918 addresses. It is unacceptable that it should happen in IPv6, yet you can't expect residential customers to pay RIR fees to get PI address space - and should that even happen, when are we going to have carrier routers that can route 500 Million (my very much rough estimate of houses in the world) routes? The majority of Internet connections are residential. "Enterprise solutions", like PI and RIR fees, aren't just feasible for the majority of the Internet. > > I'm also curious about these headaches. What are they? > > do I use that ula-* address to talk to someone or another GUA address? > how do I decide? what about to business partners? That's why there are source address selection rules in IPv6, that factor in destination address types. > > one address... much simpler, much less to screw up. > I'm all for simplicity. Unfortunately however, to overcome a problem, you usually have to add something, and adding something usually adds complexity. The key goal is to minimise the additional complexity as much as possible, without loosing the benefit. Networks need stable addressing, that is independent of the address space their Internet transit provider loans them. That allows them to change transit providers without disrupting their internal network. In IPv4, RFC1918 gives them that address stability, but then thrusts upon them the issues that NAT and duplicate/overlapping addressing creates. So the goal is: - stable addressing, independent of the stability of your transit provider's addresses that they temporarily loan to you - globally unique, or unique enough that collisions are very unlikely to occur, should you wish to permanently or temporarily interconnect domains (e.g. VPN) - user generated, so there is no cost or need to interact with a central authority and as IPv6 has formalised the support of interfaces having multiple addresses, ULAs suit those requirements. > -chris > > > > >> -Chris > >> > > From stb at lassitu.de Sun Apr 25 01:50:21 2010 From: stb at lassitu.de (Stefan Bethke) Date: Sun, 25 Apr 2010 08:50:21 +0200 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100425105957.07f6deac@opy.nosense.org> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <4BD04752.9050602@jsbc.cc> <4BD12DC0.6080004@matthew.at> <20100425105957.07f6deac@opy.nosense.org> Message-ID: <61676947-5DF0-467A-B75F-2893D59B85E4@lassitu.de> Am 25.04.2010 um 03:29 schrieb Mark Smith: > If obscurity is such an effective measure why are zebras also able to > run fast and kick hard? Because the stripes hide them from the flies, not the lions. http://en.wikipedia.org/wiki/Zebra#cite_note-5 -- Stefan Bethke Fon +49 151 14070811 From mehmet at icann.org Sun Apr 25 07:46:40 2010 From: mehmet at icann.org (Mehmet Akcin) Date: Sun, 25 Apr 2010 05:46:40 -0700 Subject: South Africa network issues Message-ID: Anyone experiencing connectivity problems to South African networks at this moment? A fellow colleague informed SEACOM cable which is serving east Africa seems to be down. Let me know if you have more information on this subject. Mehmet From nick at foobar.org Sun Apr 25 07:56:08 2010 From: nick at foobar.org (Nick Hilliard) Date: Sun, 25 Apr 2010 13:56:08 +0100 Subject: South Africa network issues In-Reply-To: References: Message-ID: <4BD43BE8.7000403@foobar.org> On 25/04/2010 13:46, Mehmet Akcin wrote: > Anyone experiencing connectivity problems to South African networks at this > moment? A fellow colleague informed SEACOM cable which is serving east > Africa seems to be down. > > Let me know if you have more information on this subject. The problem may be related to this: http://www.seacom.mu/news/news_details.asp?iID=129 Nick From arnold at nipper.de Sun Apr 25 08:03:27 2010 From: arnold at nipper.de (Arnold Nipper) Date: Sun, 25 Apr 2010 15:03:27 +0200 Subject: South Africa network issues In-Reply-To: References: Message-ID: <4BD43D9F.4030303@nipper.de> On 25.04.2010 14:46 Mehmet Akcin wrote > Anyone experiencing connectivity problems to South African networks at this > moment? A fellow colleague informed SEACOM cable which is serving east > Africa seems to be down. > > Let me know if you have more information on this subject. > gone? (server1:2010 122 )date -u Sun Apr 25 13:02:02 UTC 2010 (server1:2010 123 )fping -q -c5 symmetria.tenet.ac.za symmetria.tenet.ac.za : xmt/rcv/%loss = 5/4/20%, min/avg/max = 1050/1058/1068 Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From mehmet at icann.org Sun Apr 25 08:18:08 2010 From: mehmet at icann.org (Mehmet Akcin) Date: Sun, 25 Apr 2010 06:18:08 -0700 Subject: South Africa network issues In-Reply-To: <4BD43BE8.7000403@foobar.org> Message-ID: http://www.tm.com.my/about-tm/media-centre/announcements/Pages/INTERNETSERVI CESDISRUPTIONDUETOCABLEWORKSONSMW4.aspx I think this might be another factor. Mehmet On 4/25/10 5:56 AM, "Nick Hilliard" wrote: > On 25/04/2010 13:46, Mehmet Akcin wrote: >> Anyone experiencing connectivity problems to South African networks at this >> moment? A fellow colleague informed SEACOM cable which is serving east >> Africa seems to be down. >> >> Let me know if you have more information on this subject. > > The problem may be related to this: > > http://www.seacom.mu/news/news_details.asp?iID=129 > > Nick > From owen at delong.com Sun Apr 25 08:54:09 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 25 Apr 2010 06:54:09 -0700 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100425105957.07f6deac@opy.nosense.org> References: <20100421222628.993782B2121@mx5.roble.com> <4A397128-EE16-4279-AB14-CD4D68C57517@delong.com> <4BD0424C.8090000@viagenie.ca> <4BD04752.9050602@jsbc.cc> <4BD12DC0.6080004@matthew.at> <20100425105957.07f6deac@opy.nosense.org> Message-ID: On Apr 24, 2010, at 6:29 PM, Mark Smith wrote: > On Thu, 22 Apr 2010 22:18:56 -0700 > Matthew Kaufman wrote: > >> Owen DeLong wrote: >>> On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote: >>> >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 4/22/2010 05:34, Simon Perreault wrote: >>>> >>>>> On 2010-04-22 07:18, William Herrin wrote: >>>>> >>>>>> On the other hand, I could swear I've seen a draft where the PC >>>>>> picks up random unused addresses in the lower 64 for each new >>>>>> outbound connection for anonymity purposes. >>>>>> >>>>> That's probably RFC 4941. It's available in pretty much all >>>>> operating systems. I don't think there's any IPR issue to be afraid >>>>> of. >>>>> >>>>> Simon >>>>> >>>> I think this is different. They're talking about using a new IPv6 for >>>> each connection. RFC4941 just changes it over time IIRC. IMHO that's >>>> still pretty good privacy, at least on par with a NATed IPv4 from the >>>> outside perspective, especially if you rotated through temporary IPv6s >>>> fairly frequently. >>>> >>> >>> 4941 specified changing over time as one possibility. It does allow >>> for per flow or any other host based determination of when it needs a new >>> address. >>> >>> Owen >>> >>> >>> >> But none of this does what NAT does for a big enterprise, which is to >> *hide internal topology*. >> Yes, addressing the privacy concerns that come >> from using lower-64-bits-derived-from-MAC-address is required, but it is >> also necessary (for some organizations) to make it impossible to tell >> that this host is on the same subnet as that other host, as that would >> expose information like which host you might want to attack in order to >> get access to the financial or medical records, as well as whether or >> not the executive floor is where these interesting website hits came from. >> > > Are you saying that hiding network topology is going to be your only > security measure to protect these systems? Yikes! > I doubt that's what he is saying, but, I do think he over-emphasizes the value of obscurity... > How about > > (a) having them authenticate people who try to use them > (b) have those people use two factor authentication > (c) not co-locating them on the same subnet (with a /48 you could give > many of your vital hosts their own individaul subnet) i.e. > fundamentally, don't use subnets as a security domain boundary > (d) not setting reverse DNS names that give away what the hosts are for > (e) not providing them with globally routable addresses in the first > place > None of these are mutually exclusive with obscurity. > Obscurity is a cheap and easy first level defence in depth measure. > However it'll only fool the stupid and mostly uninterested attacker. > Any attacker who's determined will easily bypass this obscurity, via > malware, key sniffers, guessable passwords, black bag jobs, theats of > violence and bribery. And, to follow that up, any attacker who would be somehow blocked or even impeded by this obscurity today would be just as effectively blocked by the other measures above (if not more so) without such obscurity. Obscurity is of very limited value to security. If there is a significant cost to it (and there is a significant cost to NAT), then, the value proposition is easily lost. Owen From owen at delong.com Sun Apr 25 08:58:19 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 25 Apr 2010 06:58:19 -0700 Subject: Connectivity to an IPv6-only site In-Reply-To: <87vdbg4a4o.fsf@doris.mad.asaurus.net> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> <538D27E2-4771-4420-821D-BA8879B6822A@delong.com> <5598.1272031635@localhost> <87vdbg4a4o.fsf@doris.mad.asaurus.net> Message-ID: On Apr 24, 2010, at 6:02 PM, Kevin Buhr wrote: > Valdis.Kletnieks at vt.edu writes: >> >> Ours are currently intentionally configured to not issue queries over IPv6, >> because at one time, there were *so many* sites that listed unreachable quad-A >> NS records. Our DNS guy is more than willing to revisit that config switch. >> >> Anybody have some statistics on what the current situation is? > > I just dredged a list of 570 one, two, and three-dot domains from a > mailing list (a bunch of recent messages on debian-user). Digging > them gave 919 unique nameserver domain names, and digging those gave > 119 AAAA addresses. Of these, 106 responded to a DNS query (for the > nameserver's own AAAA address) in some fashion, and 13 didn't. > > Of the 13, 5 were cogentco.com DNS servers and unreachable over my HE > tunnel thanks to ongoing peering disputes. > Yeah, sorry about that, we really are trying to resolve this. We're here, we'll peer. It'd be nice if Cogent would, too. We really have done everything we can think of to get Cogent to peer. We even baked them a really nice cake. If you are a Cogent customer, feel free to ask them why they won't peer IPv6 with HE. > In all cases, the nameservers with AAAA addresses had A addresses as > well. Owen From tony at hoyle.me.uk Sun Apr 25 10:17:21 2010 From: tony at hoyle.me.uk (Tony Hoyle) Date: Sun, 25 Apr 2010 16:17:21 +0100 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <20100425113106.6b12817c@opy.nosense.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> Message-ID: <4BD45D01.8060501@hoyle.me.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25/04/2010 03:01, Mark Smith wrote: > I'm a typical, fairly near future residential customer. I have a NAS > that I have movies stored on. My ISP delegates an IPv6 prefix to me with > a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes What ISP would put a 'lifetime' on your ipv6 prefix? That seems insane to me... they should give you a /48 and be done with it. Even the free tunnel brokers do that. But then I never understood dynamic ipv4 either.... Tony -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL1F0BAAoJEJ1qCQ6ePCDUKnkH/iwae1SessBxQ708eLennoZV Zmy+2jSABgQtY+GTpqkXzn/Tr5tXWJfq4+ONx4N0SfA6e2asKkUtf6+/ZzWx/gUA EmCQ966HIMdJoCGeFc4snCMm6vOe+fqRcZA0BqGbF6bEkctuyEETVlr6jDfFXqcA oFwibApR/GmBOd/1IfMh3dNjHEt4XtfoL9BUqOUiPzfI2+xByaHfh3I04yskFZkf 7EDW+JVbMA9w9Hy6M1nsggHijETpBKiDsHusrFhRaq9h6NdL8Ypf0D4+DIluGuOR zuAcrOCu1dd3Y4fLkOwej7z1C5QDMLluToUQhCljua6agOhzJKsh5u4Acfc0Wik= =NtLo -----END PGP SIGNATURE----- From LarrySheldon at cox.net Sun Apr 25 10:30:32 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 25 Apr 2010 10:30:32 -0500 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <4BD45D01.8060501@hoyle.me.uk> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> Message-ID: <4BD46018.30409@cox.net> On 4/25/2010 10:17, Tony Hoyle wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 25/04/2010 03:01, Mark Smith wrote: >> I'm a typical, fairly near future residential customer. I have a NAS >> that I have movies stored on. My ISP delegates an IPv6 prefix to me with >> a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes > > What ISP would put a 'lifetime' on your ipv6 prefix? That seems insane > to me... they should give you a /48 and be done with it. Even the free > tunnel brokers do that. > > But then I never understood dynamic ipv4 either.... +1 > > Tony > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.12 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJL1F0BAAoJEJ1qCQ6ePCDUKnkH/iwae1SessBxQ708eLennoZV > Zmy+2jSABgQtY+GTpqkXzn/Tr5tXWJfq4+ONx4N0SfA6e2asKkUtf6+/ZzWx/gUA > EmCQ966HIMdJoCGeFc4snCMm6vOe+fqRcZA0BqGbF6bEkctuyEETVlr6jDfFXqcA > oFwibApR/GmBOd/1IfMh3dNjHEt4XtfoL9BUqOUiPzfI2+xByaHfh3I04yskFZkf > 7EDW+JVbMA9w9Hy6M1nsggHijETpBKiDsHusrFhRaq9h6NdL8Ypf0D4+DIluGuOR > zuAcrOCu1dd3Y4fLkOwej7z1C5QDMLluToUQhCljua6agOhzJKsh5u4Acfc0Wik= > =NtLo > -----END PGP SIGNATURE----- > > -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From owen at delong.com Sun Apr 25 10:48:39 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 25 Apr 2010 08:48:39 -0700 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <4BD45D01.8060501@hoyle.me.uk> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> Message-ID: <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> On Apr 25, 2010, at 8:17 AM, Tony Hoyle wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 25/04/2010 03:01, Mark Smith wrote: >> I'm a typical, fairly near future residential customer. I have a NAS >> that I have movies stored on. My ISP delegates an IPv6 prefix to me with >> a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes > > What ISP would put a 'lifetime' on your ipv6 prefix? That seems insane > to me... they should give you a /48 and be done with it. Even the free > tunnel brokers do that. > > But then I never understood dynamic ipv4 either.... > If they are using DHCP-PD, then, it comes with a lifetime whether it is static or not. The reality is that unless they need to renumber you, you'll probably get a new RA with the 60/90 minute lifetimes specified each time RAs are sent and your counters will all get reset to 60/90 for the foreseeable future. The preferred and valid lifetimes aren't limitations, they're minimums. The prefix should be yours and should be functional for you for AT LEAST the valid lifetime. Owen From sthaug at nethelp.no Sun Apr 25 11:11:22 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sun, 25 Apr 2010 18:11:22 +0200 (CEST) Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <4BD46018.30409@cox.net> References: <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <4BD46018.30409@cox.net> Message-ID: <20100425.181122.71164896.sthaug@nethelp.no> > What ISP would put a 'lifetime' on your ipv6 prefix? That seems insane > to me... they should give you a /48 and be done with it. Even the free > tunnel brokers do that. > > But then I never understood dynamic ipv4 either.... Dynamic IPv4 isn't too difficult to understand. There are two main arguments: - Dynamic addresses is a way to differentiate residential customers (who pay less) from business customers (who pay more). - Dynamic addresses makes it much easier to handle customers in "bulk". You can have *one* standardized form of DNS info (forward/reverse), no customer defined DNS at all. You can easily move customers to a new aggregation box when the current box is reaching max capacity - just remember to lower your DHCP lease time beforehand. You may not need to alert customers individually as long as work is done within your well defined service windows. etc etc. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From randy at psg.com Sun Apr 25 11:56:59 2010 From: randy at psg.com (Randy Bush) Date: Sun, 25 Apr 2010 09:56:59 -0700 Subject: South Africa network issues In-Reply-To: References: Message-ID: we know the prefix for afnog.org was not being announced for about 16 hours. no post mortem yet. randy From jfesler at gigo.com Sun Apr 25 12:11:26 2010 From: jfesler at gigo.com (Jason Fesler) Date: Sun, 25 Apr 2010 10:11:26 -0700 (PDT) Subject: Connectivity to an IPv6-only site In-Reply-To: <5EC8E91C-141A-4BB4-82BC-D8E9AEA5A1DD@nosignal.org> References: <4BD1432F.4070406@ibctech.ca> <5EC8E91C-141A-4BB4-82BC-D8E9AEA5A1DD@nosignal.org> Message-ID: > Its a shame there is not a pair of images on this site - one originated > from a v4 only box, one a v6 only box. The img src= could point to the I've been working on something in this direction this past week, that is primarilly for user facing debugging purposes (versus for a content provider). http://test-ipv6.com will tell the user what to expect, after having them try a combination of image fetches (ipv4, ipv6, dual stack, ipv4 literal, ipv6 literal). It does each set of images 2-3 times (minimum is 2; a third pass is done if they go quick enough) and gets the "best" time of each type of fetch. Based on the successes and failures, and the times, it tries to give a straight-English explanation to the end user on what the future internet might look for them, based on their *current* internet service / OS / browser. Lastly, it posts the results back to my server, along with the user agent string, in case there are any trends that can be learned. On my todo list is to have it detect the case where the user timed out trying to reach the IPv6 and dual stack names; and ask the user for more details (ie, netstat -nr and ifconfig/ipconfig). Feedback welcome, preferably off-list. If there's a desire for me to summarize, or anything earth shattering, I'll followup on-list. I'm especially interested in people who've allowed utorrent to enable ipv6 to send me their results. :) From richard.barnes at gmail.com Sun Apr 25 12:21:16 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Sun, 25 Apr 2010 13:21:16 -0400 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> Message-ID: Moreover, the general point stands that Mark's problem is one of bad ISP decisions, not anything different between IPv4/RFC1918 and IPv6. On Sun, Apr 25, 2010 at 11:48 AM, Owen DeLong wrote: > > On Apr 25, 2010, at 8:17 AM, Tony Hoyle wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 25/04/2010 03:01, Mark Smith wrote: >>> I'm a typical, fairly near future residential customer. I have a NAS >>> that I have movies stored on. My ISP delegates an IPv6 prefix to me with >>> a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes >> >> What ISP would put a 'lifetime' on your ipv6 prefix? ?That seems insane >> to me... they should give you a /48 and be done with it. ?Even the free >> tunnel brokers do that. >> >> But then I never understood dynamic ipv4 either.... >> > If they are using DHCP-PD, then, it comes with a lifetime whether it is > static or not. > > The reality is that unless they need to renumber you, you'll probably get > a new RA with the 60/90 minute lifetimes specified each time RAs are > sent and your counters will all get reset to 60/90 for the foreseeable > future. ?The preferred and valid lifetimes aren't limitations, they're > minimums. ?The prefix should be yours and should be functional for > you for AT LEAST the valid lifetime. > > Owen > > > From rmacharia at gmail.com Sun Apr 25 13:55:07 2010 From: rmacharia at gmail.com (Raymond Macharia) Date: Sun, 25 Apr 2010 21:55:07 +0300 Subject: South Africa network issues In-Reply-To: References: Message-ID: Cable fault repairs on SMW4 which currently seacom uses to haul traffic to europe and onto the rest of the world. Below is subject for email sent by my upstream provider. Latest information is that it will take about 3 days if the weather remains friendly. "SMW4 Seg4.1(Alexandria towards west) cable fault Urgent repairactivity" Regards Raymond Macharia On 4/25/10, Randy Bush wrote: > we know the prefix for afnog.org was not being announced for about 16 > hours. no post mortem yet. > > randy > > -- Sent from my mobile device Raymond Macharia From owen at delong.com Sun Apr 25 14:56:41 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 25 Apr 2010 12:56:41 -0700 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <20100425.181122.71164896.sthaug@nethelp.no> References: <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <4BD46018.30409@cox.net> <20100425.181122.71164896.sthaug@nethelp.no> Message-ID: <09627F14-557C-4FA0-8B52-BD1A444B18D5@delong.com> On Apr 25, 2010, at 9:11 AM, sthaug at nethelp.no wrote: >> What ISP would put a 'lifetime' on your ipv6 prefix? That seems insane >> to me... they should give you a /48 and be done with it. Even the free >> tunnel brokers do that. >> >> But then I never understood dynamic ipv4 either.... > > Dynamic IPv4 isn't too difficult to understand. There are two main > arguments: > > - Dynamic addresses is a way to differentiate residential customers > (who pay less) from business customers (who pay more). > Which is both specious and obnoxious. Given a choice between a provider which does this and one who does not, I will always choose the one that does not. Unfortunately, there is no PON vendor in my area, so I live with com cast business (on a dynamic IP because I refuse to pay their absurd mark-up on IP addresses). Given a PON vendor in my neighborhood, I'd drop Comcast in a heartbeat. > - Dynamic addresses makes it much easier to handle customers in "bulk". > You can have *one* standardized form of DNS info (forward/reverse), no > customer defined DNS at all. You can easily move customers to a new > aggregation box when the current box is reaching max capacity - just > remember to lower your DHCP lease time beforehand. You may not need to > alert customers individually as long as work is done within your well > defined service windows. etc etc. > This is true. However, I'd be willing to pay some amount to cover this difference. Interestingly, Comcast is the only provider where I've been unable to get a static address on a residential plan at any price. They're also the only provider that has tried to charge more for a static on business service. > Steinar Haug, Nethelp consulting, sthaug at nethelp.no Owen From sthaug at nethelp.no Sun Apr 25 15:27:32 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sun, 25 Apr 2010 22:27:32 +0200 (CEST) Subject: In-Reply-To: <09627F14-557C-4FA0-8B52-BD1A444B18D5@delong.com> References: <4BD46018.30409@cox.net> <20100425.181122.71164896.sthaug@nethelp.no> <09627F14-557C-4FA0-8B52-BD1A444B18D5@delong.com> Message-ID: <20100425.222732.104106150.sthaug@nethelp.no> > > - Dynamic addresses is a way to differentiate residential customers > > (who pay less) from business customers (who pay more). > > > Which is both specious and obnoxious. It is a business choice, which you may or may not agree with. > Given a choice between a provider which does this and one who does not, I will always choose the one that does not. Unfortunately, there is no PON vendor in my area, so I live with com cast business (on a dynamic IP because I refuse to pay their absurd mark-up on IP addresses). Given a PON vendor in my neighborhood, I'd drop Comcast in a heartbeat. You can obviously vote with your wallet. In a market with rather thin margins, where most residential customers are happy with dynamic addresses, I find it entirely unsurprising that some companies would like to differentiate between customers this way. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From LarrySheldon at cox.net Sun Apr 25 16:06:16 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 25 Apr 2010 16:06:16 -0500 Subject: DHCP Use (was Re: ) In-Reply-To: <20100425.222732.104106150.sthaug@nethelp.no> References: <4BD46018.30409@cox.net> <20100425.181122.71164896.sthaug@nethelp.no> <09627F14-557C-4FA0-8B52-BD1A444B18D5@delong.com> <20100425.222732.104106150.sthaug@nethelp.no> Message-ID: <4BD4AEC8.7010002@cox.net> On 4/25/2010 15:27, sthaug at nethelp.no wrote: >>> - Dynamic addresses is a way to differentiate residential customers >>> (who pay less) from business customers (who pay more). >>> >> Which is both specious and obnoxious. > > It is a business choice, which you may or may not agree with. > >> Given a choice between a provider which does this and one who does not, I will always choose the one that does not. Unfortunately, there is no PON vendor in my area, so I live with com cast business (on a dynamic IP because I refuse to pay their absurd mark-up on IP addresses). Given a PON vendor in my neighborhood, I'd drop Comcast in a heartbeat. > > You can obviously vote with your wallet. In a market with rather thin > margins, where most residential customers are happy with dynamic > addresses, I find it entirely unsurprising that some companies would > like to differentiate between customers this way. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no The whole idea that DHCP should only be used for (and is absolute proof of the status of) despised-class customers is just nuts. When I was a network administrator we were working to convert all hosts to DHCP to improve the service to everybody. There were some hosts that were not bright enough to use DHCP (I don't remember an example, but I do remember there were some), it seems like there were some where we decided it was a Bad Idea (see parenthetical material above), and some that were not under our administrative control who believed that to use DHCP was an admission of inferior status. We had a lot of hosts that got their "permanently assigned", "static" address via DHCP. The big benefits came from being able to change name-server addresses, default-gateway addresses (and even netmask settings although that turned out not to work as well as we had hoped due to poor planning on our part). And of course, shortening the lease-life when changes were pending was useful in the same way that changing DNS TTL is. > > -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Apr 25 17:39:58 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 26 Apr 2010 08:09:58 +0930 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <09627F14-557C-4FA0-8B52-BD1A444B18D5@delong.com> References: <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <4BD46018.30409@cox.net> <20100425.181122.71164896.sthaug@nethelp.no> <09627F14-557C-4FA0-8B52-BD1A444B18D5@delong.com> Message-ID: <20100426080958.7d5ae9e4@opy.nosense.org> On Sun, 25 Apr 2010 12:56:41 -0700 Owen DeLong wrote: > > > > On Apr 25, 2010, at 9:11 AM, sthaug at nethelp.no wrote: > > >> What ISP would put a 'lifetime' on your ipv6 prefix? That seems insane > >> to me... they should give you a /48 and be done with it. Even the free > >> tunnel brokers do that. > >> > >> But then I never understood dynamic ipv4 either.... > > > > Dynamic IPv4 isn't too difficult to understand. There are two main > > arguments: > > > > - Dynamic addresses is a way to differentiate residential customers > > (who pay less) from business customers (who pay more). > > > Which is both specious and obnoxious. > No necessarily. There is an increased cost with static addresses. When a (typically business) customer pays for one, you are selling the ability to have that /32 or /32 + subnet regardless of where they connect to your infrastructure. For example, if you have multiple redundant BRASes available, it doesn't matter which one they connect to, they'll still get the same address. If they happen to connect to your 3G infrastructure instead, they'll get it there too. There are some regional aggregation opportunities with that model, but they aren't absolute. If they move out of the region in which you've given the original assignment, the static addess needs to follow them. So the customer with a static IP address(es) is basically paying for their own route table slot in your network, and the corresponding processing cost involved in maintaining that route slot i.e. convergence. In Australia, as the country's business centres are fairly sparse, that means a route table entry in every router in the continent. If, other hand, you're taking about a static address that doesn't change every time to connect/disconnect, but would change if you move house (assuming ADSL/cable), then that is a much more tractable problem and a different one to true static addresses. > Given a choice between a provider which does this and one who does not, I will always choose the one that does not. Unfortunately, there is no PON vendor in my area, so I live with com cast business (on a dynamic IP because I refuse to pay their absurd mark-up on IP addresses). Given a PON vendor in my neighborhood, I'd drop Comcast in a heartbeat. > > > - Dynamic addresses makes it much easier to handle customers in "bulk". > > You can have *one* standardized form of DNS info (forward/reverse), no > > customer defined DNS at all. You can easily move customers to a new > > aggregation box when the current box is reaching max capacity - just > > remember to lower your DHCP lease time beforehand. You may not need to > > alert customers individually as long as work is done within your well > > defined service windows. etc etc. > > > This is true. However, I'd be willing to pay some amount to cover this difference. Interestingly, Comcast is the only provider where I've been unable to get a static address on a residential plan at any price. They're also the only provider that has tried to charge more for a static on business service. > > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > > Owen > > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Apr 25 17:50:33 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 26 Apr 2010 08:20:33 +0930 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> Message-ID: <20100426082033.335e28da@opy.nosense.org> On Sun, 25 Apr 2010 13:21:16 -0400 Richard Barnes wrote: > Moreover, the general point stands that Mark's problem is one of bad > ISP decisions, not anything different between IPv4/RFC1918 and IPv6. > My example, although a bit convoluted to demonstrate a point, is about robustness against Internet link failure. I don't think people's internal connectivity should be dependent on their Internet link being available and being assigned global address space. That's what the global only people are saying. (how is the customer going to access the CPE webserver to enter ISP login details when they get the CPE out of the box, if hasn't got address space because it hasn't connected to the ISP ...) > > > On Sun, Apr 25, 2010 at 11:48 AM, Owen DeLong wrote: > > > > On Apr 25, 2010, at 8:17 AM, Tony Hoyle wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> On 25/04/2010 03:01, Mark Smith wrote: > >>> I'm a typical, fairly near future residential customer. I have a NAS > >>> that I have movies stored on. My ISP delegates an IPv6 prefix to me with > >>> a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes > >> > >> What ISP would put a 'lifetime' on your ipv6 prefix? ?That seems insane > >> to me... they should give you a /48 and be done with it. ?Even the free > >> tunnel brokers do that. > >> > >> But then I never understood dynamic ipv4 either.... > >> > > If they are using DHCP-PD, then, it comes with a lifetime whether it is > > static or not. > > > > The reality is that unless they need to renumber you, you'll probably get > > a new RA with the 60/90 minute lifetimes specified each time RAs are > > sent and your counters will all get reset to 60/90 for the foreseeable > > future. ?The preferred and valid lifetimes aren't limitations, they're > > minimums. ?The prefix should be yours and should be functional for > > you for AT LEAST the valid lifetime. > > > > Owen > > > > > > > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Apr 25 17:53:17 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 26 Apr 2010 08:23:17 +0930 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <4BD45D01.8060501@hoyle.me.uk> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> Message-ID: <20100426082317.1be2a50d@opy.nosense.org> On Sun, 25 Apr 2010 16:17:21 +0100 Tony Hoyle wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 25/04/2010 03:01, Mark Smith wrote: > > I'm a typical, fairly near future residential customer. I have a NAS > > that I have movies stored on. My ISP delegates an IPv6 prefix to me with > > a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes > > What ISP would put a 'lifetime' on your ipv6 prefix? Because they loan it to you while you are their customer. Unless you get PI, you don't 'own' your addresses, so you can't take them with you when you change ISPs. In IPv4 a lifetime is implicit, which might be as long/short as while your current connection is up, in IPv6 it is explicit. (other people who've responded have provided other valid reasons, so I won't repeat them) > That seems insane > to me... they should give you a /48 and be done with it. Even the free > tunnel brokers do that. > No they don't. They set a lifetime too, and if you change tunnel broker, you don't get to keep using the same addresses. > But then I never understood dynamic ipv4 either.... > > Tony > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.12 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJL1F0BAAoJEJ1qCQ6ePCDUKnkH/iwae1SessBxQ708eLennoZV > Zmy+2jSABgQtY+GTpqkXzn/Tr5tXWJfq4+ONx4N0SfA6e2asKkUtf6+/ZzWx/gUA > EmCQ966HIMdJoCGeFc4snCMm6vOe+fqRcZA0BqGbF6bEkctuyEETVlr6jDfFXqcA > oFwibApR/GmBOd/1IfMh3dNjHEt4XtfoL9BUqOUiPzfI2+xByaHfh3I04yskFZkf > 7EDW+JVbMA9w9Hy6M1nsggHijETpBKiDsHusrFhRaq9h6NdL8Ypf0D4+DIluGuOR > zuAcrOCu1dd3Y4fLkOwej7z1C5QDMLluToUQhCljua6agOhzJKsh5u4Acfc0Wik= > =NtLo > -----END PGP SIGNATURE----- > From marka at isc.org Sun Apr 25 18:15:35 2010 From: marka at isc.org (Mark Andrews) Date: Mon, 26 Apr 2010 09:15:35 +1000 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: Your message of "Sun, 25 Apr 2010 13:21:16 -0400." References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> Message-ID: <201004252315.o3PNFZw7098460@drugs.dv.isc.org> In message , Richard Barnes writes: > Moreover, the general point stands that Mark's problem is one of bad > ISP decisions, not anything different between IPv4/RFC1918 and IPv6. Actually one needs to deploy a ULA or have PI addresses to handle external link down events that are long enough to cause any provider supplied addresses to expire. With address selection rules setup so that you prefer ULA over non-ULA for intra site it just works. For some services you only advertise a ULA address even if the host machine has both. I was disscussing how a CPE device should be advertising DNS severs in DHCP and decided that adverising ULA addresses for the DNS proxy/forewarding server was the best way to do this. Mark > On Sun, Apr 25, 2010 at 11:48 AM, Owen DeLong wrote: > > > > On Apr 25, 2010, at 8:17 AM, Tony Hoyle wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> On 25/04/2010 03:01, Mark Smith wrote: > >>> I'm a typical, fairly near future residential customer. I have a NAS > >>> that I have movies stored on. My ISP delegates an IPv6 prefix to me wit= > h > >>> a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes > >> > >> What ISP would put a 'lifetime' on your ipv6 prefix? =A0That seems insan= > e > >> to me... they should give you a /48 and be done with it. =A0Even the fre= > e > >> tunnel brokers do that. > >> > >> But then I never understood dynamic ipv4 either.... > >> > > If they are using DHCP-PD, then, it comes with a lifetime whether it is > > static or not. > > > > The reality is that unless they need to renumber you, you'll probably get > > a new RA with the 60/90 minute lifetimes specified each time RAs are > > sent and your counters will all get reset to 60/90 for the foreseeable > > future. =A0The preferred and valid lifetimes aren't limitations, they're > > minimums. =A0The prefix should be yours and should be functional for > > you for AT LEAST the valid lifetime. > > > > Owen > > > > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mpalmer at hezmatt.org Sun Apr 25 18:32:30 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Mon, 26 Apr 2010 09:32:30 +1000 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <20100426082033.335e28da@opy.nosense.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> Message-ID: <20100425233230.GX20959@hezmatt.org> On Mon, Apr 26, 2010 at 08:20:33AM +0930, Mark Smith wrote: > On Sun, 25 Apr 2010 13:21:16 -0400 > Richard Barnes wrote: > > > Moreover, the general point stands that Mark's problem is one of bad > > ISP decisions, not anything different between IPv4/RFC1918 and IPv6. > > My example, although a bit convoluted to demonstrate a point, is about > robustness against Internet link failure. I don't think people's > internal connectivity should be dependent on their Internet link being > available and being assigned global address space. That's what the > global only people are saying. > > (how is the customer going to access the CPE webserver to enter ISP > login details when they get the CPE out of the box, if hasn't got > address space because it hasn't connected to the ISP ...) I've been using IPv6 for about 18 seconds, and even *I* know the answer to that one -- the link-local address. - Matt -- "You are capable, creative, competent, careful. Prove it." -- Seen in a fortune cookie From tony at hoyle.me.uk Sun Apr 25 18:33:14 2010 From: tony at hoyle.me.uk (Tony Hoyle) Date: Mon, 26 Apr 2010 00:33:14 +0100 Subject: DHCP Use (was Re: ) In-Reply-To: <4BD4AEC8.7010002@cox.net> References: <4BD46018.30409@cox.net> <20100425.181122.71164896.sthaug@nethelp.no> <09627F14-557C-4FA0-8B52-BD1A444B18D5@delong.com> <20100425.222732.104106150.sthaug@nethelp.no> <4BD4AEC8.7010002@cox.net> Message-ID: <4BD4D13A.3060106@hoyle.me.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25/04/2010 22:06, Larry Sheldon wrote: > The whole idea that DHCP should only be used for (and is absolute proof > of the status of) despised-class customers is just nuts. > I've never seen DHCP used on residential DSL circuits.. it's all PPP (oA mostly, and oE if you want) in this country (which the telco picks up and sends as L2TP to the DSL provider). I get alocated my /26 and it doesn't matter which LNS I connect to or how I get there (indeed I can talk L2TP directly to the provider to connect over 3G etc.). We do have providers that charge extra for static IP (although it's not as common as it used to be). I just wouldn't pick one that did so as it's not justifiable IMO (my current one gives me as many as I can justify at no cost). Tony -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL1NE6AAoJEJ1qCQ6ePCDUJt4H/inX9ghqyWRnpFNb3s0PRuao bHkU58vpJD3IRiSs69golNrAa9+iZTlfX2wymFedRPoVepFsfAG39rg3I6THj224 LvPgHK1MJWsHjRQedEPdoKGWIUAsPOqbhe7nzlNprZbBcR9tjaf+DlvHA6CJBjPL TqVQTfHnxd39OInwka+ef7bRmSx4bIP/ANTvUy5wKjTBrTZV7s4lR4muTh0VoPaF rJq6VEOz28a/BiwpqqD3Jy5X1n2nAqMb8RJqz/PLLtFjAnBPgqr3a5yaHxWaZ5aH 1WvWPqiLqmR+gNEFX1k7F1Yd5G5eaDwiRAEhhhHg4XT6Zc+2BP1QPqEoanbiuFM= =Xoqj -----END PGP SIGNATURE----- From owen at delong.com Sun Apr 25 18:42:31 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 25 Apr 2010 16:42:31 -0700 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <20100426082033.335e28da@opy.nosense.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> Message-ID: On Apr 25, 2010, at 3:50 PM, Mark Smith wrote: > On Sun, 25 Apr 2010 13:21:16 -0400 > Richard Barnes wrote: > >> Moreover, the general point stands that Mark's problem is one of bad >> ISP decisions, not anything different between IPv4/RFC1918 and IPv6. >> > > My example, although a bit convoluted to demonstrate a point, is about > robustness against Internet link failure. I don't think people's > internal connectivity should be dependent on their Internet link being > available and being assigned global address space. That's what the > global only people are saying. > Your internet connectivity, by definition, depends on an internet link being available. No link, no connection. Simple as that. Now, if you're talking about multihoming, I, as one of the global only people, am suggesting that you get your global addresses from ARIN and advertise it to both of your upstreams. I know this is not popular with many of the ISPs out there because there is a cost to that and a scale factor that still has yet to be addressed in the IP routing paradigm. However, I think that will happen anyway. Alternatively, even if you want to do some funky NAT-based solution, there's nothing wrong with using GUA on the internal side of the NAT to your PA prefixes outside. That way, when you get the opportunity to remove that NAT cruft from your environment, you already have usable addresses and you don't have to renumber. > (how is the customer going to access the CPE webserver to enter ISP > login details when they get the CPE out of the box, if hasn't got > address space because it hasn't connected to the ISP ...) That's what Link Local is for. fe80::% For example, if the CPE is connected to the customer's network on eth0 and the CPE mac address is 00:45:4b:b9:02:be, you could go to: http://[fe80::0245:4bff:feb9:02be]%eth0 Owen >> >> >> On Sun, Apr 25, 2010 at 11:48 AM, Owen DeLong wrote: >>> >>> On Apr 25, 2010, at 8:17 AM, Tony Hoyle wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 25/04/2010 03:01, Mark Smith wrote: >>>>> I'm a typical, fairly near future residential customer. I have a NAS >>>>> that I have movies stored on. My ISP delegates an IPv6 prefix to me with >>>>> a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes >>>> >>>> What ISP would put a 'lifetime' on your ipv6 prefix? That seems insane >>>> to me... they should give you a /48 and be done with it. Even the free >>>> tunnel brokers do that. >>>> >>>> But then I never understood dynamic ipv4 either.... >>>> >>> If they are using DHCP-PD, then, it comes with a lifetime whether it is >>> static or not. >>> >>> The reality is that unless they need to renumber you, you'll probably get >>> a new RA with the 60/90 minute lifetimes specified each time RAs are >>> sent and your counters will all get reset to 60/90 for the foreseeable >>> future. The preferred and valid lifetimes aren't limitations, they're >>> minimums. The prefix should be yours and should be functional for >>> you for AT LEAST the valid lifetime. >>> >>> Owen >>> >>> >>> >> From tony at hoyle.me.uk Sun Apr 25 18:46:17 2010 From: tony at hoyle.me.uk (Tony Hoyle) Date: Mon, 26 Apr 2010 00:46:17 +0100 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <20100426082317.1be2a50d@opy.nosense.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <20100426082317.1be2a50d@opy.nosense.org> Message-ID: <4BD4D449.8020804@hoyle.me.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25/04/2010 23:53, Mark Smith wrote: > On Sun, 25 Apr 2010 16:17:21 +0100 > Tony Hoyle wrote: > > On 25/04/2010 03:01, Mark Smith wrote: >>>> I'm a typical, fairly near future residential customer. I have a NAS >>>> that I have movies stored on. My ISP delegates an IPv6 prefix to me with >>>> a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes > > What ISP would put a 'lifetime' on your ipv6 prefix? > >> Because they loan it to you while you are their customer. Unless you >> get PI, you don't 'own' your addresses, so you can't take them with >> you when you change ISPs. In IPv4 a lifetime is implicit, which might be >> as long/short as while your current connection is up, in IPv6 it is >> explicit. > That's not what 'lifetime' means in this discusion. They're talking about v6 addresses changing when you're with the same provider - indeed, when logged into the same link even. That's insane. A change of ISP is a major change. Your ipv4 addresses will change as well if you change ISP. As you say, if you don't want them to change get PI space. v6 and v4 are no different in this respect. Tony -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL1NRJAAoJEJ1qCQ6ePCDUDeQH/07EZ2uBb5E2Is5juO1NCp4S BYl36VnSIwmadVZpQxJ2tmrJB2jKGV2sV4K0hJ/QRHRNK0k0CJv2k/KWPf8sis6p v6bDjnHD1k4bSTxuwEgRbAbPB5uDpRaw7F2ItgdNKGmf8KZh+tCX4uYZ3Pger0Q9 BEE6y/PjDlgk+ZW+BX6Jgp5raBC9gWu0hiFIhiIRXxmUNgKmJpaRsc6DH5jC5Hch BhrDxvHZCMNpG2KH32w9D955FSHBCt/ih/hNEB36yDTiln4gMx99jKquECeZrujJ zX1+sZ0DtLGR3oFjXyXfVS+8Y13i2fLYfQ1g5l/dhXGGs+Nwwb0ska8K+D5Tza0= =cgpi -----END PGP SIGNATURE----- From tony at hoyle.me.uk Sun Apr 25 18:51:55 2010 From: tony at hoyle.me.uk (Tony Hoyle) Date: Mon, 26 Apr 2010 00:51:55 +0100 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <20100425233230.GX20959@hezmatt.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> <20100425233230.GX20959@hezmatt.org> Message-ID: <4BD4D59B.9070409@hoyle.me.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26/04/2010 00:32, Matthew Palmer wrote: > I've been using IPv6 for about 18 seconds, and even *I* know the answer to > that one -- the link-local address. > It should respond at ff02::2 as well (at least to a ping, so you can get the LL address if you don't know it). Tony -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL1NWbAAoJEJ1qCQ6ePCDU2ScIANFCWKUhc7zfs0ajLL1fkUNe 7DR4LlStfh1XQArQ50eBVmCLpZGrx8bWcluT+PUHSnQve2lLkLKB6MIbrJ4ezc8g sa/hIcpPKioLpAuQr9q3HEPqqiIJ58119wIVGdglWPEeyjlWZih+n6wWoZ4WVeFK aKXXdhE5s8QhZeUEzDioktxl9r1wRQK+ecFYWWF8K9sHd4ePwViyfsk7xnLhaWxp /98BlYGeKMgMfLGH1aNxVYwbEM77KOqXcJbN1Gc2QB03wi4RJyw9/45dR+dzeSbn LrbWmulqBi79Jv9InPY6FNqf8RjYspl2a+hXiRLimW2yNcp19W5f9Wrh1/7v6JE= =3opf -----END PGP SIGNATURE----- From LarrySheldon at cox.net Sun Apr 25 18:52:25 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 25 Apr 2010 18:52:25 -0500 Subject: DHCP Use (was Re: ) In-Reply-To: <4BD4D13A.3060106@hoyle.me.uk> References: <4BD46018.30409@cox.net> <20100425.181122.71164896.sthaug@nethelp.no> <09627F14-557C-4FA0-8B52-BD1A444B18D5@delong.com> <20100425.222732.104106150.sthaug@nethelp.no> <4BD4AEC8.7010002@cox.net> <4BD4D13A.3060106@hoyle.me.uk> Message-ID: <4BD4D5B9.6030005@cox.net> On 4/25/2010 18:33, Tony Hoyle wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 25/04/2010 22:06, Larry Sheldon wrote: > >> The whole idea that DHCP should only be used for (and is absolute proof >> of the status of) despised-class customers is just nuts. >> > > I've never seen DHCP used on residential DSL circuits.. it's all PPP (oA > mostly, and oE if you want) in this country (which the telco picks up > and sends as L2TP to the DSL provider). I guess I should have said dhcp instead of DHCP. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From sethm at rollernet.us Sun Apr 25 19:11:38 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 25 Apr 2010 17:11:38 -0700 Subject: DHCP Use (was Re: ) In-Reply-To: <4BD4D13A.3060106@hoyle.me.uk> References: <4BD46018.30409@cox.net> <20100425.181122.71164896.sthaug@nethelp.no> <09627F14-557C-4FA0-8B52-BD1A444B18D5@delong.com> <20100425.222732.104106150.sthaug@nethelp.no> <4BD4AEC8.7010002@cox.net> <4BD4D13A.3060106@hoyle.me.uk> Message-ID: <4BD4DA3A.3090406@rollernet.us> On 4/25/10 4:33 PM, Tony Hoyle wrote: > On 25/04/2010 22:06, Larry Sheldon wrote: > >> The whole idea that DHCP should only be used for (and is absolute proof >> of the status of) despised-class customers is just nuts. > > > I've never seen DHCP used on residential DSL circuits.. it's all PPP (oA > mostly, and oE if you want) in this country (which the telco picks up > and sends as L2TP to the DSL provider). I get alocated my /26 and it > doesn't matter which LNS I connect to or how I get there (indeed I can > talk L2TP directly to the provider to connect over 3G etc.). > I have, once, with routed bridged encapsulation instead of PPP. ~Seth From dougb at dougbarton.us Sun Apr 25 19:35:05 2010 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 25 Apr 2010 17:35:05 -0700 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> Message-ID: <4BD4DFB9.5070105@dougbarton.us> On 04/25/10 16:42, Owen DeLong wrote: > That's what Link Local is for. > > fe80::% > > For example, if the CPE is connected to the customer's network on eth0 > and the CPE mac address is 00:45:4b:b9:02:be, you could go to: > > http://[fe80::0245:4bff:feb9:02be]%eth0 ... and regardless of the specific method, the vendors already document the procedure for connecting to the web interface for IPv4, there is no reason to believe that they could not or would not do the same for IPv6 if necessary. -- ... 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 swmike at swm.pp.se Sun Apr 25 21:37:57 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 26 Apr 2010 04:37:57 +0200 (CEST) Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <4BD4DFB9.5070105@dougbarton.us> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> <4BD4DFB9.5070105@dougbarton.us> Message-ID: On Sun, 25 Apr 2010, Doug Barton wrote: > On 04/25/10 16:42, Owen DeLong wrote: >> That's what Link Local is for. >> >> fe80::% >> >> For example, if the CPE is connected to the customer's network on eth0 >> and the CPE mac address is 00:45:4b:b9:02:be, you could go to: >> >> http://[fe80::0245:4bff:feb9:02be]%eth0 > > ... and regardless of the specific method, the vendors already document > the procedure for connecting to the web interface for IPv4, there is no > reason to believe that they could not or would not do the same for IPv6 > if necessary. Does anyone actually believe that the above is user-friendly and will work in real life? Using link-local for this kind of end-user administration of their equipment is doomed to fail. There needs to be a procedure for devices which are going to get DHCP-PD from the provider, that they have a certain prefix they use until they actually get the real PD prefix, so end user dns etc works so it's easy to do administration of the device. We can't expect end-users to do the above procedure. -- Mikael Abrahamsson email: swmike at swm.pp.se From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Apr 25 22:01:51 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 26 Apr 2010 12:31:51 +0930 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <20100425233230.GX20959@hezmatt.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> <20100425233230.GX20959@hezmatt.org> Message-ID: <20100426123151.78654a64@opy.nosense.org> On Mon, 26 Apr 2010 09:32:30 +1000 Matthew Palmer wrote: > On Mon, Apr 26, 2010 at 08:20:33AM +0930, Mark Smith wrote: > > On Sun, 25 Apr 2010 13:21:16 -0400 > > Richard Barnes wrote: > > > > > Moreover, the general point stands that Mark's problem is one of bad > > > ISP decisions, not anything different between IPv4/RFC1918 and IPv6. > > > > My example, although a bit convoluted to demonstrate a point, is about > > robustness against Internet link failure. I don't think people's > > internal connectivity should be dependent on their Internet link being > > available and being assigned global address space. That's what the > > global only people are saying. > > > > (how is the customer going to access the CPE webserver to enter ISP > > login details when they get the CPE out of the box, if hasn't got > > address space because it hasn't connected to the ISP ...) > > I've been using IPv6 for about 18 seconds, and even *I* know the answer to > that one -- the link-local address. > Ever tried to ping a link local address? If you've been using IPv6 for only 18 seconds, probably not. Try it some time, hopefully you'll work out what the issue with using LLs is. > - Matt > > -- > "You are capable, creative, competent, careful. Prove it." > -- Seen in a fortune cookie > From dougb at dougbarton.us Sun Apr 25 22:03:29 2010 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 25 Apr 2010 20:03:29 -0700 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> <4BD4DFB9.5070105@dougbarton.us> Message-ID: <4BD50281.9040106@dougbarton.us> On 04/25/10 19:37, Mikael Abrahamsson wrote: > On Sun, 25 Apr 2010, Doug Barton wrote: > >> ... and regardless of the specific method, the vendors already document >> the procedure for connecting to the web interface for IPv4, there is no >> reason to believe that they could not or would not do the same for IPv6 >> if necessary. > > Does anyone actually believe that the above is user-friendly and will > work in real life? Sorry, I knew that I shouldn't have helped perpetuate this thread, which (IMO) is already way off topic. Doug -- ... 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 nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Apr 25 22:13:17 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 26 Apr 2010 12:43:17 +0930 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <20100426123151.78654a64@opy.nosense.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> <20100425233230.GX20959@hezmatt.org> <20100426123151.78654a64@opy.nosense.org> Message-ID: <20100426124317.1d02d49c@opy.nosense.org> On Mon, 26 Apr 2010 12:31:51 +0930 Mark Smith wrote: > On Mon, 26 Apr 2010 09:32:30 +1000 > Matthew Palmer wrote: > > > On Mon, Apr 26, 2010 at 08:20:33AM +0930, Mark Smith wrote: > > > On Sun, 25 Apr 2010 13:21:16 -0400 > > > Richard Barnes wrote: > > > > > > > Moreover, the general point stands that Mark's problem is one of bad > > > > ISP decisions, not anything different between IPv4/RFC1918 and IPv6. > > > > > > My example, although a bit convoluted to demonstrate a point, is about > > > robustness against Internet link failure. I don't think people's > > > internal connectivity should be dependent on their Internet link being > > > available and being assigned global address space. That's what the > > > global only people are saying. > > > > > > (how is the customer going to access the CPE webserver to enter ISP > > > login details when they get the CPE out of the box, if hasn't got > > > address space because it hasn't connected to the ISP ...) > > > > I've been using IPv6 for about 18 seconds, and even *I* know the answer to > > that one -- the link-local address. > > > > Ever tried to ping a link local address? > > If you've been using IPv6 for only 18 seconds, probably not. Try it > some time, hopefully you'll work out what the issue with using LLs is. > To make it easier, here's a clue: $ ip -6 route show | grep fe80 fe80::/64 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev tun6to4 proto kernel metric 256 mtu 1472 advmss 1412 hoplimit 4294967295 fe80::/64 dev pan0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 (eth1 is my wired/wireless LAN, tun6to4 is my IPv6 6to4 tunnel, and pan0 is my bluetooth LAN) > > > - Matt > > > > -- > > "You are capable, creative, competent, careful. Prove it." > > -- Seen in a fortune cookie > > From jbates at brightok.net Sun Apr 25 23:23:32 2010 From: jbates at brightok.net (Jack Bates) Date: Sun, 25 Apr 2010 23:23:32 -0500 Subject: DHCP Use (was Re: ) In-Reply-To: <4BD4DA3A.3090406@rollernet.us> References: <4BD46018.30409@cox.net> <20100425.181122.71164896.sthaug@nethelp.no> <09627F14-557C-4FA0-8B52-BD1A444B18D5@delong.com> <20100425.222732.104106150.sthaug@nethelp.no> <4BD4AEC8.7010002@cox.net> <4BD4D13A.3060106@hoyle.me.uk> <4BD4DA3A.3090406@rollernet.us> Message-ID: <4BD51544.5030707@brightok.net> Seth Mattinen wrote: > On 4/25/10 4:33 PM, Tony Hoyle wrote: >> On 25/04/2010 22:06, Larry Sheldon wrote: >> >>> The whole idea that DHCP should only be used for (and is absolute proof >>> of the status of) despised-class customers is just nuts. >> >> I've never seen DHCP used on residential DSL circuits.. it's all PPP (oA >> mostly, and oE if you want) in this country (which the telco picks up >> and sends as L2TP to the DSL provider). I get alocated my /26 and it >> doesn't matter which LNS I connect to or how I get there (indeed I can >> talk L2TP directly to the provider to connect over 3G etc.). >> > > I have, once, with routed bridged encapsulation instead of PPP. > I personally love it, as do my customers who don't care much for cpe's that do NAT or having to configure PPP on their devices. Individual vlans or more traditional pvc for each customer, and massive router configs make for fun. Perhaps someday vendors will support it better, but I enjoy the low overhead and stupid cpe. Oh, and did I mention the customers using switches instead of routers get to enjoy IPv6? Jack From jbates at brightok.net Sun Apr 25 23:27:18 2010 From: jbates at brightok.net (Jack Bates) Date: Sun, 25 Apr 2010 23:27:18 -0500 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> <4BD4DFB9.5070105@dougbarton.us> Message-ID: <4BD51626.4010004@brightok.net> Mikael Abrahamsson wrote: > Does anyone actually believe that the above is user-friendly and will > work in real life? Using link-local for this kind of end-user > administration of their equipment is doomed to fail. There needs to be a > procedure for devices which are going to get DHCP-PD from the provider, > that they have a certain prefix they use until they actually get the > real PD prefix, so end user dns etc works so it's easy to do > administration of the device. Last 3 cheap routers. BIG STICKER: INSTALL SOFTWARE BEFORE YOU PLUG THIS ROUTER IN! I doubt many users even use the old "goto http://192.168.1.1/" anymore. That being said, there are private addressing schemes in IPv6 as well. No reason one could be bound to a cpe router with an easy to type address. Jack From swmike at swm.pp.se Sun Apr 25 23:43:14 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 26 Apr 2010 06:43:14 +0200 (CEST) Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <4BD51626.4010004@brightok.net> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> <4BD4DFB9.5070105@dougbarton.us> <4BD51626.4010004@brightok.net> Message-ID: On Sun, 25 Apr 2010, Jack Bates wrote: > Last 3 cheap routers. BIG STICKER: INSTALL SOFTWARE BEFORE YOU PLUG THIS > ROUTER IN! I doubt many users even use the old "goto http://192.168.1.1/" > anymore. That being said, there are private addressing schemes in IPv6 as > well. No reason one could be bound to a cpe router with an easy to type > address. Yeah, and when I try that on my linux box it won,t install the software for some reason. we need solutions that are cross platform and open, let's not help microsoft any further, thank you. -- Mikael Abrahamsson email: swmike at swm.pp.se From sethm at rollernet.us Sun Apr 25 23:53:15 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 25 Apr 2010 21:53:15 -0700 Subject: DHCP Use (was Re: ) In-Reply-To: <4BD51544.5030707@brightok.net> References: <4BD46018.30409@cox.net> <20100425.181122.71164896.sthaug@nethelp.no> <09627F14-557C-4FA0-8B52-BD1A444B18D5@delong.com> <20100425.222732.104106150.sthaug@nethelp.no> <4BD4AEC8.7010002@cox.net> <4BD4D13A.3060106@hoyle.me.uk> <4BD4DA3A.3090406@rollernet.us> <4BD51544.5030707@brightok.net> Message-ID: <4BD51C3B.5000002@rollernet.us> On 4/25/10 9:23 PM, Jack Bates wrote: > Seth Mattinen wrote: >> On 4/25/10 4:33 PM, Tony Hoyle wrote: >>> On 25/04/2010 22:06, Larry Sheldon wrote: >>> >>>> The whole idea that DHCP should only be used for (and is absolute proof >>>> of the status of) despised-class customers is just nuts. >>> >>> I've never seen DHCP used on residential DSL circuits.. it's all PPP (oA >>> mostly, and oE if you want) in this country (which the telco picks up >>> and sends as L2TP to the DSL provider). I get alocated my /26 and it >>> doesn't matter which LNS I connect to or how I get there (indeed I can >>> talk L2TP directly to the provider to connect over 3G etc.). >>> >> >> I have, once, with routed bridged encapsulation instead of PPP. >> > > I personally love it, as do my customers who don't care much for cpe's > that do NAT or having to configure PPP on their devices. Individual > vlans or more traditional pvc for each customer, and massive router > configs make for fun. Perhaps someday vendors will support it better, > but I enjoy the low overhead and stupid cpe. > > Oh, and did I mention the customers using switches instead of routers > get to enjoy IPv6? > Don't forget the increased MTU without PPP eating some of it. ~Seth From r.engehausen at gmail.com Mon Apr 26 00:03:01 2010 From: r.engehausen at gmail.com (Roy) Date: Sun, 25 Apr 2010 22:03:01 -0700 Subject: DHCP Use (was Re: ) In-Reply-To: <4BD4DA3A.3090406@rollernet.us> References: <4BD46018.30409@cox.net> <20100425.181122.71164896.sthaug@nethelp.no> <09627F14-557C-4FA0-8B52-BD1A444B18D5@delong.com> <20100425.222732.104106150.sthaug@nethelp.no> <4BD4AEC8.7010002@cox.net> <4BD4D13A.3060106@hoyle.me.uk> <4BD4DA3A.3090406@rollernet.us> Message-ID: <4BD51E85.3020609@gmail.com> On 4/25/2010 5:11 PM, Seth Mattinen wrote: > On 4/25/10 4:33 PM, Tony Hoyle wrote: > >> On 25/04/2010 22:06, Larry Sheldon wrote: >> >> >>> The whole idea that DHCP should only be used for (and is absolute proof >>> of the status of) despised-class customers is just nuts. >>> >> >> I've never seen DHCP used on residential DSL circuits.. it's all PPP (oA >> mostly, and oE if you want) in this country (which the telco picks up >> and sends as L2TP to the DSL provider). I get alocated my /26 and it >> doesn't matter which LNS I connect to or how I get there (indeed I can >> talk L2TP directly to the provider to connect over 3G etc.). >> >> > I have, once, with routed bridged encapsulation instead of PPP. > > ~Seth > > > My old company does it this way. Made life very easy. Most consumer grade routers come set for DHCP out of the box so it is plug and play. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Apr 26 00:24:05 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 26 Apr 2010 14:54:05 +0930 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> Message-ID: <20100426145405.7947d206@opy.nosense.org> On Sun, 25 Apr 2010 16:42:31 -0700 Owen DeLong wrote: > > On Apr 25, 2010, at 3:50 PM, Mark Smith wrote: > > > On Sun, 25 Apr 2010 13:21:16 -0400 > > Richard Barnes wrote: > > > >> Moreover, the general point stands that Mark's problem is one of bad > >> ISP decisions, not anything different between IPv4/RFC1918 and IPv6. > >> > > > > My example, although a bit convoluted to demonstrate a point, is about > > robustness against Internet link failure. I don't think people's > > internal connectivity should be dependent on their Internet link being > > available and being assigned global address space. That's what the > > global only people are saying. > > > Your internet connectivity, by definition, depends on an internet link > being available. No link, no connection. Simple as that. > > Now, if you're talking about multihoming, I, as one of the global only > people, am suggesting that you get your global addresses from ARIN > and advertise it to both of your upstreams. > > I know this is not popular with many of the ISPs out there because there > is a cost to that and a scale factor that still has yet to be addressed in the > IP routing paradigm. However, I think that will happen anyway. > > Alternatively, even if you want to do some funky NAT-based solution, > there's nothing wrong with using GUA on the internal side of the NAT > to your PA prefixes outside. That way, when you get the opportunity to > remove that NAT cruft from your environment, you already have usable > addresses and you don't have to renumber. > > > (how is the customer going to access the CPE webserver to enter ISP > > login details when they get the CPE out of the box, if hasn't got > > address space because it hasn't connected to the ISP ...) > > That's what Link Local is for. > > fe80::% > > For example, if the CPE is connected to the customer's network on eth0 > and the CPE mac address is 00:45:4b:b9:02:be, you could go to: > > http://[fe80::0245:4bff:feb9:02be]%eth0 > Would you want to be asking residential customers (your other half, mother, father, sister etc. - not a tech like you) to work that out and then type that in? Would you want to be running the helpdesk that supports those customers, considering the chance of error there is (selecting the wrong interface, typos etc. etc.) The IPv6 Internet needs to be at least as user friendly as IPv4, so asking residential customers to type in anything harder than an IPv4 address is unacceptable. Adding in an interface name to a literal IPv6 address is effectively specifying a subnet, without specifying a subnet. ULAs (announced in RAs) make this easier, because you're not creating the requirement for applications to have to understand both literal LL IPv6 addresses as well as qualifying interface names. Regards, Mark. From swmike at swm.pp.se Mon Apr 26 00:31:04 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 26 Apr 2010 07:31:04 +0200 (CEST) Subject: DHCP Use (was Re: ) In-Reply-To: <4BD51E85.3020609@gmail.com> References: <4BD46018.30409@cox.net> <20100425.181122.71164896.sthaug@nethelp.no> <09627F14-557C-4FA0-8B52-BD1A444B18D5@delong.com> <20100425.222732.104106150.sthaug@nethelp.no> <4BD4AEC8.7010002@cox.net> <4BD4D13A.3060106@hoyle.me.uk> <4BD4DA3A.3090406@rollernet.us> <4BD51E85.3020609@gmail.com> Message-ID: On Sun, 25 Apr 2010, Roy wrote: > My old company does it this way. Made life very easy. Most consumer grade > routers come set for DHCP out of the box so it is plug and play. Yes, running IPoETHoATMoDSL is really nice if you own the dslam yourself, then it's only a media converter. It's also nice to be able to have a very simple L3 device in the CO and do routing there, avoids all the need for secure metro ethernet and long L2 transport. very clean. -- Mikael Abrahamsson email: swmike at swm.pp.se From owen at delong.com Mon Apr 26 01:41:16 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 25 Apr 2010 23:41:16 -0700 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> <4BD4DFB9.5070105@dougbarton.us> Message-ID: On Apr 25, 2010, at 7:37 PM, Mikael Abrahamsson wrote: > On Sun, 25 Apr 2010, Doug Barton wrote: > >> On 04/25/10 16:42, Owen DeLong wrote: >>> That's what Link Local is for. >>> >>> fe80::% >>> >>> For example, if the CPE is connected to the customer's network on eth0 >>> and the CPE mac address is 00:45:4b:b9:02:be, you could go to: >>> >>> http://[fe80::0245:4bff:feb9:02be]%eth0 >> >> ... and regardless of the specific method, the vendors already document >> the procedure for connecting to the web interface for IPv4, there is no >> reason to believe that they could not or would not do the same for IPv6 >> if necessary. > > Does anyone actually believe that the above is user-friendly and will work in real life? Using link-local for this kind of end-user administration of their equipment is doomed to fail. There needs to be a procedure for devices which are going to get DHCP-PD from the provider, that they have a certain prefix they use until they actually get the real PD prefix, so end user dns etc works so it's easy to do administration of the device. > I fail to see how link local is any more difficult than any other IPv6 address. I also fail to see how this is significantly different from the way these devices work in IPv4. > We can't expect end-users to do the above procedure. > Of course not... End users will get a slip of paper with the computed Link Local already on it in the form of connect to http://[fe80::0245:4bff:feb9:02be]%xxx Where xxx will be en0 for Mac, eth0 for Linux, etc. If it's a wireless adapter, it will be en1 for Mac. Windows might get interesting as windows interface naming is, uh, creative at best. Owen From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Apr 26 01:50:50 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 26 Apr 2010 16:20:50 +0930 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <4BD50281.9040106@dougbarton.us> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> <4BD4DFB9.5070105@dougbarton.us> <4BD50281.9040106@dougbarton.us> Message-ID: <20100426162050.5935dd65@opy.nosense.org> On Sun, 25 Apr 2010 20:03:29 -0700 Doug Barton wrote: > On 04/25/10 19:37, Mikael Abrahamsson wrote: > > On Sun, 25 Apr 2010, Doug Barton wrote: > > > >> ... and regardless of the specific method, the vendors already document > >> the procedure for connecting to the web interface for IPv4, there is no > >> reason to believe that they could not or would not do the same for IPv6 > >> if necessary. > > > > Does anyone actually believe that the above is user-friendly and will > > work in real life? > > Sorry, I knew that I shouldn't have helped perpetuate this thread, which > (IMO) is already way off topic. > > I think it is entirely reasonable to discus. End-users of the Internet indirectly pay operators' salaries, so it is very wise for operators to remember to "think like the customer" (or, in the least, remember that if operators make the Internet too hard to use, they'll likely be the ones called around to their non-technical relatives' place to "fix my broken Internet"). From anderson at cbn.net.id Mon Apr 26 01:56:07 2010 From: anderson at cbn.net.id (Anderson) Date: Mon, 26 Apr 2010 13:56:07 +0700 Subject: Contact for AS4134 - China Backbone Message-ID: <4BD53907.9070202@cbn.net.id> Grettings, does someone know contact person at noc for AS4134 - China Backbone ? thank you very much. -- regards, anderson l. CBN Network Operation Center From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Apr 26 02:08:25 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 26 Apr 2010 16:38:25 +0930 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <4BD4D449.8020804@hoyle.me.uk> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <20100426082317.1be2a50d@opy.nosense.org> <4BD4D449.8020804@hoyle.me.uk> Message-ID: <20100426163825.29c6096b@opy.nosense.org> On Mon, 26 Apr 2010 00:46:17 +0100 Tony Hoyle wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 25/04/2010 23:53, Mark Smith wrote: > > On Sun, 25 Apr 2010 16:17:21 +0100 > > Tony Hoyle wrote: > > > > On 25/04/2010 03:01, Mark Smith wrote: > >>>> I'm a typical, fairly near future residential customer. I have a NAS > >>>> that I have movies stored on. My ISP delegates an IPv6 prefix to me with > >>>> a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes > > > > What ISP would put a 'lifetime' on your ipv6 prefix? > > > >> Because they loan it to you while you are their customer. Unless you > >> get PI, you don't 'own' your addresses, so you can't take them with > >> you when you change ISPs. In IPv4 a lifetime is implicit, which might be > >> as long/short as while your current connection is up, in IPv6 it is > >> explicit. > > > That's not what 'lifetime' means in this discusion. They're talking > about v6 addresses changing when you're with the same provider - indeed, > when logged into the same link even. That's insane. > How much do you understand about IPv6 addressing? Are you aware that IPv6 addresses have explicit preferred and valid lifetimes, and therefore they can change over time? > A change of ISP is a major change. Your ipv4 addresses will change as > well if you change ISP. > > As you say, if you don't want them to change get PI space. v6 and v4 > are no different in this respect. > > Tony > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.12 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJL1NRJAAoJEJ1qCQ6ePCDUDeQH/07EZ2uBb5E2Is5juO1NCp4S > BYl36VnSIwmadVZpQxJ2tmrJB2jKGV2sV4K0hJ/QRHRNK0k0CJv2k/KWPf8sis6p > v6bDjnHD1k4bSTxuwEgRbAbPB5uDpRaw7F2ItgdNKGmf8KZh+tCX4uYZ3Pger0Q9 > BEE6y/PjDlgk+ZW+BX6Jgp5raBC9gWu0hiFIhiIRXxmUNgKmJpaRsc6DH5jC5Hch > BhrDxvHZCMNpG2KH32w9D955FSHBCt/ih/hNEB36yDTiln4gMx99jKquECeZrujJ > zX1+sZ0DtLGR3oFjXyXfVS+8Y13i2fLYfQ1g5l/dhXGGs+Nwwb0ska8K+D5Tza0= > =cgpi > -----END PGP SIGNATURE----- > From dot at dotat.at Mon Apr 26 02:27:28 2010 From: dot at dotat.at (Tony Finch) Date: Mon, 26 Apr 2010 08:27:28 +0100 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> <4BD4DFB9.5070105@dougbarton.us> Message-ID: Use mdns/bonjour to connect to unconfigured devices. It uses link- local addresses (no need for an uplink and works for any kind of device) and provides friendly names. Tony (on his iPod). -- f.anthony.n.finch http://dotat.at/ On 26 Apr 2010, at 03:37, Mikael Abrahamsson wrote: > On Sun, 25 Apr 2010, Doug Barton wrote: > >> On 04/25/10 16:42, Owen DeLong wrote: >>> That's what Link Local is for. >>> >>> fe80::% >>> >>> For example, if the CPE is connected to the customer's network on >>> eth0 >>> and the CPE mac address is 00:45:4b:b9:02:be, you could go to: >>> >>> http://[fe80::0245:4bff:feb9:02be]%eth0 >> >> ... and regardless of the specific method, the vendors already >> document >> the procedure for connecting to the web interface for IPv4, there >> is no >> reason to believe that they could not or would not do the same for >> IPv6 >> if necessary. > > Does anyone actually believe that the above is user-friendly and > will work in real life? Using link-local for this kind of end-user > administration of their equipment is doomed to fail. There needs to > be a procedure for devices which are going to get DHCP-PD from the > provider, that they have a certain prefix they use until they > actually get the real PD prefix, so end user dns etc works so it's > easy to do administration of the device. > > We can't expect end-users to do the above procedure. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > From swmike at swm.pp.se Mon Apr 26 05:36:19 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 26 Apr 2010 12:36:19 +0200 (CEST) Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> <4BD4DFB9.5070105@dougbarton.us> Message-ID: On Sun, 25 Apr 2010, Owen DeLong wrote: > I fail to see how link local is any more difficult than any other IPv6 address. They're different because you have to know your local network interface name as well. > Windows might get interesting as windows interface naming is, uh, > creative at best. Exactly. -- Mikael Abrahamsson email: swmike at swm.pp.se From venoy4806 at 163.com Mon Apr 26 06:10:51 2010 From: venoy4806 at 163.com (=?gbk?B?wu3Hvw==?=) Date: Mon, 26 Apr 2010 19:10:51 +0800 (CST) Subject: help In-Reply-To: References: Message-ID: <1951c11.eacb.12839cffae4.Coremail.venoy4806@163.com> ?2010-04-26?nanog-request at nanog.org ??? >Send NANOG mailing list submissions to > nanog at nanog.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog >or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > >You can reach the person managing the list at > nanog-owner at nanog.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of NANOG digest..." > > >Today's Topics: > > 1. Re: [Re: > http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] > (Mikael Abrahamsson) > 2. Re: [Re: > http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] (Mark Smith) > 3. Re: [Re: > http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] (Doug Barton) > 4. Re: [Re: > http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] (Mark Smith) > 5. Re: DHCP Use (was Re: ) (Jack Bates) > 6. Re: [Re: > http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] (Jack Bates) > 7. Re: [Re: > http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] > (Mikael Abrahamsson) > 8. Re: DHCP Use (was Re: ) (Seth Mattinen) > 9. Re: DHCP Use (was Re: ) (Roy) > 10. Re: [Re: > http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] (Mark Smith) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Mon, 26 Apr 2010 04:37:57 +0200 (CEST) >From: Mikael Abrahamsson >Subject: Re: [Re: > http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] >To: Doug Barton >Cc: nanog at nanog.org >Message-ID: >Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > >On Sun, 25 Apr 2010, Doug Barton wrote: > >> On 04/25/10 16:42, Owen DeLong wrote: >>> That's what Link Local is for. >>> >>> fe80::% >>> >>> For example, if the CPE is connected to the customer's network on eth0 >>> and the CPE mac address is 00:45:4b:b9:02:be, you could go to: >>> >>> http://[fe80::0245:4bff:feb9:02be]%eth0 >> >> ... and regardless of the specific method, the vendors already document >> the procedure for connecting to the web interface for IPv4, there is no >> reason to believe that they could not or would not do the same for IPv6 >> if necessary. > >Does anyone actually believe that the above is user-friendly and will work >in real life? Using link-local for this kind of end-user administration of >their equipment is doomed to fail. There needs to be a procedure for >devices which are going to get DHCP-PD from the provider, that they have a >certain prefix they use until they actually get the real PD prefix, so end >user dns etc works so it's easy to do administration of the device. > >We can't expect end-users to do the above procedure. > >-- >Mikael Abrahamsson email: swmike at swm.pp.se > > > >------------------------------ > >Message: 2 >Date: Mon, 26 Apr 2010 12:31:51 +0930 >From: Mark Smith > >Subject: Re: [Re: > http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] >To: Matthew Palmer >Cc: nanog at nanog.org >Message-ID: <20100426123151.78654a64 at opy.nosense.org> >Content-Type: text/plain; charset=US-ASCII > >On Mon, 26 Apr 2010 09:32:30 +1000 >Matthew Palmer wrote: > >> On Mon, Apr 26, 2010 at 08:20:33AM +0930, Mark Smith wrote: >> > On Sun, 25 Apr 2010 13:21:16 -0400 >> > Richard Barnes wrote: >> > >> > > Moreover, the general point stands that Mark's problem is one of bad >> > > ISP decisions, not anything different between IPv4/RFC1918 and IPv6. >> > >> > My example, although a bit convoluted to demonstrate a point, is about >> > robustness against Internet link failure. I don't think people's >> > internal connectivity should be dependent on their Internet link being >> > available and being assigned global address space. That's what the >> > global only people are saying. >> > >> > (how is the customer going to access the CPE webserver to enter ISP >> > login details when they get the CPE out of the box, if hasn't got >> > address space because it hasn't connected to the ISP ...) >> >> I've been using IPv6 for about 18 seconds, and even *I* know the answer to >> that one -- the link-local address. >> > >Ever tried to ping a link local address? > >If you've been using IPv6 for only 18 seconds, probably not. Try it >some time, hopefully you'll work out what the issue with using LLs is. > > >> - Matt >> >> -- >> "You are capable, creative, competent, careful. Prove it." >> -- Seen in a fortune cookie >> > > > >------------------------------ > >Message: 3 >Date: Sun, 25 Apr 2010 20:03:29 -0700 >From: Doug Barton >Subject: Re: [Re: > http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] >To: Mikael Abrahamsson >Cc: nanog at nanog.org >Message-ID: <4BD50281.9040106 at dougbarton.us> >Content-Type: text/plain; charset=ISO-8859-1 > >On 04/25/10 19:37, Mikael Abrahamsson wrote: >> On Sun, 25 Apr 2010, Doug Barton wrote: >> >>> ... and regardless of the specific method, the vendors already document >>> the procedure for connecting to the web interface for IPv4, there is no >>> reason to believe that they could not or would not do the same for IPv6 >>> if necessary. >> >> Does anyone actually believe that the above is user-friendly and will >> work in real life? > >Sorry, I knew that I shouldn't have helped perpetuate this thread, which >(IMO) is already way off topic. > > >Doug > >-- > > ... 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/ > > > > >------------------------------ > >Message: 4 >Date: Mon, 26 Apr 2010 12:43:17 +0930 >From: Mark Smith > >Subject: Re: [Re: > http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] >To: Matthew Palmer >Cc: nanog at nanog.org >Message-ID: <20100426124317.1d02d49c at opy.nosense.org> >Content-Type: text/plain; charset=US-ASCII > >On Mon, 26 Apr 2010 12:31:51 +0930 >Mark Smith >wrote: > >> On Mon, 26 Apr 2010 09:32:30 +1000 >> Matthew Palmer wrote: >> >> > On Mon, Apr 26, 2010 at 08:20:33AM +0930, Mark Smith wrote: >> > > On Sun, 25 Apr 2010 13:21:16 -0400 >> > > Richard Barnes wrote: >> > > >> > > > Moreover, the general point stands that Mark's problem is one of bad >> > > > ISP decisions, not anything different between IPv4/RFC1918 and IPv6. >> > > >> > > My example, although a bit convoluted to demonstrate a point, is about >> > > robustness against Internet link failure. I don't think people's >> > > internal connectivity should be dependent on their Internet link being >> > > available and being assigned global address space. That's what the >> > > global only people are saying. >> > > >> > > (how is the customer going to access the CPE webserver to enter ISP >> > > login details when they get the CPE out of the box, if hasn't got >> > > address space because it hasn't connected to the ISP ...) >> > >> > I've been using IPv6 for about 18 seconds, and even *I* know the answer to >> > that one -- the link-local address. >> > >> >> Ever tried to ping a link local address? >> >> If you've been using IPv6 for only 18 seconds, probably not. Try it >> some time, hopefully you'll work out what the issue with using LLs is. >> > >To make it easier, here's a clue: > >$ ip -6 route show | grep fe80 >fe80::/64 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 >fe80::/64 dev tun6to4 proto kernel metric 256 mtu 1472 advmss 1412 hoplimit 4294967295 >fe80::/64 dev pan0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 > > >(eth1 is my wired/wireless LAN, tun6to4 is my IPv6 6to4 tunnel, and pan0 is my bluetooth LAN) > > >> >> > - Matt >> > >> > -- >> > "You are capable, creative, competent, careful. Prove it." >> > -- Seen in a fortune cookie >> > > > > >------------------------------ > >Message: 5 >Date: Sun, 25 Apr 2010 23:23:32 -0500 >From: Jack Bates >Subject: Re: DHCP Use (was Re: ) >To: Seth Mattinen >Cc: nanog at nanog.org >Message-ID: <4BD51544.5030707 at brightok.net> >Content-Type: text/plain; charset=UTF-8; format=flowed > >Seth Mattinen wrote: >> On 4/25/10 4:33 PM, Tony Hoyle wrote: >>> On 25/04/2010 22:06, Larry Sheldon wrote: >>> >>>> The whole idea that DHCP should only be used for (and is absolute proof >>>> of the status of) despised-class customers is just nuts. >>> >>> I've never seen DHCP used on residential DSL circuits.. it's all PPP (oA >>> mostly, and oE if you want) in this country (which the telco picks up >>> and sends as L2TP to the DSL provider). I get alocated my /26 and it >>> doesn't matter which LNS I connect to or how I get there (indeed I can >>> talk L2TP directly to the provider to connect over 3G etc.). >>> >> >> I have, once, with routed bridged encapsulation instead of PPP. >> > >I personally love it, as do my customers who don't care much for cpe's >that do NAT or having to configure PPP on their devices. Individual >vlans or more traditional pvc for each customer, and massive router >configs make for fun. Perhaps someday vendors will support it better, >but I enjoy the low overhead and stupid cpe. > >Oh, and did I mention the customers using switches instead of routers >get to enjoy IPv6? > >Jack > > > >------------------------------ > >Message: 6 >Date: Sun, 25 Apr 2010 23:27:18 -0500 >From: Jack Bates >Subject: Re: [Re: > http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] >To: Mikael Abrahamsson >Cc: nanog at nanog.org >Message-ID: <4BD51626.4010004 at brightok.net> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >Mikael Abrahamsson wrote: >> Does anyone actually believe that the above is user-friendly and will >> work in real life? Using link-local for this kind of end-user >> administration of their equipment is doomed to fail. There needs to be a >> procedure for devices which are going to get DHCP-PD from the provider, >> that they have a certain prefix they use until they actually get the >> real PD prefix, so end user dns etc works so it's easy to do >> administration of the device. > >Last 3 cheap routers. BIG STICKER: INSTALL SOFTWARE BEFORE YOU PLUG THIS >ROUTER IN! I doubt many users even use the old "goto >http://192.168.1.1/" anymore. That being said, there are private >addressing schemes in IPv6 as well. No reason one could be bound to a >cpe router with an easy to type address. > > >Jack > > > >------------------------------ > >Message: 7 >Date: Mon, 26 Apr 2010 06:43:14 +0200 (CEST) >From: Mikael Abrahamsson >Subject: Re: [Re: > http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] >To: Jack Bates >Cc: nanog at nanog.org >Message-ID: >Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > >On Sun, 25 Apr 2010, Jack Bates wrote: > >> Last 3 cheap routers. BIG STICKER: INSTALL SOFTWARE BEFORE YOU PLUG THIS >> ROUTER IN! I doubt many users even use the old "goto http://192.168.1.1/" >> anymore. That being said, there are private addressing schemes in IPv6 as >> well. No reason one could be bound to a cpe router with an easy to type >> address. > >Yeah, and when I try that on my linux box it won,t install the software >for some reason. we need solutions that are cross platform and open, let's >not help microsoft any further, thank you. > >-- >Mikael Abrahamsson email: swmike at swm.pp.se > > > >------------------------------ > >Message: 8 >Date: Sun, 25 Apr 2010 21:53:15 -0700 >From: Seth Mattinen >Subject: Re: DHCP Use (was Re: ) >To: nanog at nanog.org >Message-ID: <4BD51C3B.5000002 at rollernet.us> >Content-Type: text/plain; charset=UTF-8 > >On 4/25/10 9:23 PM, Jack Bates wrote: >> Seth Mattinen wrote: >>> On 4/25/10 4:33 PM, Tony Hoyle wrote: >>>> On 25/04/2010 22:06, Larry Sheldon wrote: >>>> >>>>> The whole idea that DHCP should only be used for (and is absolute proof >>>>> of the status of) despised-class customers is just nuts. >>>> >>>> I've never seen DHCP used on residential DSL circuits.. it's all PPP (oA >>>> mostly, and oE if you want) in this country (which the telco picks up >>>> and sends as L2TP to the DSL provider). I get alocated my /26 and it >>>> doesn't matter which LNS I connect to or how I get there (indeed I can >>>> talk L2TP directly to the provider to connect over 3G etc.). >>>> >>> >>> I have, once, with routed bridged encapsulation instead of PPP. >>> >> >> I personally love it, as do my customers who don't care much for cpe's >> that do NAT or having to configure PPP on their devices. Individual >> vlans or more traditional pvc for each customer, and massive router >> configs make for fun. Perhaps someday vendors will support it better, >> but I enjoy the low overhead and stupid cpe. >> >> Oh, and did I mention the customers using switches instead of routers >> get to enjoy IPv6? >> > >Don't forget the increased MTU without PPP eating some of it. > >~Seth > > > >------------------------------ > >Message: 9 >Date: Sun, 25 Apr 2010 22:03:01 -0700 >From: Roy >Subject: Re: DHCP Use (was Re: ) >Cc: nanog at nanog.org >Message-ID: <4BD51E85.3020609 at gmail.com> >Content-Type: text/plain; charset=UTF-8; format=flowed > >On 4/25/2010 5:11 PM, Seth Mattinen wrote: >> On 4/25/10 4:33 PM, Tony Hoyle wrote: >> >>> On 25/04/2010 22:06, Larry Sheldon wrote: >>> >>> >>>> The whole idea that DHCP should only be used for (and is absolute proof >>>> of the status of) despised-class customers is just nuts. >>>> >>> >>> I've never seen DHCP used on residential DSL circuits.. it's all PPP (oA >>> mostly, and oE if you want) in this country (which the telco picks up >>> and sends as L2TP to the DSL provider). I get alocated my /26 and it >>> doesn't matter which LNS I connect to or how I get there (indeed I can >>> talk L2TP directly to the provider to connect over 3G etc.). >>> >>> >> I have, once, with routed bridged encapsulation instead of PPP. >> >> ~Seth >> >> >> > > >My old company does it this way. Made life very easy. Most consumer >grade routers come set for DHCP out of the box so it is plug and play. > > > > > >------------------------------ > >Message: 10 >Date: Mon, 26 Apr 2010 14:54:05 +0930 >From: Mark Smith > >Subject: Re: [Re: > http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] >To: Owen DeLong >Cc: nanog at nanog.org >Message-ID: <20100426145405.7947d206 at opy.nosense.org> >Content-Type: text/plain; charset=US-ASCII > >On Sun, 25 Apr 2010 16:42:31 -0700 >Owen DeLong wrote: > >> >> On Apr 25, 2010, at 3:50 PM, Mark Smith wrote: >> >> > On Sun, 25 Apr 2010 13:21:16 -0400 >> > Richard Barnes wrote: >> > >> >> Moreover, the general point stands that Mark's problem is one of bad >> >> ISP decisions, not anything different between IPv4/RFC1918 and IPv6. >> >> >> > >> > My example, although a bit convoluted to demonstrate a point, is about >> > robustness against Internet link failure. I don't think people's >> > internal connectivity should be dependent on their Internet link being >> > available and being assigned global address space. That's what the >> > global only people are saying. >> > >> Your internet connectivity, by definition, depends on an internet link >> being available. No link, no connection. Simple as that. >> >> Now, if you're talking about multihoming, I, as one of the global only >> people, am suggesting that you get your global addresses from ARIN >> and advertise it to both of your upstreams. >> >> I know this is not popular with many of the ISPs out there because there >> is a cost to that and a scale factor that still has yet to be addressed in the >> IP routing paradigm. However, I think that will happen anyway. >> >> Alternatively, even if you want to do some funky NAT-based solution, >> there's nothing wrong with using GUA on the internal side of the NAT >> to your PA prefixes outside. That way, when you get the opportunity to >> remove that NAT cruft from your environment, you already have usable >> addresses and you don't have to renumber. >> >> > (how is the customer going to access the CPE webserver to enter ISP >> > login details when they get the CPE out of the box, if hasn't got >> > address space because it hasn't connected to the ISP ...) >> >> That's what Link Local is for. >> >> fe80::% >> >> For example, if the CPE is connected to the customer's network on eth0 >> and the CPE mac address is 00:45:4b:b9:02:be, you could go to: >> >> http://[fe80::0245:4bff:feb9:02be]%eth0 >> > >Would you want to be asking residential customers (your other half, >mother, father, sister etc. - not a tech like you) to work that out and >then type that in? Would you want to be running the helpdesk that >supports those customers, considering the chance of error there is >(selecting the wrong interface, typos etc. etc.) > >The IPv6 Internet needs to be at least as user friendly as IPv4, so >asking residential customers to type in anything harder than an IPv4 >address is unacceptable. > >Adding in an interface name to a literal IPv6 address is effectively >specifying a subnet, without specifying a subnet. ULAs (announced in >RAs) make this easier, because you're not creating the requirement for >applications to have to understand both literal LL IPv6 addresses as >well as qualifying interface names. > >Regards, >Mark. > > > >------------------------------ > >_______________________________________________ >NANOG mailing list >NANOG at nanog.org >https://mailman.nanog.org/mailman/listinfo/nanog > >End of NANOG Digest, Vol 27, Issue 158 >************************************** From tony at hoyle.me.uk Mon Apr 26 07:17:02 2010 From: tony at hoyle.me.uk (Tony Hoyle) Date: Mon, 26 Apr 2010 13:17:02 +0100 Subject: DHCP Use (was Re: ) In-Reply-To: <4BD51C3B.5000002@rollernet.us> References: <4BD46018.30409@cox.net> <20100425.181122.71164896.sthaug@nethelp.no> <09627F14-557C-4FA0-8B52-BD1A444B18D5@delong.com> <20100425.222732.104106150.sthaug@nethelp.no> <4BD4AEC8.7010002@cox.net> <4BD4D13A.3060106@hoyle.me.uk> <4BD4DA3A.3090406@rollernet.us> <4BD51544.5030707@brightok.net> <4BD51C3B.5000002@rollernet.us> Message-ID: <4BD5843E.5020909@hoyle.me.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26/04/2010 05:53, Seth Mattinen wrote: > > Don't forget the increased MTU without PPP eating some of it. > You get 1500 with PPPoA anyway. You can do it with PPPoE with some jiggery pokery.. that tends to be in the class of 'neat hack' though. Tony -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL1YQ+AAoJEJ1qCQ6ePCDU7IsH/i9RFUvseW9m4fqedaNZu/Q1 cv2wT6IkOFRtl/HiVwXZ6qiQykeEz2A+yBG4QI2Ho1EhYUr4tWlz1JjFGXwx9nKD cSvH5YvmSJl6jSr3Co2hVWuTcB0w7oCet/6maUoyzoyHoIEOzPqhEl8a8/If2SUX G28cmTC2It7IBj7ACIBZA6HjvFVJ6hqCfv8dwewwhDRRSe5YD91YRQ2HsrvDMUQY ybqySe23IfSH2/oxTytdoA371pm1t3pGCTNXqRKIpBJY/UXeki+PezWnbhFSmPGj XXMWY7/P66J4RK6c5Bpx+lCKkbxC+F6U6AUdeKVH8T8wWTJfkTfDIwrwTgJN+N0= =IWIw -----END PGP SIGNATURE----- From tony at hoyle.me.uk Mon Apr 26 07:27:41 2010 From: tony at hoyle.me.uk (Tony Hoyle) Date: Mon, 26 Apr 2010 13:27:41 +0100 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <20100426163825.29c6096b@opy.nosense.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <20100426082317.1be2a50d@opy.nosense.org> <4BD4D449.8020804@hoyle.me.uk> <20100426163825.29c6096b@opy.nosense.org> Message-ID: <4BD586BD.4060002@hoyle.me.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26/04/2010 08:08, Mark Smith wrote: > >> How much do you understand about IPv6 addressing? Are you aware that >> IPv6 addresses have explicit preferred and valid lifetimes, and >> therefore they can change over time? Only via privacy extensions.. and I always switch them off as they're a pain in the neck. Even with those they don't change the prefix. My /48 is allocated to me.. In no sane world would that suddenly change, unless I did something major like change ISP, any more than my v4 address would suddenly change. You're trying to say ipv6 prefixes change randomly over time - just think of the implications if that could happen... even basic things like firewalling would become a nightmare. Tony -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL1Ya9AAoJEJ1qCQ6ePCDU5H0H/RE+eHLqJ/18akk/OQHaGF1H 6DebnteCd73tHzzY+1rNs0yNlOkFIE6u3FSCjRgP0Es+x4K7RjKsBhKzWYxhb+t3 CnPQNySP1diQxhCPZV/aTOC+/hyAKFdsQhz4TKVhMdhbA+K+wqpwUWAAXZMTVpoh GuMdK6EngV0IHw2gMwt+VdLVMbKII2BTiw7GVKnULwWhPUOipfJ0othxPhStULtg 3adZo4ka+129Cpv3Kx0BkMLTLUDneJA8Ia6MgRRz7G9SBlaJQ6J6Oidcp49Ag3SF 4jw+8DhLQbZJPsuRjxcdBYZDEHkVBqTje+KNbp2tuAUUCzqKClOSGycszyfncp0= =MWdV -----END PGP SIGNATURE----- From andy at nosignal.org Mon Apr 26 08:10:53 2010 From: andy at nosignal.org (Andy Davidson) Date: Mon, 26 Apr 2010 14:10:53 +0100 Subject: Books for the NOC guys... In-Reply-To: <86wrwqukcm.fsf@seastrom.com> References: <86wrwqukcm.fsf@seastrom.com> Message-ID: <20100426131053.GA10509@chilli.nosignal.org> On Fri, Apr 02, 2010 at 08:09:29AM -0400, Robert E. Seastrom wrote: > This morning I went digging for a book to recommend that someone in > our NOC read in order to understand at a high level how Internet > infrastructure works How to do comes automatically, *why* to do is the difference between a good and great engineer. Watching old nanog (and other country-nog) archives is good, going to the actual meetings and meeting people is better, and developing a culture of shared understanding and colaboration is golden. I guess I mean, working out the what the "best way" to build a network is rather than following an example.. If you do like dead trees, then capturing the spirit of what I mean comes from older books like my (prized) "ISP Survival Guide" (Geoff Huston). My 2p. Andy From jbates at brightok.net Mon Apr 26 08:23:26 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 26 Apr 2010 08:23:26 -0500 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> <4BD4DFB9.5070105@dougbarton.us> <4BD51626.4010004@brightok.net> Message-ID: <4BD593CE.50109@brightok.net> Mikael Abrahamsson wrote: > > Yeah, and when I try that on my linux box it won,t install the software > for some reason. we need solutions that are cross platform and open, > let's not help microsoft any further, thank you. > Ummm, we're talking about idiots that can't figure out how to type and address. If you're on a linux box, presumably there is someone around that can hit a link-local or other addressing scheme programmed on the router. Jack From swmike at swm.pp.se Mon Apr 26 08:32:03 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 26 Apr 2010 15:32:03 +0200 (CEST) Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <4BD593CE.50109@brightok.net> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> <4BD4DFB9.5070105@dougbarton.us> <4BD51626.4010004@brightok.net> <4BD593CE.50109@brightok.net> Message-ID: On Mon, 26 Apr 2010, Jack Bates wrote: > Ummm, we're talking about idiots that can't figure out how to type and > address. If you're on a linux box, presumably there is someone around that > can hit a link-local or other addressing scheme programmed on the router. This is getting wildly off topic, but if you go to the ubuntu support channels and forums (and mac I guess) you'll see that this is no longer true. -- Mikael Abrahamsson email: swmike at swm.pp.se From jbates at brightok.net Mon Apr 26 08:38:16 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 26 Apr 2010 08:38:16 -0500 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <20100426145405.7947d206@opy.nosense.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> <20100426145405.7947d206@opy.nosense.org> Message-ID: <4BD59748.7020408@brightok.net> Mark Smith wrote: > The IPv6 Internet needs to be at least as user friendly as IPv4, so > asking residential customers to type in anything harder than an IPv4 > address is unacceptable. IPv6 has plenty of them. http://www.rfc-editor.org/rfc/rfc4193.txt rfc4193, and please remember you can bind multiple IPv6 addresses, which makes it even more fun, and there's honestly no reason why dns services, capture services, etc on a home router can't make it a painless process. That being said, typing a shortcut address into a browser won't be bad and since not link-local you don't have to worry about the %interface crap. Jack From jbates at brightok.net Mon Apr 26 08:42:31 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 26 Apr 2010 08:42:31 -0500 Subject: DHCP Use (was Re: ) In-Reply-To: References: <4BD46018.30409@cox.net> <20100425.181122.71164896.sthaug@nethelp.no> <09627F14-557C-4FA0-8B52-BD1A444B18D5@delong.com> <20100425.222732.104106150.sthaug@nethelp.no> <4BD4AEC8.7010002@cox.net> <4BD4D13A.3060106@hoyle.me.uk> <4BD4DA3A.3090406@rollernet.us> <4BD51E85.3020609@gmail.com> Message-ID: <4BD59847.1080101@brightok.net> Mikael Abrahamsson wrote: > > Yes, running IPoETHoATMoDSL is really nice if you own the dslam > yourself, then it's only a media converter. It's also nice to be able to > have a very simple L3 device in the CO and do routing there, avoids all > the need for secure metro ethernet and long L2 transport. very clean. > I don't do anything without consideration of the future. My own network, and even some of the local AT&T pops easily handle sliding of DSL customers to interconnected ISPs. Extremely easy with ATM, and even doable with 802.1ad for those non-atm DSLAMs (idiotic sales pitch isn't it? Of course, it has ATM!). Jack From stephen at sprunk.org Mon Apr 26 09:20:30 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 26 Apr 2010 09:20:30 -0500 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <20100425113106.6b12817c@opy.nosense.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> Message-ID: <4BD5A12E.50907@sprunk.org> On 24 Apr 2010 21:01, Mark Smith wrote: > On Thu, 22 Apr 2010 01:48:18 -0400 > Christopher Morrow wrote: > >> On Wed, Apr 21, 2010 at 5:47 PM, Mark Smith >> wrote: >> >>> So what happens when you change providers? How are you going to keep using globals that now aren't yours? >>> >> use pi space, request it from your local friendly RIR. >> > I was hoping that wasn't going to be your answer. So do you expect every residential customer to get a PI from an RIR? > The vast majority of residential customers have no idea what "globals" or "PI" are. They use PA and they're fine with that--despite being forcibly renumbered every few hours/days. (Many ISPs deliberately tune their DHCP servers to give residential customers a different address each time for "market segmentation" reasons.) > Here's the scenario: > > I'm a typical, fairly near future residential customer. I have a NAS that I have movies stored on. My ISP delegates an IPv6 prefix to me with a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes. ... I start watching a 2 hour movie, delivered from my NAS to my TV over IPv6, using the GUA addresses (because you're saying I don't ULAs). 5 minutes into the movie, my Internet drops out. And five minutes and a few seconds into the movie, the movie drops out because the DRM mechanism can't phone home anymore to validate you still have a license to watch it. I have an IP-based DVR, and that's exactly what happens. However, let us look forward to a world where the TV/movie studios have woken up to the fact that DRM does more harm than good, as the record industry recently has: > 1 hour, 35 minutes into movie, the movies drops out, because the IPv6 addresses used to deliver it can't be used anymore. The vast majority of residential customers have a single subnet, so they can get by just fine using IPv6 link-local addresses. The vanishingly small percentage that have multiple subnets are presumably savvy enough to set up ULA-R addresses. There is no need for ULA-C in this scenario. The only semi-rational justification for ULA-C is that organizations privately internetworking with other organizations are scared of ULA-R collisions. However, PI solves that problem just as readily. If one cannot afford or qualify for PI, or one wants a non-PI prefix due to delusions of better security, one can use a private deconfliction registry, e.g. . S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From stephen at sprunk.org Mon Apr 26 09:34:27 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 26 Apr 2010 09:34:27 -0500 Subject: Connectivity to an IPv6-only site In-Reply-To: <4BD35F5B.8060904@brightok.net> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> <538D27E2-4771-4420-821D-BA8879B6822A@delong.com> <5598.1272031635@localhost> <201004231645.o3NGj5e5066388@drugs.dv.isc.org> <14793.1272042510@localhost> <4BD35F5B.8060904@brightok.net> Message-ID: <4BD5A473.9050309@sprunk.org> On 24 Apr 2010 16:15, Jack Bates wrote: > Valdis.Kletnieks at vt.edu wrote: >> No, the problems are probably further back in time. We first started >> turning up IPv6 back in 1997 or so. There's a *very* good chance >> that we turned it off a decade ago (or whenever people *first* >> started listing quad-A's in NS entries) due to breakage and never >> actually revisited it since then. This would have been in the era of >> early 6bone and "your IPv6 connection is probably tromboned through >> Tokyo". > > I periodically see issues with idiotic load balancers that don't > respond to anything except A records for specific domains. This causes > problems when requesting AAAA records and delays waiting for timeouts > before going to A. newegg fixed theirs though, yipeee! :) Don't forget the hotspot vendor that returns an address of 0.0.0.1 for every A query if you have previously done an AAAA query for the same name (and timed out). That's a fun one. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From jimb at jsbc.cc Mon Apr 26 09:46:04 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Mon, 26 Apr 2010 07:46:04 -0700 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> <4BD4DFB9.5070105@dougbarton.us> Message-ID: <4BD5A72C.301@jsbc.cc> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/26/2010 03:36, Mikael Abrahamsson wrote: > On Sun, 25 Apr 2010, Owen DeLong wrote: > >> I fail to see how link local is any more difficult than any >> other IPv6 address. > > They're different because you have to know your local network > interface name as well. > >> Windows might get interesting as windows interface naming is, >> uh, creative at best. > > Exactly. > Installation software could make this easy. It could either prompt the user to type in the address on a sticker then enumerate all interfaces on the system and attempt to contact the router on each NIC. Another possibility is that it could enumerate all the interfaces, then use the IPv6 link-local scope all routers multicast (ff02::2) to enumerate a list of routers found on each link, sort them and/or filter them by ethernet OUI, and present a list of choices for the user to click on to configure the router. The user could also easily match the enet address on a little slip of paper or sticker on the router to this list, or through some initial settings on the router which allow info to be pulled from it somehow, present a list of unconfigured routers, etc, etc. Point is, I can imagine a lot of ways this could be made user-proof via software/firmware combination that requires no advanced networking knowledge. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvVpywACgkQ2fXFxl4S7sSCuwCg07Gwxz6NDYuTkVYr5gP5LUMC n4EAoIdqZQ7C/01X0EcV3vnZiTD4b7Vc =hDQN -----END PGP SIGNATURE----- From owen at delong.com Mon Apr 26 10:01:37 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 26 Apr 2010 08:01:37 -0700 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <4BD586BD.4060002@hoyle.me.uk> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <20100426082317.1be2a50d@opy.nosense.org> <4BD4D449.8020804@hoyle.me.uk> <20100426163825.29c6096b@opy.nosense.org> <4BD586BD.4060002@hoyle.me.uk> Message-ID: <69F9805C-0D15-4610-9BC4-9F6028C265B2@delong.com> On Apr 26, 2010, at 5:27 AM, Tony Hoyle wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 26/04/2010 08:08, Mark Smith wrote: > >> >>> How much do you understand about IPv6 addressing? Are you aware that >>> IPv6 addresses have explicit preferred and valid lifetimes, and >>> therefore they can change over time? > > Only via privacy extensions.. and I always switch them off as they're a > pain in the neck. Even with those they don't change the prefix. > Uh, no... If you're using slack, IPv6 addresses have explicit preferred and valid lifetimes for the PREFIX which can change over time at the decision of the person running the device(s) issuing the RAs. > My /48 is allocated to me.. In no sane world would that suddenly > change, unless I did something major like change ISP, any more than my > v4 address would suddenly change. > Agreed, mostly. If your provider issues your /48 to you via DHCP-PD, then, it, too, has a desired and valid lifetime which is expected to be passed along in your subordinate RAs, and, it means that if they reconfigure their DHCP server, you are expected to abide by the change. > You're trying to say ipv6 prefixes change randomly over time - just > think of the implications if that could happen... even basic things like > firewalling would become a nightmare. > Whether they do or not depends on your circumstance and the design of upstream networks. They may or may not. Certainly it is desirable from a customer perspective that they do not. It may be equally desirable from a carrier perspective that they do. Personally, I hope carriers will design their networks well enough that changing prefixes at random times is not necessary and customers can get a better IPv6 experience. We, for one, use static assignments at HE. Owen From morrowc.lists at gmail.com Mon Apr 26 10:07:52 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 26 Apr 2010 11:07:52 -0400 Subject: Connectivity to an IPv6-only site In-Reply-To: <4BD5A473.9050309@sprunk.org> References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> <538D27E2-4771-4420-821D-BA8879B6822A@delong.com> <5598.1272031635@localhost> <201004231645.o3NGj5e5066388@drugs.dv.isc.org> <14793.1272042510@localhost> <4BD35F5B.8060904@brightok.net> <4BD5A473.9050309@sprunk.org> Message-ID: On Mon, Apr 26, 2010 at 10:34 AM, Stephen Sprunk wrote: > Don't forget the hotspot vendor that returns an address of 0.0.0.1 for > every A query if you have previously done an AAAA query for the same > name (and timed out). ?That's a fun one. so... aside from the every 3 months bitching on this list (and some on v6ops maybe) about these sorts of things, what's happening to tell/educate/warn/notice the hotspot-vendors that this sort of practice (along with 'everything is at 1.1.1.1!') is just a bad plan? How can users, even more advanced users, tell a hotspot vendor in a meaningful way that their 'solution' is broken? -chris From morrowc.lists at gmail.com Mon Apr 26 10:12:00 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 26 Apr 2010 11:12:00 -0400 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <69F9805C-0D15-4610-9BC4-9F6028C265B2@delong.com> References: <20100421043432.GB25523@vacation.karoshi.com.> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <20100426082317.1be2a50d@opy.nosense.org> <4BD4D449.8020804@hoyle.me.uk> <20100426163825.29c6096b@opy.nosense.org> <4BD586BD.4060002@hoyle.me.uk> <69F9805C-0D15-4610-9BC4-9F6028C265B2@delong.com> Message-ID: On Mon, Apr 26, 2010 at 11:01 AM, Owen DeLong wrote: > We, for one, use static assignments at HE. HE.net provides a fine tunneled service, they have a limited number of 'pops', so it can afford to split their initial allocation up into very large chunks ... look at the typical DSL/cable deployment, splitting of headends and or pops COULD cause outgrowth of the initial pop-level allocation and forcing a re-addressing of the downstream users, if keeping some aggregation is relevant to the provider. I hear HE is headed back to their local RIR for another allocation though, eh? -chris From jbates at brightok.net Mon Apr 26 10:20:10 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 26 Apr 2010 10:20:10 -0500 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <69F9805C-0D15-4610-9BC4-9F6028C265B2@delong.com> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <20100426082317.1be2a50d@opy.nosense.org> <4BD4D449.8020804@hoyle.me.uk> <20100426163825.29c6096b@opy.nosense.org> <4BD586BD.4060002@hoyle.me.uk> <69F9805C-0D15-4610-9BC4-9F6028C265B2@delong.com> Message-ID: <4BD5AF2A.90202@brightok.net> Owen DeLong wrote: > Whether they do or not depends on your circumstance and the design > of upstream networks. They may or may not. Certainly it is desirable > from a customer perspective that they do not. It may be equally desirable > from a carrier perspective that they do. Personally, I hope carriers will > design their networks well enough that changing prefixes at random > times is not necessary and customers can get a better IPv6 experience. > I won't say that it never changes, but generally it has not. Prefix is 2607:F780:1::/48 assign /60 prefix 1 entries in use, 4095 available, 0 rejected 0 entries cached, 1000 maximum User Prefix Interface 0001000110D1D32C001 2607:F780:1::/60 AT5/0.14250 I presume it will stay the same as long as cache works. Jack From owen at delong.com Mon Apr 26 10:33:28 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 26 Apr 2010 08:33:28 -0700 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <4BD5A12E.50907@sprunk.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD5A12E.50907@sprunk.org> Message-ID: <3DD429BD-FE58-4BE0-BF5A-17CC313DFF87@delong.com> On Apr 26, 2010, at 7:20 AM, Stephen Sprunk wrote: > On 24 Apr 2010 21:01, Mark Smith wrote: >> On Thu, 22 Apr 2010 01:48:18 -0400 >> Christopher Morrow wrote: >> >>> On Wed, Apr 21, 2010 at 5:47 PM, Mark Smith >>> wrote: >>> >>>> So what happens when you change providers? How are you going to keep using globals that now aren't yours? >>>> >>> use pi space, request it from your local friendly RIR. >>> >> I was hoping that wasn't going to be your answer. So do you expect every residential customer to get a PI from an RIR? >> > > The vast majority of residential customers have no idea what "globals" > or "PI" are. They use PA and they're fine with that--despite being > forcibly renumbered every few hours/days. (Many ISPs deliberately tune > their DHCP servers to give residential customers a different address > each time for "market segmentation" reasons.) > The majority of residential cusotmers bitch about paying $20/month for what they have and are not planning to multihome. This was a comment about multihoming. FWIW, this residential user has PI from an RIR (v4 and v6) and is multihomed using it. It works fine. > > The only semi-rational justification for ULA-C is that organizations > privately internetworking with other organizations are scared of ULA-R > collisions. However, PI solves that problem just as readily. If one > cannot afford or qualify for PI, or one wants a non-PI prefix due to > delusions of better security, one can use a private deconfliction > registry, e.g. . > The claim being made which I was attempting to refute had nothing to do with residential. IT was that ULA-C with NAT at the border would allow an organization to semi-transparently switch back and forth between providers. This is a (somewhat) common practice in IPv4 for delivering (degraded) multihoming. Owen From Bryan at bryanfields.net Mon Apr 26 10:57:49 2010 From: Bryan at bryanfields.net (Bryan Fields) Date: Mon, 26 Apr 2010 11:57:49 -0400 Subject: IPAM Message-ID: <4BD5B7FD.9040707@bryanfields.net> I'm wondering what the service providers are using for IPAM. We are looking at having to manage both v4 and v6 address space and delegate internally to other people. I've looked at infoblox, but we can't justify spending 400k at this point. It's a lovely solution though. Lucent has/had a product too, but having used it before it sucks. It's also about 5x the cost of the info blox solution, and I'd rather not run solaris or windows in production. Is anyone running IPplan? http://iptrack.sourceforge.net/ I looked at it before, and at the time it's support of V6 was lacking. Is anyone running this in a SP environment with v6? Any other OSS tools for this people are using? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From regnauld at nsrc.org Mon Apr 26 11:08:31 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Mon, 26 Apr 2010 18:08:31 +0200 Subject: IPAM In-Reply-To: <4BD5B7FD.9040707@bryanfields.net> References: <4BD5B7FD.9040707@bryanfields.net> Message-ID: On 26/04/2010, at 17.57, Bryan Fields wrote: > Is anyone running IPplan? http://iptrack.sourceforge.net/ I looked > at it > before, and at the time it's support of V6 was lacking. Is anyone > running > this in a SP environment with v6? > > Any other OSS tools for this people are using? Check out tipp: http://tipp.tobez.org/ There was a discussion thread on this topic not long ago here. Cheers, Phil From williamsjj at digitar.com Mon Apr 26 11:13:05 2010 From: williamsjj at digitar.com (Jason J. W. Williams) Date: Mon, 26 Apr 2010 10:13:05 -0600 Subject: IPAM In-Reply-To: References: <4BD5B7FD.9040707@bryanfields.net> Message-ID: We've been using IPplan for about 5 years pretty effectively. It could use a UI refresh but it's decent. -J -------- Jason J. W. Williams, COO/CTO DigiTar williamsjj at digitar.com V: 208.343.8520 F: 208.322.8522 M: 208.863.0727 www.digitar.com On Apr 26, 2010, at 10:08 AM, Phil Regnauld wrote: > > > > On 26/04/2010, at 17.57, Bryan Fields wrote: > >> Is anyone running IPplan? http://iptrack.sourceforge.net/ I looked at it >> before, and at the time it's support of V6 was lacking. Is anyone running >> this in a SP environment with v6? >> >> Any other OSS tools for this people are using? > > Check out tipp: > > http://tipp.tobez.org/ > > There was a discussion thread on this topic not long ago here. > > Cheers, > Phil > > !SIG:4bd5badd162723911514005! > From lists at billfehring.com Mon Apr 26 11:16:09 2010 From: lists at billfehring.com (Bill Fehring) Date: Mon, 26 Apr 2010 09:16:09 -0700 Subject: IPAM In-Reply-To: References: <4BD5B7FD.9040707@bryanfields.net> Message-ID: >> Is anyone running IPplan? http://iptrack.sourceforge.net/ ?I looked at it >> before, and at the time it's support of V6 was lacking. ?Is anyone running >> this in a SP environment with v6? > Check out tipp: > http://tipp.tobez.org/ TIPP appears to not have IPv6 support at this time. Best, Bill From steve at ibctech.ca Mon Apr 26 11:17:39 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 26 Apr 2010 12:17:39 -0400 Subject: IPAM In-Reply-To: References: <4BD5B7FD.9040707@bryanfields.net> Message-ID: <4BD5BCA3.6040804@ibctech.ca> On 2010.04.26 12:13, Jason J. W. Williams wrote: > We've been using IPplan for about 5 years pretty effectively. It could use a UI refresh but it's decent. Does not do v6. Steve From jbates at brightok.net Mon Apr 26 11:20:04 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 26 Apr 2010 11:20:04 -0500 Subject: IPAM In-Reply-To: <4BD5BCA3.6040804@ibctech.ca> References: <4BD5B7FD.9040707@bryanfields.net> <4BD5BCA3.6040804@ibctech.ca> Message-ID: <4BD5BD34.30904@brightok.net> Steve Bertrand wrote: > On 2010.04.26 12:13, Jason J. W. Williams wrote: >> We've been using IPplan for about 5 years pretty effectively. It could use a UI refresh but it's decent. > > Does not do v6. > Their site says that the beta supports IPv6. Jack From mike.hertrick at neovera.com Mon Apr 26 11:27:22 2010 From: mike.hertrick at neovera.com (Michael Hertrick) Date: Mon, 26 Apr 2010 12:27:22 -0400 Subject: IPAM In-Reply-To: <4BD5B7FD.9040707@bryanfields.net> References: <4BD5B7FD.9040707@bryanfields.net> Message-ID: <4BD5BEEA.3060801@neovera.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bryan Fields wrote: > I've looked at infoblox, but we can't justify spending 400k at this point. > It's a lovely solution though. Same here... > Is anyone running IPplan? http://iptrack.sourceforge.net/ I looked at it > before, and at the time it's support of V6 was lacking. Is anyone running > this in a SP environment with v6? I've been using IPPlan for years, but it does not support IPv6 and looks like adding IPv6 support would be a lot of work. We haven't even attempted to add IPv6 support. > > Any other OSS tools for this people are using? I found netdot recently. It's a work in progress, but is coming along. IPAM (with v6 support) is just one component; it has a lot of other features and uses as well, too many to list here. Just check out the web site: http://netdot.uoregon.edu Regards, Michael Hertrick Neovera, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvVvucACgkQcJVdtfpkLb82AACglprWdb5k3pbs7vbQDPG7Fovo z0AAn35ijgLmaSZkIHuelXmoJAOArd1p =/9lB -----END PGP SIGNATURE----- From giulianocm at uol.com.br Mon Apr 26 11:31:48 2010 From: giulianocm at uol.com.br (GIULIANOCM (UOL)) Date: Mon, 26 Apr 2010 13:31:48 -0300 Subject: IPAM In-Reply-To: <4BD5B7FD.9040707@bryanfields.net> References: <4BD5B7FD.9040707@bryanfields.net> Message-ID: <4BD5BFF4.60701@uol.com.br> You can use: BLUECAT NETWORKS solution http://www.bluecatnetworks.com/ You can buy it in a VM mode or appliance mode. > I'm wondering what the service providers are using for IPAM. We are looking > at having to manage both v4 and v6 address space and delegate internally to > other people. > > I've looked at infoblox, but we can't justify spending 400k at this point. > It's a lovely solution though. > > Lucent has/had a product too, but having used it before it sucks. It's also > about 5x the cost of the info blox solution, and I'd rather not run solaris or > windows in production. > > Is anyone running IPplan? http://iptrack.sourceforge.net/ I looked at it > before, and at the time it's support of V6 was lacking. Is anyone running > this in a SP environment with v6? > > Any other OSS tools for this people are using? From sethm at rollernet.us Mon Apr 26 11:41:39 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 26 Apr 2010 09:41:39 -0700 Subject: IPAM In-Reply-To: <4BD5BD34.30904@brightok.net> References: <4BD5B7FD.9040707@bryanfields.net> <4BD5BCA3.6040804@ibctech.ca> <4BD5BD34.30904@brightok.net> Message-ID: <4BD5C243.5000106@rollernet.us> On 4/26/10 9:20 AM, Jack Bates wrote: > Steve Bertrand wrote: >> On 2010.04.26 12:13, Jason J. W. Williams wrote: >>> We've been using IPplan for about 5 years pretty effectively. It >>> could use a UI refresh but it's decent. >> >> Does not do v6. >> > > Their site says that the beta supports IPv6. > Interesting. I just dropped ipplan ("we will never support IPv6") and was trying out HaCi. Netdot was also on my list to try. ~Seth From alh-ietf at tndh.net Mon Apr 26 12:36:21 2010 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 26 Apr 2010 10:36:21 -0700 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <3DD429BD-FE58-4BE0-BF5A-17CC313DFF87@delong.com> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD5A12E.50907@sprunk.org> <3DD429BD-FE58-4BE0-BF5A-17CC313DFF87@delong.com> Message-ID: <03ed01cae566$fc721400$f5563c00$@net> While I appreciate Bill's attempt to raise attention to the draft, I needed to update it anyway with the intent to greatly simplify things and hopefully clarify at the same time. Given the interest level in this thread, I will ask for comments here before publishing the updated I-D. Replace intro paragraph 2 with: In any case, the prefixes defined here are not expected to appear in the routing system for the global Internet. A frequent question is how this prefix differs from a PI assignment. The simple answer is in expectation of global public routability. A PI assignment has the expectation that it could appear in the global DFZ, where a ULA-C registration is expected to be limited reach as service providers are free to, and expected to filter the entire FC00::/7 prefix as bogon space. The appropriate use of these prefixes is within a single network administration, or between privately interconnected networks that want to ensure that private communications do not accidentally get routed over the public Internet as might happen with PI. Replace section 3.2 & 3.3 with: Global IDs MUST be allocated under a single allocation and registration authority. The IAB SHOULD designate IANA as the registration authority. As policies differ around the world, IANA SHOULD delegate to the RIRs in a manner similar to the /12 approach used for the 2000::/3 prefix. The RIRs SHOULD establish registration policies which recognize that ULA-C prefixes are not a threat to the global DFZ, and therefore easier to justify. Organizations that don't want an ongoing relationship with the RIRs SHOULD be directed to RFC 4193. The requirements for ULA-C allocation and registrations are: - Globally Unique. - Available to anyone in an unbiased manner. - Available as a single prefix when justified to align subnet structures with PA or PI. Other clean up as necessary to align with this simplified text. The point is to remove as much policy as possible from the IETF text, and leave that to each region. Comments welcome, and to the extent they are operationally related to the DFZ could remain on nanog, but otherwise should be on the IETF 6man list. Tony > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Monday, April 26, 2010 8:33 AM > To: Stephen Sprunk > Cc: North American Noise and Off-topic Gripes > Subject: Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] > > > On Apr 26, 2010, at 7:20 AM, Stephen Sprunk wrote: > > > On 24 Apr 2010 21:01, Mark Smith wrote: > >> On Thu, 22 Apr 2010 01:48:18 -0400 > >> Christopher Morrow wrote: > >> > >>> On Wed, Apr 21, 2010 at 5:47 PM, Mark Smith > >>> wrote: > >>> > >>>> So what happens when you change providers? How are you going to > keep using globals that now aren't yours? > >>>> > >>> use pi space, request it from your local friendly RIR. > >>> > >> I was hoping that wasn't going to be your answer. So do you expect > every residential customer to get a PI from an RIR? > >> > > > > The vast majority of residential customers have no idea what > "globals" > > or "PI" are. They use PA and they're fine with that--despite being > > forcibly renumbered every few hours/days. (Many ISPs deliberately > tune > > their DHCP servers to give residential customers a different address > > each time for "market segmentation" reasons.) > > > The majority of residential cusotmers bitch about paying $20/month for > what they have and are not planning to multihome. > > This was a comment about multihoming. > > FWIW, this residential user has PI from an RIR (v4 and v6) and is > multihomed > using it. It works fine. > > > > The only semi-rational justification for ULA-C is that organizations > > privately internetworking with other organizations are scared of ULA- > R > > collisions. However, PI solves that problem just as readily. If one > > cannot afford or qualify for PI, or one wants a non-PI prefix due to > > delusions of better security, one can use a private deconfliction > > registry, e.g. . > > > The claim being made which I was attempting to refute had nothing to > do with residential. IT was that ULA-C with NAT at the border would > allow an organization to semi-transparently switch back and forth > between providers. This is a (somewhat) common practice in IPv4 > for delivering (degraded) multihoming. > > Owen From regnauld at nsrc.org Mon Apr 26 14:52:12 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Mon, 26 Apr 2010 21:52:12 +0200 Subject: IPAM In-Reply-To: <4BD5BEEA.3060801@neovera.com> References: <4BD5B7FD.9040707@bryanfields.net> <4BD5BEEA.3060801@neovera.com> Message-ID: <20100426195212.GB64420@macbook.catpipe.net> Michael Hertrick (mike.hertrick) writes: > > I found netdot recently. It's a work in progress, but is coming along. > IPAM (with v6 support) is just one component; it has a lot of other > features and uses as well, too many to list here. Just check out the > web site: > > http://netdot.uoregon.edu I'm working on a FreeBSD port of this one, which should make it much easier to install. Cheers, Phil From joly at punkcast.com Mon Apr 26 16:31:42 2010 From: joly at punkcast.com (Joly MacFie) Date: Mon, 26 Apr 2010 17:31:42 -0400 Subject: Books for the NOC guys... In-Reply-To: <20100403105237.GC31245@skywalker.creative.net.au> References: <86wrwqukcm.fsf@seastrom.com> <20100403105237.GC31245@skywalker.creative.net.au> Message-ID: I also grabbed the list http://isoc-ny.org/wiki/Networking Thanks to all who contributed. j On Sat, Apr 3, 2010 at 6:52 AM, Adrian Chadd wrote: > On Fri, Apr 02, 2010, Robert E. Seastrom wrote: > > > So, what are you having your up-and-coming NOC staff read? > > Since I thought this was worthwhile summarising, I've dumped > it on the mail topics page in the Wiki: > > http://nanog.cluepon.net/index.php/MailTopics > > I specifically left out the programming language related ranting. > > > Adrian > > -- --------------------------------------------------------------- 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 mansaxel at besserwisser.org Mon Apr 26 16:48:27 2010 From: mansaxel at besserwisser.org (Mans Nilsson) Date: Mon, 26 Apr 2010 23:48:27 +0200 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <20100425113106.6b12817c@opy.nosense.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> Message-ID: <20100426214827.GJ4960@besserwisser.org> Subject: Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] Date: Sun, Apr 25, 2010 at 11:31:06AM +0930 Quoting Mark Smith (nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org): > > > > > > So what happens when you change providers? How are you going to keep > > > using globals that now aren't yours? > > > > use pi space, request it from your local friendly RIR. > > > > I was hoping that wasn't going to be your answer. So do you expect > every residential customer to get a PI from an RIR? No, won't be necessary. Typical leases on v4 are extremely stable. I see no reason why they should be less so -- bar implementation hickups -- in v6. My "dynamic" v4 address of my Telia DSL at home has been the same for over a year. The ISP that messes this up will lose customers. As long as we use self-healing reasonably abstracted means of pointing out where our stuff is we'll easily survive renumbering should it occur. As long as the renumbering is less frequent than the TTL on the DNS records. For DLNA-like stuff, there is always FE80::/10, besides. The uniqueness of the unicast IP address is the key to its value and the means with which it enables us to build new stuff from which we make money. Corrupting the uniqueness requirement is devaluing the real reach and power of the IP address in search of shortsighted futile "gains" and is a practice any network professional should abstain from. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 As President I have to go vacuum my coin collection! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From marka at isc.org Mon Apr 26 17:00:42 2010 From: marka at isc.org (Mark Andrews) Date: Tue, 27 Apr 2010 08:00:42 +1000 Subject: Connectivity to an IPv6-only site In-Reply-To: Your message of "Mon, 26 Apr 2010 11:07:52 -0400." References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> <538D27E2-4771-4420-821D-BA8879B6822A@delong.com> <5598.1272031635@localhost> <201004231645.o3NGj5e5066388@drugs.dv.isc.org> <14793.1272042510@localhost> <4BD35F5B.8060904@brightok.net> <4BD5A473.9050309@sprunk.org> Message-ID: <201004262200.o3QM0geI013642@drugs.dv.isc.org> In message , Christopher Morrow writes: > On Mon, Apr 26, 2010 at 10:34 AM, Stephen Sprunk wrote= > : > > > Don't forget the hotspot vendor that returns an address of 0.0.0.1 for > > every A query if you have previously done an AAAA query for the same > > name (and timed out). =A0That's a fun one. > > so... aside from the every 3 months bitching on this list (and some on > v6ops maybe) about these sorts of things, what's happening to > tell/educate/warn/notice the hotspot-vendors that this sort of > practice (along with 'everything is at 1.1.1.1!') is just a bad plan? > How can users, even more advanced users, tell a hotspot vendor in a > meaningful way that their 'solution' is broken? > > -chris I periodically try to get the name of vendor and product identification about load balancer vendors that return broken DNS responses. This is after pointing out that the load balancer is broken and saying why I want it (to inform the vendor / warn others not to purchace a broken product). Invariably the administrator is too paranoid to supply the information. The best one can hope for is to have the operator contact their supplier. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From adrian at creative.net.au Mon Apr 26 22:11:07 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 27 Apr 2010 11:11:07 +0800 Subject: Books for the NOC guys... In-Reply-To: References: <86wrwqukcm.fsf@seastrom.com> <20100403105237.GC31245@skywalker.creative.net.au> Message-ID: <20100427031107.GG25706@skywalker.creative.net.au> On Mon, Apr 26, 2010, Joly MacFie wrote: > I also grabbed the list http://isoc-ny.org/wiki/Networking > > Thanks to all who contributed. Please feel free to add a link to the above url in the nanog wiki. > > j > > > On Sat, Apr 3, 2010 at 6:52 AM, Adrian Chadd wrote: > > > On Fri, Apr 02, 2010, Robert E. Seastrom wrote: > > > > > So, what are you having your up-and-coming NOC staff read? > > > > Since I thought this was worthwhile summarising, I've dumped > > it on the mail topics page in the Wiki: > > > > http://nanog.cluepon.net/index.php/MailTopics > > > > I specifically left out the programming language related ranting. > > > > > > Adrian > > > > > > > -- > --------------------------------------------------------------- > 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 > --------------------------------------------------------------- -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - From sthaug at nethelp.no Tue Apr 27 01:44:12 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 27 Apr 2010 08:44:12 +0200 (CEST) Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <20100426214827.GJ4960@besserwisser.org> References: <20100425113106.6b12817c@opy.nosense.org> <20100426214827.GJ4960@besserwisser.org> Message-ID: <20100427.084412.71099665.sthaug@nethelp.no> > > I was hoping that wasn't going to be your answer. So do you expect > > every residential customer to get a PI from an RIR? > > No, won't be necessary. Typical leases on v4 are extremely stable. I > see no reason why they should be less so -- bar implementation hickups > -- in v6. My "dynamic" v4 address of my Telia DSL at home has been the > same for over a year. The ISP that messes this up will lose customers. Agreed. We use a reasonable leasetime (24 hours) and let the DHCP server do its normal job. Which means that the client *will* get the same IPv4 address as long as nothing else changes (MAC-address, etc) - after all, that's what the RFC says. But we also need the ability to perform bulk moves of customers when an aggregation box fills up, and this is much easier if we *can* change the client IP address in connection with a bulk move. Thus we don't want to *guarantee* that the dynamic addresses are stable. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From packetgeek at yahoo.com Tue Apr 27 09:00:38 2010 From: packetgeek at yahoo.com (Charles Bronson) Date: Tue, 27 Apr 2010 07:00:38 -0700 (PDT) Subject: Starting up a WiMAX ISP Message-ID: <787457.18090.qm@web33403.mail.mud.yahoo.com> Looking for advice... I live in central / western New York state (think villages and farms). There are a good number of hills but no mountains. I have solid LAN experience and experience facing a smaller network to the Internet. I was network admin for a medium size enterprise network (I.e. design and implementation including LAN, Internet connectivity, VPN, routers, DNS, mail, webservers, physical servers, etc). I would like to build a local ISP that can serve high speed internet access to the more rural areas whose only option is dial up access, well away from the CO. It would also be nice to compete with the cable company and DSL for customers in the villages. I have been researching information for design / implementation of WiMAX, equipment suppliers, contractors to help with installation of tower equipment and acquiring tower space, but have been coming up empty handed. What resources are available to help me bridge the gap from where I am to what I need to know to get started and what specific technologies would you recommend I bone up on? I know beyond the WiMAX specific information, I will probably need to cozy up to BGP, maybe MPLS for traffic between the core and towers? Also do you have any suggestions on where I can find suppliers and service vendors in this field? Networks are my passion and am willing to dig in, but I need some direction. Thanks for you help an insight. Charles Bronson From lesmith at ecsis.net Tue Apr 27 09:19:03 2010 From: lesmith at ecsis.net (Larry Smith) Date: Tue, 27 Apr 2010 09:19:03 -0500 Subject: Starting up a WiMAX ISP In-Reply-To: <787457.18090.qm@web33403.mail.mud.yahoo.com> References: <787457.18090.qm@web33403.mail.mud.yahoo.com> Message-ID: <201004270919.03437.lesmith@ecsis.net> On Tue April 27 2010 09:00, Charles Bronson wrote: > Looking for advice... > > I live in central / western New York state (think villages and farms). > There are a good number of hills but no mountains. I have solid LAN > experience and experience facing a smaller network to the Internet. I was > network admin for a medium size enterprise network (I.e. design and > implementation including LAN, Internet connectivity, VPN, routers, DNS, > mail, webservers, physical servers, etc). I would like to build a local ISP > that can serve high speed internet access to the more rural areas whose > only option is dial up access, well away from the CO. It would also be nice > to compete with the cable company and DSL for customers in the villages. > > I have been researching information for design / implementation of WiMAX, > equipment suppliers, contractors to help with installation of tower > equipment and acquiring tower space, but have been coming up empty handed. > > What resources are available to help me bridge the gap from where I am to > what I need to know to get started and what specific technologies would you > recommend I bone up on? I know beyond the WiMAX specific information, I > will probably need to cozy up to BGP, maybe MPLS for traffic between the > core and towers? Also do you have any suggestions on where I can find > suppliers and service vendors in this field? Networks are my passion and am > willing to dig in, but I need some direction. > > Thanks for you help an insight. > > Charles Bronson Recommend you look at www.wispa.org (Wireless Internet Service Providers Association). Probably have loads of information and resources to get you pointed in the right direction... -- Larry Smith lesmith at ecsis.net From o.neghina at gmail.com Tue Apr 27 09:59:29 2010 From: o.neghina at gmail.com (Ovidiu Neghina) Date: Tue, 27 Apr 2010 17:59:29 +0300 Subject: Starting up a WiMAX ISP In-Reply-To: <201004270919.03437.lesmith@ecsis.net> References: <787457.18090.qm@web33403.mail.mud.yahoo.com> <201004270919.03437.lesmith@ecsis.net> Message-ID: Charles, That is not an easy journey. The radio part it itself is a dedicated department usually in a wireless operator(planning, coverage etc). Plus - how are you going to sustain this from buget perspective. Wimax is not future proof technology. All major wimax vendors have droped their support (alcatel - to name just one.). br Ovidiu On Tue, Apr 27, 2010 at 5:19 PM, Larry Smith wrote: > On Tue April 27 2010 09:00, Charles Bronson wrote: >> Looking for advice... >> >> I live in central / western New York state (think villages and farms). >> There are a good number of hills but no mountains. I have solid LAN >> experience and experience facing a smaller network to the Internet. I was >> network admin for a medium size enterprise network (I.e. design and >> implementation including LAN, Internet connectivity, VPN, routers, DNS, >> mail, webservers, physical servers, etc). I would like to build a local ISP >> that can serve high speed internet access to the more rural areas whose >> only option is dial up access, well away from the CO. It would also be nice >> to compete with the cable company and DSL for customers in the villages. >> >> I have been researching information for design / implementation of WiMAX, >> equipment suppliers, contractors to help with installation of tower >> equipment and acquiring tower space, but have been coming up empty handed. >> >> What resources are available to help me bridge the gap from where I am to >> what I need to know to get started and what specific technologies would you >> recommend I bone up on? I know beyond the WiMAX specific information, I >> will probably need to cozy up to BGP, maybe MPLS for traffic between the >> core and towers? Also do you have any suggestions on where I can find >> suppliers and service vendors in this field? Networks are my passion and am >> willing to dig in, but I need some direction. >> >> Thanks for you help an insight. >> >> ?Charles Bronson > > Recommend you look at www.wispa.org (Wireless Internet Service Providers > Association). ?Probably have loads of information and resources to get > you pointed in the right direction... > > -- > Larry Smith > lesmith at ecsis.net > > > From johnl at iecc.com Tue Apr 27 10:09:11 2010 From: johnl at iecc.com (John Levine) Date: 27 Apr 2010 15:09:11 -0000 Subject: Starting up a WiMAX ISP In-Reply-To: <787457.18090.qm@web33403.mail.mud.yahoo.com> Message-ID: <20100427150911.87703.qmail@joyce.lan> >I live in central / western New York state (think villages and farms). You might want to start by talking to Lightlink in Ithaca, which has been doing fixed wireless for years. R's, John From adam at nasa.gov Tue Apr 27 10:16:59 2010 From: adam at nasa.gov (Henson, Adam J. (ARC-IO)[PEROT SYSTEMS]) Date: Tue, 27 Apr 2010 10:16:59 -0500 Subject: Starting up a WiMAX ISP In-Reply-To: <787457.18090.qm@web33403.mail.mud.yahoo.com> References: <787457.18090.qm@web33403.mail.mud.yahoo.com> Message-ID: Firstly, there's a lot of "WiMAX specific information" to learn, so don't skimp on that. Beyond the basics of the protocol, you need to be familiar with RF engineering, installation and troubleshooting, along with FCC rules and regs.? I'm a WiFi engineer by day, and I've found that my understanding of it has greatly eased my introduction to WiMAX, so you may want to check out the CWNA primer if you're unfamiliar with things like EIRP, dB math and/or modulation/coding schemes.? As for equipment suppliers, we're currently evaluating a product from PureWave. Two other vendors would be Alvarion and Huawei.? As for towers, you may want to look at collapsible winch-based towers or similiar, if finding a climber in the sticks proves difficult. Running an ISP is a little different from an enterprise net. You need to think about things like billing, CALEA compliance, your support model, and the basics of running a business. WISP margins tend to be rather low, so you may find yourself wearing many hats. If you're not comfortable running a business, you can try finding a local entrepreneur, preferably who can fund you, to run that side of the house. The core network of your WISP should be as simple as possible while remaining robust. Think carefully about your needs and how to elegantly address them. This is critical to financial success. If you're in an environment with hills and nice lines of sight to many customers, you really should look at WiFi-based PTMP systems instead. They offer you a significant throughput enhancement at much-reduced cost, but do require LOS. Ubiquiti Networks makes some very low-cost gear that works amazingly, and they have some knowledgeable people in their forums. Alvarion also has an offering in this sector (BreezeAccess VL) but it's older, rather cumbersome and quite 'spensive.? You are more susceptible to interference with these systems, but you also have more channels to choose from. Finally, if you're out in the sticks and dialup's really the only option, you need to know about the Rural Utilities Service - USDA.gov/rus/ ? Adam Henson adam at nasa.gov ________________________________________ From: Charles Bronson [packetgeek at yahoo.com] Sent: Tuesday, April 27, 2010 7:00 AM To: nanog at nanog.org Subject: Starting up a WiMAX ISP Looking for advice... I live in central / western New York state (think villages and farms). There are a good number of hills but no mountains. I have solid LAN experience and experience facing a smaller network to the Internet. I was network admin for a medium size enterprise network (I.e. design and implementation including LAN, Internet connectivity, VPN, routers, DNS, mail, webservers, physical servers, etc). I would like to build a local ISP that can serve high speed internet access to the more rural areas whose only option is dial up access, well away from the CO. It would also be nice to compete with the cable company and DSL for customers in the villages. I have been researching information for design / implementation of WiMAX, equipment suppliers, contractors to help with installation of tower equipment and acquiring tower space, but have been coming up empty handed. What resources are available to help me bridge the gap from where I am to what I need to know to get started and what specific technologies would you recommend I bone up on? I know beyond the WiMAX specific information, I will probably need to cozy up to BGP, maybe MPLS for traffic between the core and towers? Also do you have any suggestions on where I can find suppliers and service vendors in this field? Networks are my passion and am willing to dig in, but I need some direction. Thanks for you help an insight. Charles Bronson From packetgeek at yahoo.com Tue Apr 27 10:43:47 2010 From: packetgeek at yahoo.com (Charles Bronson) Date: Tue, 27 Apr 2010 08:43:47 -0700 (PDT) Subject: Starting up a WiMAX ISP In-Reply-To: References: <787457.18090.qm@web33403.mail.mud.yahoo.com> Message-ID: <892926.15240.qm@web33401.mail.mud.yahoo.com> I have received a few responses along this line and figured I would pick one and answer all of them. To determine if it is financial sustainable, I will take the information on design and implementation to create a configuration. This will let me establish the fixed and recurring costs required to set up the core and then incremental costs (fixed hardware and recurring leases) per broadcast area. Then I can calculate how many customers I will need per broadcast area to bring up a broadcast site. This will give me general startup costs and let me build a customer count / biling rate table. Once I have those numbers I can beat the pavement and find out what people will pay for my service and then I will know based on my table if there is a snowball's chance in hell of this working. Charles Bronson ________________________________ From: Brandon Kim To: packetgeek at yahoo.com Sent: Tue, April 27, 2010 11:10:08 AM Subject: RE: Starting up a WiMAX ISP Interesting mission you have here. I'm in hudson valley region of NY. Have you done some research on the economics of this venture? Do you know if people would be willing to pay for higher speed internet access? Do you know if there are any gov't programs that can give you a grant to do this? > Date: Tue, 27 Apr 2010 07:00:38 -0700 > From: packetgeek at yahoo.com > Subject: Starting up a WiMAX ISP > To: nanog at nanog.org > > Looking for advice... > > I live in central / western New York state (think villages and farms). There are a good number of hills but no mountains. I have solid LAN experience and experience facing a smaller network to > the Internet. I was network admin for a medium size enterprise network (I.e. design and implementation including LAN, Internet connectivity, VPN, routers, DNS, mail, webservers, physical servers, etc). I would like to build a local ISP that can serve high speed internet access to the more rural areas whose only option is dial up access, well away from the CO. It would also be nice to compete with the cable company and DSL for customers in the villages. > > I have been researching information for design / implementation of WiMAX, equipment suppliers, contractors to help with installation of tower equipment and acquiring tower space, but have been coming up empty handed. > > What resources are available to help me bridge the gap from where I am to what I need to know to get started and what specific technologies would you recommend I bone up on? I know beyond the WiMAX specific information, I will probably need to cozy up to BGP, maybe MPLS for traffic between the core and towers? Also do you have any suggestions on where I can find suppliers and service vendors in this field? Networks are my passion and am willing to dig in, but I need some direction. > > Thanks for you help an insight. > > Charles Bronson > > > > From packetgeek at yahoo.com Tue Apr 27 10:46:51 2010 From: packetgeek at yahoo.com (Charles Bronson) Date: Tue, 27 Apr 2010 08:46:51 -0700 (PDT) Subject: Starting up a WiMAX ISP In-Reply-To: <20100427150911.87703.qmail@joyce.lan> References: <20100427150911.87703.qmail@joyce.lan> Message-ID: <138120.96249.qm@web33403.mail.mud.yahoo.com> That is a good idea. I would definitely be interested in working with the right people to extend their service as opposed to reinventing the wheel unless I don't like the wheel they invented. Charles Bronson ----- Original Message ---- From: John Levine To: nanog at nanog.org Cc: packetgeek at yahoo.com Sent: Tue, April 27, 2010 11:09:11 AM Subject: Re: Starting up a WiMAX ISP >I live in central / western New York state (think villages and farms). You might want to start by talking to Lightlink in Ithaca, which has been doing fixed wireless for years. R's, John From carlos at race.com Tue Apr 27 12:27:29 2010 From: carlos at race.com (Carlos Alcantar) Date: Tue, 27 Apr 2010 10:27:29 -0700 Subject: comcast enterprise/carrier services Message-ID: <859604546CD1FF488BDB6EA94C896AFBE0568C@racexchange.race.local> Looking for a sales contact for Comcast enterprise/carrier services for there Ethernet product thanks. Carlos Alcantar Race Telecommunications, Inc. 101 Haskins Way South San Francisco, CA 94080 P: 650.649.3550 x143 F: 650.649.3551 E: carlos (at) race.com From andy at nosignal.org Tue Apr 27 12:36:22 2010 From: andy at nosignal.org (Andy Davidson) Date: Tue, 27 Apr 2010 18:36:22 +0100 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> Message-ID: <20100427173622.GA24745@chilli.nosignal.org> On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote: >> Did you use Yahoo IM, AIM, or Skype? > Yes, yes, and yes. Works fine. What about every other service/protocol that users use today, and might be invented tomorrow ? Do & will they all work with NAT ? Do many others work as well or act reliably through NAT ? Will it stop or hamper the innovation of new services on the internet ? The answer to these questions isn't a good one for users, so as the community that are best placed to defend service quality and innovation by preserving the end to end principal, it is our responsibility to defend it to the best of our ability. So get busy - v6 awareness, availability and abundancy are overdue for our end users. Andy From malitsky at netabn.com Tue Apr 27 12:42:55 2010 From: malitsky at netabn.com (Michael Malitsky) Date: Tue, 27 Apr 2010 12:42:55 -0500 Subject: VPN over Comcast Message-ID: <79AF0C3901752A49881FE4CB31F7AA4001A16D06@abn-borg2.NETABN.LOCAL> I will probably be laughed at, but I'll ask just in case. We are having particularly bad luck trying to run VPN tunnels over Comcast cable in the Chicago area. The symptoms are basically complete loss of connectivity (lasting minutes to sometimes hours), or sometimes flapping for a period of time. More often than not, a reboot of the cable modem is required. The most interesting ones involve the following: a PIX or ASA configured as an EZvpn client, connecting to a 3000 concentrator, authentication over RADIUS. When I go to look at the RADIUS logs, I see connections from the same box with small intervals. Timeout is 8 hours, so theoretically I should see 3 connections in a 24-hr period. In some cases, I see dozens, in the most egregious cases, thousands over a 24-hour period. I am taking that as an indicator of a really unstable Comcast circuit. We have not had this problem with any other ISP, anywhere in the country. I am pretty much down to telling customers to find another provider... Any thoughts or ideas on the matter will be appreciated. PS. To be fair (?) to Comcast, this is not a ubiquitous problem. It affects about 25% of the installations I get to see. Sincerely, Michael Malitsky From toasty at dragondata.com Tue Apr 27 12:48:26 2010 From: toasty at dragondata.com (Kevin Day) Date: Tue, 27 Apr 2010 12:48:26 -0500 Subject: VPN over Comcast In-Reply-To: <79AF0C3901752A49881FE4CB31F7AA4001A16D06@abn-borg2.NETABN.LOCAL> References: <79AF0C3901752A49881FE4CB31F7AA4001A16D06@abn-borg2.NETABN.LOCAL> Message-ID: On Apr 27, 2010, at 12:42 PM, Michael Malitsky wrote: > I will probably be laughed at, but I'll ask just in case. > > We are having particularly bad luck trying to run VPN tunnels over > Comcast cable in the Chicago area. The symptoms are basically complete > loss of connectivity (lasting minutes to sometimes hours), or sometimes > flapping for a period of time. More often than not, a reboot of the > cable modem is required. The most interesting ones involve the > following: a PIX or ASA configured as an EZvpn client, connecting to a > 3000 concentrator, authentication over RADIUS. When I go to look at the > RADIUS logs, I see connections from the same box with small intervals. > Timeout is 8 hours, so theoretically I should see 3 connections in a > 24-hr period. In some cases, I see dozens, in the most egregious cases, > thousands over a 24-hour period. I am taking that as an indicator of a > really unstable Comcast circuit. We have not had this problem with any > other ISP, anywhere in the country. > I am pretty much down to telling customers to find another provider... > > Any thoughts or ideas on the matter will be appreciated. > > PS. To be fair (?) to Comcast, this is not a ubiquitous problem. It > affects about 25% of the installations I get to see. > > Sincerely, > Michael Malitsky > > We experienced the same thing, and switching from UDP tunnels to TCP tunnels fixed it. There are two things at play here. 1) The SMC modem/router that they insist you use for their "Small Business" cable internet service seems to have trouble with very high rates of non-TCP traffic going through its NAT. 2) Comcast rate limits non-TCP traffic somewhere on their network. Tunneling TCP inside TCP is a bad idea, but actually made the VPNs useful for us. Using IPSEC or UDP tunnels left us with tunnels that were rate limited to about 1mbps each way, until either the modem crashed or their network throttled us down to near useless speeds. I don't know if they're trying to stop customers from DoS'ing people or... exactly what the goal of it is, and couldn't ever get them to explain anything. From matthew at matthew.at Tue Apr 27 12:48:54 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 27 Apr 2010 10:48:54 -0700 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <20100427173622.GA24745@chilli.nosignal.org> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> Message-ID: <4BD72386.6010303@matthew.at> Andy Davidson wrote: > On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote: > >>> Did you use Yahoo IM, AIM, or Skype? >>> >> Yes, yes, and yes. Works fine. >> > > What about every other service/protocol that users use today, > and might be invented tomorrow ? Do & will they all work with > NAT ? > Anyone inventing a new service/protocol that doesn't work with NAT isn't planning on success. > Do many others work as well or act reliably through NAT ? > Yes. > Will it stop or hamper the innovation of new services on the > internet ? > Hasn't so far. > The answer to these questions isn't a good one for users, so > as the community that are best placed to defend service quality > and innovation by preserving the end to end principal, it is > our responsibility to defend it to the best of our ability. > Firewalls will always break the end-to-end principle, whether or not addresses are identical between the inside and outside or not. > So get busy - v6 awareness, availability and abundancy are > overdue for our end users. > Maybe. Most of them are perfectly happy. Matthew Kaufman From gladney at stsci.edu Tue Apr 27 13:02:01 2010 From: gladney at stsci.edu (gladney at stsci.edu) Date: Tue, 27 Apr 2010 18:02:01 +0000 Subject: VPN over Comcast Message-ID: <1601844665-1272391322-cardhu_decombobulator_blackberry.rim.net-603838399-@bda2079.bisx.prod.on.blackberry> Are you running IPSec over UDP? We've had problems in Maryland with IPSec over UDP to Comcast customer. Try switching to TCP. Gary ------Original Message------ From: Michael Malitsky To: nanog at nanog.org Subject: VPN over Comcast Sent: Apr 27, 2010 1:42 PM I will probably be laughed at, but I'll ask just in case. We are having particularly bad luck trying to run VPN tunnels over Comcast cable in the Chicago area. The symptoms are basically complete loss of connectivity (lasting minutes to sometimes hours), or sometimes flapping for a period of time. More often than not, a reboot of the cable modem is required. The most interesting ones involve the following: a PIX or ASA configured as an EZvpn client, connecting to a 3000 concentrator, authentication over RADIUS. When I go to look at the RADIUS logs, I see connections from the same box with small intervals. Timeout is 8 hours, so theoretically I should see 3 connections in a 24-hr period. In some cases, I see dozens, in the most egregious cases, thousands over a 24-hour period. I am taking that as an indicator of a really unstable Comcast circuit. We have not had this problem with any other ISP, anywhere in the country. I am pretty much down to telling customers to find another provider... Any thoughts or ideas on the matter will be appreciated. PS. To be fair (?) to Comcast, this is not a ubiquitous problem. It affects about 25% of the installations I get to see. Sincerely, Michael Malitsky Sent via BlackBerry from T-Mobile From nick at foobar.org Tue Apr 27 13:02:00 2010 From: nick at foobar.org (Nick Hilliard) Date: Tue, 27 Apr 2010 19:02:00 +0100 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD72386.6010303@matthew.at> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72386.6010303@matthew.at> Message-ID: <4BD72698.5030709@foobar.org> On 27/04/2010 18:48, Matthew Kaufman wrote: > Anyone inventing a new service/protocol that doesn't work with NAT isn't > planning on success. You mean, like multisession bgp over tls? Nick, just sayin' From johnl at iecc.com Tue Apr 27 13:09:40 2010 From: johnl at iecc.com (John R. Levine) Date: 27 Apr 2010 14:09:40 -0400 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <20100427173622.GA24745@chilli.nosignal.org> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> Message-ID: >>> Did you use Yahoo IM, AIM, or Skype? >> Yes, yes, and yes. Works fine. > > What about every other service/protocol that users use today, > and might be invented tomorrow ? Do & will they all work with > NAT ? Some do, some don't. My observation is that in practice the stuff that people do on consumer DSL works through NAT a lot better than the nanog conventional wisdom says it does. > Will it stop or hamper the innovation of new services on the > internet ? Like peer to peer phish bots? I certainly hope so. R's, John From Valdis.Kletnieks at vt.edu Tue Apr 27 13:15:39 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 27 Apr 2010 14:15:39 -0400 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: Your message of "Tue, 27 Apr 2010 10:48:54 PDT." <4BD72386.6010303@matthew.at> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72386.6010303@matthew.at> Message-ID: <19110.1272392139@localhost> On Tue, 27 Apr 2010 10:48:54 PDT, Matthew Kaufman said: > Anyone inventing a new service/protocol that doesn't work with NAT isn't > planning on success. Only true in the IPv4 world. IPv6 will hopefully be different. > > The answer to these questions isn't a good one for users, so > > as the community that are best placed to defend service quality > > and innovation by preserving the end to end principal, it is > > our responsibility to defend it to the best of our ability. > > > Firewalls will always break the end-to-end principle, whether or not > addresses are identical between the inside and outside or not. The difference is that if a protocol wants to be end-to-end, I can fix a firewall to not break it. You don't have that option with a NAT. > > So get busy - v6 awareness, availability and abundancy are > > overdue for our end users. > > > Maybe. Most of them are perfectly happy. Most of the US population was perfectly happy just before the recent financial crisis hit. Ignorance is bliss - but only for a little while. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From davei at otd.com Tue Apr 27 13:29:50 2010 From: davei at otd.com (Dave Israel) Date: Tue, 27 Apr 2010 14:29:50 -0400 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <20100427173622.GA24745@chilli.nosignal.org> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> Message-ID: <4BD72D1E.60506@otd.com> On 4/27/2010 1:36 PM, Andy Davidson wrote: > On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote: > >>> Did you use Yahoo IM, AIM, or Skype? >>> >> Yes, yes, and yes. Works fine. >> > What about every other service/protocol that users use today, > and might be invented tomorrow ? Do & will they all work with > NAT ? > Sure, I can invent a service/protocol that doesn't work with NAT. While I am at it, I'll make it not work with IPv4, IPv6, Ethernet, an architectures using less than 256 bits of memory addressing. I bet it'll be popular! > Do many others work as well or act reliably through NAT ? > Yes, nearly everything that end users use works great through NAT, because end users are often behind NAT and for a service to be popular, it has to be NAT-friendly. Protocols that are not NAT friendly and yet survive are generally LAN applications that are resting on their NAT-unferiendliness and calling it security. > Will it stop or hamper the innovation of new services on the > internet ? > Nope. > The answer to these questions isn't a good one for users, so > as the community that are best placed to defend service quality > and innovation by preserving the end to end principal, it is > our responsibility to defend it to the best of our ability. > The end to end principle only helps service quality and innovation when the services are built on an end to end model. In a client-server world where addresses only identify groups of endpoints and individual identification is done at higher layers (which is what the ipv4+NAT Internet is looking like), end to endness is an anomaly, not the norm. > So get busy - v6 awareness, availability and abundancy are > overdue for our end users. > Nearly all of the end users don't give a rat's hindquarters about ipv6. It gives them nothing they know that they want. Meanwhile, those who do know they want it are getting used to working around it, using PAT tricks and STUN services. Should people *have* to use those services? No. But there's so many other things that we shouldn't have to do, but we do anyway because that's how it works, that these NAT-circumvention tricks are not a dealbreaker. Meanwhile, the NATification of the Internet continuously increases the contrast between services (with real addresses) and clients (with shared addresses). Over time, this differentiation will increase and become more and more a standard (a de facto one if not an actual codified one.) Clients will have shared, ephemeral addresses, and services will have stable ones. This helps ensure that clients cannot generally communicate without a facilitating service, and every transaction will then have a middleman, somebody you have to pay somehow to get your services. You may pay in cash, by watching commercials, by sacrificing personal information, or by submitting your communciations to analysis by others, but somehow, you will pay. The vast majority of users won't care; they communicate that way now, and it does not bother them much. It's only those few who want to communicate without paying, in time, money, or privacy, or to communicate in ways other than the standard protocols, who will really suffer. And their complaints will have to fight against the voice of those who will say, well, if you make it end to end, then businesses lose money, and people will be able to share files again and violate copyrights, and all these things will cost jobs and tax dollars, etc, etc. If you want to avoid that future, I strongly suggest you deploy ipv6 and pressure others to do the same. But you're going to need to use valid arguments, about privacy and protection from the deprecations of unscrupulous middlemen, instead of insisting that the Internet will break down and die and locusts will descend from the heavens and eat our first born if we don't. -Dave From LarrySheldon at cox.net Tue Apr 27 13:32:48 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 27 Apr 2010 13:32:48 -0500 Subject: comcast enterprise/carrier services In-Reply-To: <859604546CD1FF488BDB6EA94C896AFBE0568C@racexchange.race.local> References: <859604546CD1FF488BDB6EA94C896AFBE0568C@racexchange.race.local> Message-ID: <4BD72DD0.6050703@cox.net> > Looking for a sales contact for Comcast enterprise/carrier services for > there Ethernet product thanks. "there" as contrasted with "here"? I don't understand. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From jlewis at lewis.org Tue Apr 27 13:37:08 2010 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 27 Apr 2010 14:37:08 -0400 (EDT) Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <19110.1272392139@localhost> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72386.6010303@matthew.at> <19110.1272392139@localhost> Message-ID: On Tue, 27 Apr 2010 Valdis.Kletnieks at vt.edu wrote: > The difference is that if a protocol wants to be end-to-end, I can fix a > firewall to not break it. You don't have that option with a NAT. Maybe we want end-to-end to break. Firewalls can trivially be misconfigured such that they're little more than routers, fully exposing all the hosts behind them to everything bad the internet has to offer (hackers, malware looking to spread itself, etc.). At least with NAT, if someone really screws up the config, the "inside" stuff is all typically on non-publicly-routed IPs, so the worst likely to happen is they lose internet, but at least the internet can't directly reach them. This has to be one of the bigger reasons people actually like using NAT. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From owen at delong.com Tue Apr 27 13:36:46 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Apr 2010 11:36:46 -0700 Subject: VPN over Comcast In-Reply-To: References: <79AF0C3901752A49881FE4CB31F7AA4001A16D06@abn-borg2.NETABN.LOCAL> Message-ID: <323E4F47-7850-4F1B-8EE0-C01AB2B89674@delong.com> On Apr 27, 2010, at 10:48 AM, Kevin Day wrote: > > On Apr 27, 2010, at 12:42 PM, Michael Malitsky wrote: > >> I will probably be laughed at, but I'll ask just in case. >> >> We are having particularly bad luck trying to run VPN tunnels over >> Comcast cable in the Chicago area. The symptoms are basically complete >> loss of connectivity (lasting minutes to sometimes hours), or sometimes >> flapping for a period of time. More often than not, a reboot of the >> cable modem is required. The most interesting ones involve the >> following: a PIX or ASA configured as an EZvpn client, connecting to a >> 3000 concentrator, authentication over RADIUS. When I go to look at the >> RADIUS logs, I see connections from the same box with small intervals. >> Timeout is 8 hours, so theoretically I should see 3 connections in a >> 24-hr period. In some cases, I see dozens, in the most egregious cases, >> thousands over a 24-hour period. I am taking that as an indicator of a >> really unstable Comcast circuit. We have not had this problem with any >> other ISP, anywhere in the country. >> I am pretty much down to telling customers to find another provider... >> >> Any thoughts or ideas on the matter will be appreciated. >> >> PS. To be fair (?) to Comcast, this is not a ubiquitous problem. It >> affects about 25% of the installations I get to see. >> >> Sincerely, >> Michael Malitsky >> >> > > We experienced the same thing, and switching from UDP tunnels to TCP tunnels fixed it. There are two things at play here. > > 1) The SMC modem/router that they insist you use for their "Small Business" cable internet service seems to have trouble with very high rates of non-TCP traffic going through its NAT. > If you have business class service, insist that they put the cablemodem in BRIDGE-ONLY mode. This will resolve this issue and eliminate the unnecessary NAT. > 2) Comcast rate limits non-TCP traffic somewhere on their network. > Comcast rate limits traffic in general. TCP is not less rate limited than anything else in my experience. Owen From owen at delong.com Tue Apr 27 13:41:05 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Apr 2010 11:41:05 -0700 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD72386.6010303@matthew.at> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72386.6010303@matthew.at> Message-ID: <63667EAD-622B-4A21-A794-6DBFCE091079@delong.com> On Apr 27, 2010, at 10:48 AM, Matthew Kaufman wrote: > Andy Davidson wrote: >> On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote: >> >>>> Did you use Yahoo IM, AIM, or Skype? >>>> >>> Yes, yes, and yes. Works fine. >>> >> >> What about every other service/protocol that users use today, and might be invented tomorrow ? Do & will they all work with NAT ? >> > > Anyone inventing a new service/protocol that doesn't work with NAT isn't planning on success. Respectfully, I disagree. There are many possible innovations that are available in a NAT-less world and it is desirable to get to that point rather than hamper future innovation with this obsolete baggage. >> Do many others work as well or act reliably through NAT ? >> > Yes. In reality, it's more like some yes, some not so much. >> Will it stop or hamper the innovation of new services on the >> internet ? >> > Hasn't so far. Here I have to call BS... I know of a number of cases where it has. >> The answer to these questions isn't a good one for users, so >> as the community that are best placed to defend service quality >> and innovation by preserving the end to end principal, it is our responsibility to defend it to the best of our ability. >> > Firewalls will always break the end-to-end principle, whether or not addresses are identical between the inside and outside or not. Yes and no. Firewalls will always break the idea of global universal end-to-end reachability. The do not break the end-to-end principle except when NAT is involved. The end-to-end principle is that the original layer 3+ information arrives at the layer 3 destination un-mangled by intermediate devices when it is a permitted type of traffic. Blocking unwanted flows does not break the end-to-end principle. Maiming and distorting data contained in the datagram, including the headers, on the other hand does break the end-to-end principle. >> So get busy - v6 awareness, availability and abundancy are >> overdue for our end users. >> > Maybe. Most of them are perfectly happy. > This word Most, it does not mean what you appear to think it means. Owen From Valdis.Kletnieks at vt.edu Tue Apr 27 13:47:26 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 27 Apr 2010 14:47:26 -0400 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: Your message of "Tue, 27 Apr 2010 14:37:08 EDT." References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72386.6010303@matthew.at> <19110.1272392139@localhost> Message-ID: <20861.1272394046@localhost> On Tue, 27 Apr 2010 14:37:08 EDT, Jon Lewis said: > Maybe we want end-to-end to break. > > Firewalls can trivially be misconfigured such that they're little more > than routers, fully exposing all the hosts behind them to everything bad > the internet has to offer (hackers, malware looking to spread itself, > etc.). > > At least with NAT, if someone really screws up the config, the "inside" > stuff is all typically on non-publicly-routed IPs, so the worst likely to > happen is they lose internet, but at least the internet can't directly > reach them. You *do* realize that the skill level needed to misconfigure a firewall into that state, and the skill level needed to do the exact same thing to a firewall-NAT box, are *both* less than the skill level needed to remember to also deploy traffic monitors so you know you screwed up, and host-based firewalls to guard against chuckleheads screwing up the border box? In other words, if your security scheme relies on that supposed feature of NAT, you have *other* things you need to be working on. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From matthew at matthew.at Tue Apr 27 13:49:26 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 27 Apr 2010 11:49:26 -0700 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <63667EAD-622B-4A21-A794-6DBFCE091079@delong.com> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72386.6010303@matthew.at> <63667EAD-622B-4A21-A794-6DBFCE091079@delong.com> Message-ID: <4BD731B6.6030505@matthew.at> Owen DeLong wrote: > On Apr 27, 2010, at 10:48 AM, Matthew Kaufman wrote: > > >> Andy Davidson wrote: >> >>> On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote: >>> >>> >>>>> Did you use Yahoo IM, AIM, or Skype? >>>>> >>>>> >>>> Yes, yes, and yes. Works fine. >>>> >>>> >>> What about every other service/protocol that users use today, and might be invented tomorrow ? Do & will they all work with NAT ? >>> >>> >> Anyone inventing a new service/protocol that doesn't work with NAT isn't planning on success. >> > > Respectfully, I disagree. There are many possible innovations that are available in a NAT-less world and it is desirable to get to that point rather than hamper future innovation with this obsolete baggage. > I would argue that every one of those innovations, if even passably useful, can also be implemented in a NAT-full world. > >>> Do many others work as well or act reliably through NAT ? >>> >>> >> Yes. >> > > In reality, it's more like some yes, some not so much. > == Some designed to work properly in the face of NAT, some ignored reality at their peril. > >>> Will it stop or hamper the innovation of new services on the >>> internet ? >>> >>> >> Hasn't so far. >> > > Here I have to call BS... I know of a number of cases where it has. > Ok, you called it... so where's the list of such services that haven't materialized as a result of NAT? Matthew Kaufman From jmkeller at houseofzen.org Tue Apr 27 13:51:06 2010 From: jmkeller at houseofzen.org (James M Keller) Date: Tue, 27 Apr 2010 14:51:06 -0400 Subject: VPN over Comcast In-Reply-To: <79AF0C3901752A49881FE4CB31F7AA4001A16D06@abn-borg2.NETABN.LOCAL> References: <79AF0C3901752A49881FE4CB31F7AA4001A16D06@abn-borg2.NETABN.LOCAL> Message-ID: <4BD7321A.2050009@houseofzen.org> On 4/27/2010 1:42 PM, Michael Malitsky wrote: > I will probably be laughed at, but I'll ask just in case. > > We are having particularly bad luck trying to run VPN tunnels over > Comcast cable in the Chicago area. The symptoms are basically complete > loss of connectivity (lasting minutes to sometimes hours), or sometimes > flapping for a period of time. More often than not, a reboot of the > cable modem is required. The most interesting ones involve the > following: a PIX or ASA configured as an EZvpn client, connecting to a > 3000 concentrator, authentication over RADIUS. When I go to look at the > RADIUS logs, I see connections from the same box with small intervals. > Timeout is 8 hours, so theoretically I should see 3 connections in a > 24-hr period. In some cases, I see dozens, in the most egregious cases, > thousands over a 24-hour period. I am taking that as an indicator of a > really unstable Comcast circuit. We have not had this problem with any > other ISP, anywhere in the country. > I am pretty much down to telling customers to find another provider... > > Any thoughts or ideas on the matter will be appreciated. > > PS. To be fair (?) to Comcast, this is not a ubiquitous problem. It > affects about 25% of the installations I get to see. > > Sincerely, > Michael Malitsky > > > > I ran into issues in various Comcast serviced regions with SSL VPN over tcp-443. From testing we started getting drops or severe rate limits on the flow after 7-10 minutes. Best guess was it was anti-p2p systems throttling encrypted/unknown protocol traffic after a set timer. Disconnecting and reconnecting pushed performance back up to normal until the timer kicked in again. We ended up setting the SSL tunnel to re-key via new sessions every 5 minutes to keep the flow shorter then the observed timer intervals. Other then running into a Cisco AnyConnect client bug (the app would steal focus at the re-keys) worked around the issue on Comcast and even some FiOS end users. -- --- James M Keller From jlewis at lewis.org Tue Apr 27 13:54:07 2010 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 27 Apr 2010 14:54:07 -0400 (EDT) Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <20861.1272394046@localhost> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72386.6010303@matthew.at> <19110.1272392139@localhost> <20861.1272394046@localhost> Message-ID: On Tue, 27 Apr 2010 Valdis.Kletnieks at vt.edu wrote: >> At least with NAT, if someone really screws up the config, the "inside" >> stuff is all typically on non-publicly-routed IPs, so the worst likely to >> happen is they lose internet, but at least the internet can't directly >> reach them. > > You *do* realize that the skill level needed to misconfigure a firewall > into that state, and the skill level needed to do the exact same thing to > a firewall-NAT box, are *both* less than the skill level needed to remember > to also deploy traffic monitors so you know you screwed up, and host-based > firewalls to guard against chuckleheads screwing up the border box? I think you forget where most networking is done. Monitoring? You mean something beyond walking down the hall to the network closet and seeing all the blinking lights are flashing really fast? How about the typical home DSL/Cable modem user? Do you think they even know what SNMP is? Do you think they have host based firewalls on all their PCs? Do you want mom and dad's PCs exposed on the internet, or neatly hidden behind a NAT device they don't even realize is built into their cable/DSL router? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From schilling2006 at gmail.com Tue Apr 27 13:56:04 2010 From: schilling2006 at gmail.com (schilling) Date: Tue, 27 Apr 2010 14:56:04 -0400 Subject: VPN over Comcast In-Reply-To: <323E4F47-7850-4F1B-8EE0-C01AB2B89674@delong.com> References: <79AF0C3901752A49881FE4CB31F7AA4001A16D06@abn-borg2.NETABN.LOCAL> <323E4F47-7850-4F1B-8EE0-C01AB2B89674@delong.com> Message-ID: http://ckdake.com/content/2008/disable-gateway-smart-packet-detection.html showed a feature of "Gateway Smart Packet Detection" in some SMC cable modem. The current solution is to identify the affected Comcast modem, and ask Comcast engineer to turn that "IDS" feature off remotely. I spend several days to talk with comcast about our blackboard will not work sometimes in some shared business class residential building. Finally got hold of a Regional Engineer to confess this with my tcpdump proof. Local comcast engineer may not be aware of this feature. Schilling On Tue, Apr 27, 2010 at 2:36 PM, Owen DeLong wrote: > > On Apr 27, 2010, at 10:48 AM, Kevin Day wrote: > >> >> On Apr 27, 2010, at 12:42 PM, Michael Malitsky wrote: >> >>> I will probably be laughed at, but I'll ask just in case. >>> >>> We are having particularly bad luck trying to run VPN tunnels over >>> Comcast cable in the Chicago area. ?The symptoms are basically complete >>> loss of connectivity (lasting minutes to sometimes hours), or sometimes >>> flapping for a period of time. ?More often than not, a reboot of the >>> cable modem is required. ?The most interesting ones involve the >>> following: a PIX or ASA configured as an EZvpn client, connecting to a >>> 3000 concentrator, authentication over RADIUS. ?When I go to look at the >>> RADIUS logs, I see connections from the same box with small intervals. >>> Timeout is 8 hours, so theoretically I should see 3 connections in a >>> 24-hr period. ?In some cases, I see dozens, in the most egregious cases, >>> thousands over a 24-hour period. ?I am taking that as an indicator of a >>> really unstable Comcast circuit. ?We have not had this problem with any >>> other ISP, anywhere in the country. >>> I am pretty much down to telling customers to find another provider... >>> >>> Any thoughts or ideas on the matter will be appreciated. >>> >>> PS. ?To be fair (?) to Comcast, this is not a ubiquitous problem. ?It >>> affects about 25% of the installations I get to see. >>> >>> Sincerely, >>> Michael Malitsky >>> >>> >> >> We experienced the same thing, and switching from UDP tunnels to TCP tunnels fixed it. There are two things at play here. >> >> 1) The SMC modem/router that they insist you use for their "Small Business" cable internet service seems to have trouble with very high rates of non-TCP traffic going through its NAT. >> > If you have business class service, insist that they put the cablemodem in BRIDGE-ONLY mode. ?This will resolve this issue and eliminate the unnecessary NAT. > >> 2) Comcast rate limits non-TCP traffic somewhere on their network. >> > Comcast rate limits traffic in general. TCP is not less rate limited than anything else in my > experience. > > Owen > > > From jared at puck.nether.net Tue Apr 27 14:03:12 2010 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 27 Apr 2010 15:03:12 -0400 Subject: VPN over Comcast In-Reply-To: References: <79AF0C3901752A49881FE4CB31F7AA4001A16D06@abn-borg2.NETABN.LOCAL> <323E4F47-7850-4F1B-8EE0-C01AB2B89674@delong.com> Message-ID: <836C4CB2-494B-4EB6-9243-F25154D1343B@puck.nether.net> You can get into the SMC device yourself by going to the http://10.1.10.1/login.asp link on the SMC. The username/password are well known as cusadmin/highspeed. I also recommend against using the integrated services in the device if at all possible. It's also mildly annoying that it does not respond to traceroute either when it's your gateway with a pool of static ips. I did have one case where it reverted to a mode where it ran dhcp/nat but that was shortlived and has not happened again. - Jared On Apr 27, 2010, at 2:56 PM, schilling wrote: > http://ckdake.com/content/2008/disable-gateway-smart-packet-detection.html > showed a feature of "Gateway Smart Packet Detection" in some SMC > cable modem. > > > > The current solution is to identify the affected Comcast modem, and ask > Comcast engineer to turn that "IDS" feature off remotely. > > I spend several days to talk with comcast about our blackboard will > not work sometimes in some shared business class residential building. > Finally got hold of a Regional Engineer to confess this with my > tcpdump proof. Local comcast engineer may not be aware of this > feature. > > > Schilling > > On Tue, Apr 27, 2010 at 2:36 PM, Owen DeLong wrote: >> >> On Apr 27, 2010, at 10:48 AM, Kevin Day wrote: >> >>> >>> On Apr 27, 2010, at 12:42 PM, Michael Malitsky wrote: >>> >>>> I will probably be laughed at, but I'll ask just in case. >>>> >>>> We are having particularly bad luck trying to run VPN tunnels over >>>> Comcast cable in the Chicago area. The symptoms are basically complete >>>> loss of connectivity (lasting minutes to sometimes hours), or sometimes >>>> flapping for a period of time. More often than not, a reboot of the >>>> cable modem is required. The most interesting ones involve the >>>> following: a PIX or ASA configured as an EZvpn client, connecting to a >>>> 3000 concentrator, authentication over RADIUS. When I go to look at the >>>> RADIUS logs, I see connections from the same box with small intervals. >>>> Timeout is 8 hours, so theoretically I should see 3 connections in a >>>> 24-hr period. In some cases, I see dozens, in the most egregious cases, >>>> thousands over a 24-hour period. I am taking that as an indicator of a >>>> really unstable Comcast circuit. We have not had this problem with any >>>> other ISP, anywhere in the country. >>>> I am pretty much down to telling customers to find another provider... >>>> >>>> Any thoughts or ideas on the matter will be appreciated. >>>> >>>> PS. To be fair (?) to Comcast, this is not a ubiquitous problem. It >>>> affects about 25% of the installations I get to see. >>>> >>>> Sincerely, >>>> Michael Malitsky >>>> >>>> >>> >>> We experienced the same thing, and switching from UDP tunnels to TCP tunnels fixed it. There are two things at play here. >>> >>> 1) The SMC modem/router that they insist you use for their "Small Business" cable internet service seems to have trouble with very high rates of non-TCP traffic going through its NAT. >>> >> If you have business class service, insist that they put the cablemodem in BRIDGE-ONLY mode. This will resolve this issue and eliminate the unnecessary NAT. >> >>> 2) Comcast rate limits non-TCP traffic somewhere on their network. >>> >> Comcast rate limits traffic in general. TCP is not less rate limited than anything else in my >> experience. >> >> Owen >> >> >> > From owen at delong.com Tue Apr 27 14:13:48 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Apr 2010 12:13:48 -0700 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD731B6.6030505@matthew.at> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72386.6010303@matthew.at> <63667EAD-622B-4A21-A794-6DBFCE091079@delong.com> <4BD731B6.6030505@matthew.at> Message-ID: <5005DE88-68DD-44F7-8154-5448D33D7F3F@delong.com> On Apr 27, 2010, at 11:49 AM, Matthew Kaufman wrote: > Owen DeLong wrote: >> On Apr 27, 2010, at 10:48 AM, Matthew Kaufman wrote: >> >> >>> Andy Davidson wrote: >>> >>>> On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote: >>>> >>>>>> Did you use Yahoo IM, AIM, or Skype? >>>>>> >>>>> Yes, yes, and yes. Works fine. >>>>> >>>> What about every other service/protocol that users use today, and might be invented tomorrow ? Do & will they all work with NAT ? >>>> >>> Anyone inventing a new service/protocol that doesn't work with NAT isn't planning on success. >>> >> >> Respectfully, I disagree. There are many possible innovations that are available in a NAT-less world and it is desirable to get to that point rather than hamper future innovation with this obsolete baggage. >> > I would argue that every one of those innovations, if even passably useful, can also be implemented in a NAT-full world. Perhaps, but, often at significant additional code, development time, QA resources and other costs. Also, often at a degraded level requiring a non-NAT'd third-party broker to intermediate between any two NAT'd parties attempting to trade information. >> >>>> Do many others work as well or act reliably through NAT ? >>>> >>> Yes. >>> >> >> In reality, it's more like some yes, some not so much. >> > == Some designed to work properly in the face of NAT, some ignored reality at their peril. We can agree to disagree about this. The reality is that there are cool things you can do with peer to peer networking that simply aren't possible in an enforced client-server model. NAT enforces a client-server model and permanently and irrevocably relegates some administrative domains to the client role. This is an unfair disadvantage to the users within those domains when it is not by the choice of the administrator (and NAT in IPv4 so far, often is not). >> >>>> Will it stop or hamper the innovation of new services on the >>>> internet ? >>>> >>> Hasn't so far. >>> >> >> Here I have to call BS... I know of a number of cases where it has. >> > Ok, you called it... so where's the list of such services that haven't materialized as a result of NAT? > Haven't materialized, for one, is an attempt to redefine the question. Note that the original question included "hamper". I would argue that the cost of maintaining a NAT compatibility lab and the QA staff to use it is a sufficient burden to call it "hamper". For the ones that did not materialize, however, I am at an unfortunate disadvantage in the argument. I can tell you that I know of at least 5 such cases. However, I cannot reveal the details because I am under NDA to the companies that were developing these products. I can tell you that in 3 of the 5 cases, adapting them to cope with a NAT world would have required the company to run an external service in perpetuity (or at least so long as the application would function, no server, no function) in order to do the match-making between clients that could not directly reach each-other. I guess a good analogy is this: In a NAT world, you have only matchmaking services and all of your ability to meet potential mates is strictly controlled through these matchmaking services. There are many services available independent of each other, and, each has its own limitations, biases, and quirks. However, you cannot meet potential mates without involving at least one matchmaker. In a NAT-Free world, you have the ability to use a matchmaking service if you like, but, you also have the ability to meet potential mates at bars, in the grocery store, on the street, in restaurants, through chance meetings, introductions by a friend, or even at work. It is possible that if you never knew it was possible to meet potential mates in all of these other ways, you would happily deal with a vast number of matchmaking services hoping to find a useful result. On the other hand, if you were to ask the average person who has experienced the latter scenario if they would be willing to limit their choices to only using a dating service, my guess would be that most people would reject the idea outright. Owen From surfer at mauigateway.com Tue Apr 27 14:29:29 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 27 Apr 2010 12:29:29 -0700 Subject: comcast enterprise/carrier services Message-ID: <20100427122929.2920BAD2@resin14.mta.everyone.net> --- carlos at race.com wrote: From: "Carlos Alcantar" Looking for a sales contact for Comcast enterprise/carrier services for there Ethernet product thanks. -------------------------------------- Please, please, PLEASE do not encourage sales droids like this. It is evident to me you have never been hounded to death by the droids trolling this list. As usual, I encourage everyone to tell any droids that you absolutely will not buy from them when they contact you from your NANOG postings. I have gone through it many times over the years and always get to the point of yelling in email "WHAT PART OF NO DO YOU NOT UNDERSTAND!" before they finally stop. My apologies for yelling, but I want to get the point across that if we encourage them the list value is decreased by orders (plural) of magnitude. scott From ipv3.com at gmail.com Tue Apr 27 15:02:52 2010 From: ipv3.com at gmail.com (IPv3.com) Date: Tue, 27 Apr 2010 15:02:52 -0500 Subject: NANOG Operational Audit of IPv4+ End-to-End L3 Transport in North America Message-ID: NANOG Operational Audit of IPv4+ End-to-End L3 Transport in North America 1. To deploy and operate a network there may be network elements (aka NATs) that are used by network operators to upgrade versions & to help with audits. 2. L3 "End-to-End" is only part of the story. What about Hop Count ? Lag Latency...band-width 3. In North America the Customer DeMarc is commonly to a Linux-based CPE Router (WRT-54GL is one example) 4. For FCC purposes and other audits, the DeMarc for L3 IPv4+ has to be consistent to avoid comparing apples and oranges. 5. It may be that large parts of the IPv4+ Spectrum allocated to North America no longer qualifies as part of the L3 End-to-End Transport (and never did?). http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml 6. Before ISPs run off chasing the IPv6 Brokers-duJour, it may be prudent to first make sure their IPv4+ networks still are part of the L3 End-to-End Transport. NANOG Operational Audit of IPv4+ End-to-End L3 Transport in North America From justin at justinshore.com Tue Apr 27 15:07:05 2010 From: justin at justinshore.com (Justin Shore) Date: Tue, 27 Apr 2010 15:07:05 -0500 Subject: NANOG Operational Audit of IPv4+ End-to-End L3 Transport in North America In-Reply-To: References: Message-ID: <4BD743E9.9010403@justinshore.com> On 4/27/2010 3:02 PM, IPv3.com wrote: > NANOG Operational Audit of IPv4+ End-to-End L3 Transport in North America I haven't been keeping up with NANOG in a while so perhaps I missed the discussion and/or memo. I take it that this spammer is still being allowed to send his shit to the mailing list? Justin From Valdis.Kletnieks at vt.edu Tue Apr 27 15:31:05 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 27 Apr 2010 16:31:05 -0400 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: Your message of "Tue, 27 Apr 2010 14:54:07 EDT." References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72386.6010303@matthew.at> <19110.1272392139@localhost> <20861.1272394046@localhost> Message-ID: <26157.1272400265@localhost> On Tue, 27 Apr 2010 14:54:07 EDT, Jon Lewis said: > I think you forget where most networking is done. Monitoring? You mean > something beyond walking down the hall to the network closet and seeing > all the blinking lights are flashing really fast? That site will manage to chucklehead their config whether or not it's NAT'ed. > How about the typical home DSL/Cable modem user? And they won't manage to chucklehead their config, even if it's not NAT'ed. > Do you think they even > know what SNMP is? Do you think they have host based firewalls on all > their PCs? Hmm... Linux has a firewall. MacOS has a firewall. Windows XP SP2 or later has a perfectly functional firewall out of the box, and earlier Windows had a firewall but it didn't do 'default deny inbound' out of the box. Those people with XBoxes and Playstations and so on can take it up with their vendors - they were certainly *marketed* as "plug it in and network", and at least my PS/2 and PS/3 didn't come with a "Warning: Do Not Use Without a NAT" sticker on them. So who doesn't have a host-based firewall in 2010? The idea is old enough that it's *really* time to play name-and-blame. > Do you want mom and dad's PCs exposed on the internet, or > neatly hidden behind a NAT device they don't even realize is built into > their cable/DSL router? Be careful here - I know that at least in my neck of Comcast cable, you can go to Best Buy, get a cablemodem, plug the cable in one side, plug an ethernet and one machine in the other side, and be handed a live on-the-network DHCP address that works just fine except for outbound port 25 being blocked. For the past month or so, my laptop has gotten 71.63.92.124 every night when I get home, which certainly doesn't look very NAT'ed. Are you *really* trying to suggest that a PC is not fit-for-purpose for that usage, and *requires* a NAT and other hand-holding? And for the record - I don't worry about my mother's PC being exposed on the Internet, because she's running Vista, which has a sane firewall by default. What *does* worry me is that she's discovered Facebook, and anything she clicks on there will not have the *slightest* bit of trouble whomping her machine through a NAT. Let's be realistic - what was the last time we had a *real* threat that a NAT would have stopped but the XP SP2 firewall would not have stopped? And how many current threats do we have that are totally NAT-agnostic? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From deleskie at gmail.com Tue Apr 27 15:34:07 2010 From: deleskie at gmail.com (deleskie at gmail.com) Date: Tue, 27 Apr 2010 20:34:07 +0000 Subject: comcast enterprise/carrier services Message-ID: <771120781-1272400448-cardhu_decombobulator_blackberry.rim.net-266406989-@bda005.bisx.prod.on.blackberry> I'm wondering how can someone recomend a vendor for X be diffrent from, Can someone recond a box that does Y. I'm no fan of blind calls from sales droids anymore more then the next person but I see this posting as relevant or more then many post here. ------Original Message------ From: Scott Weeks To: nanog at nanog.org ReplyTo: surfer at mauigateway.com Subject: Re: comcast enterprise/carrier services Sent: Apr 27, 2010 4:29 PM --- carlos at race.com wrote: From: "Carlos Alcantar" Looking for a sales contact for Comcast enterprise/carrier services for there Ethernet product thanks. -------------------------------------- Please, please, PLEASE do not encourage sales droids like this. It is evident to me you have never been hounded to death by the droids trolling this list. As usual, I encourage everyone to tell any droids that you absolutely will not buy from them when they contact you from your NANOG postings. I have gone through it many times over the years and always get to the point of yelling in email "WHAT PART OF NO DO YOU NOT UNDERSTAND!" before they finally stop. My apologies for yelling, but I want to get the point across that if we encourage them the list value is decreased by orders (plural) of magnitude. scott Sent from my BlackBerry device on the Rogers Wireless Network From surfer at mauigateway.com Tue Apr 27 15:47:29 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 27 Apr 2010 13:47:29 -0700 Subject: comcast enterprise/carrier services Message-ID: <20100427134729.2920ABFF@resin14.mta.everyone.net> --- carlos at race.com wrote: Looking for a sales contact for Comcast enterprise/carrier services for ------Original Message------ From: Scott Weeks Please, please, PLEASE do not encourage sales droids like this. --- deleskie at gmail.com wrote: ------ I'm wondering how can someone recomend a vendor for X be diffrent from, Can someone recond a box that does Y. I'm no fan of blind calls from sales droids anymore more then the next person but I see this posting as relevant or more then many post here. ----------------------------------------------------- He is not asking for a vendor comparison from list members. He is asking Comcast sales lurkers to contact him. Otherwise, he would've gone to http://business.comcast.com/ethernet/dedicated-internet.aspx and found the info there. scott From jeroen at mompl.net Tue Apr 27 15:56:37 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Tue, 27 Apr 2010 13:56:37 -0700 Subject: iabelle francois In-Reply-To: <1271997180.3980.413.camel@ubuntu.ubuntu-domain> References: <4BCF8336.4020102@mompl.net> <4BD1128D.5090505@acm.org> <1271997180.3980.413.camel@ubuntu.ubuntu-domain> Message-ID: <4BD74F85.4070508@mompl.net> Ted Cooper wrote: > On Thu, 2010-04-22 at 23:22 -0400, Eric Carroll wrote: >> On 10-04-21 06:59 PM, Jeroen van Aart wrote: >>> The url redirects to a Canadian med site. >> Just FYI, it's not a real Canadian med site. It is high probability >> not >> even Canadian. > > Posting so many URLs which either are or should be listed in domain > block lists to a list with as many subscribers as this is probably not > wise. I'm guessing you just caused a wonderful bounce storm as the NANOG > servers attempted to send that out, depending of course on how many > people whitelist NANOG to URI filtering. I would say one has their spamfilter configured incorrectly if such emails would be rejected and it should prompt an immediate fix. The mailinglist should ideally be whitelisted. In addition if you use content scanning (in almost all cases a bad idea, see: http://news.bbc.co.uk/2/hi/technology/8528672.stm ) your scanners ought to be trained well enough to figure out the email is not spam. Regards, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ From jlewis at lewis.org Tue Apr 27 16:25:18 2010 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 27 Apr 2010 17:25:18 -0400 (EDT) Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <26157.1272400265@localhost> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72386.6010303@matthew.at> <19110.1272392139@localhost> <20861.1272394046@localhost> <26157.1272400265@localhost> Message-ID: On Tue, 27 Apr 2010 Valdis.Kletnieks at vt.edu wrote: > That site will manage to chucklehead their config whether or not it's NAT'ed. True...but when they do it and all their important stuff is in 192.168.0/24, you still can't reach it...and if they break NAT, at least their internet breaks. i.e. they'll know its broken. When they change the default policy on the firewall to Accept/Allow all, everything will still work...until all their machines are infected with enough stuff to break them. > Hmm... Linux has a firewall. MacOS has a firewall. Windows XP SP2 or later > has a perfectly functional firewall out of the box, and earlier Windows had > a firewall but it didn't do 'default deny inbound' out of the box. Linux can have a firewall. Not all distros default to having any rules. XP can (if you want to call it that). I don't have any experience with MacOS. Both my kids run Win2k (to support old software that doesn't run well/at all post-2k). I doubt that's all that unusual. > Are you *really* trying to suggest that a PC is not fit-for-purpose > for that usage, and *requires* a NAT and other hand-holding? Here's an exercise. Wipe a PC. Put it on that cable modem with no firewall. Install XP on it. See if you can get any service packs installed before the box is infected. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From owen at delong.com Tue Apr 27 17:24:47 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Apr 2010 15:24:47 -0700 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72386.6010303@matthew.at> <19110.1272392139@localhost> <20861.1272394046@localhost> <26157.1272400265@localhost> Message-ID: <6109E1B3-E845-4111-966A-0613338D6719@delong.com> On Apr 27, 2010, at 2:25 PM, Jon Lewis wrote: > On Tue, 27 Apr 2010 Valdis.Kletnieks at vt.edu wrote: > >> That site will manage to chucklehead their config whether or not it's NAT'ed. > > True...but when they do it and all their important stuff is in 192.168.0/24, you still can't reach it...and if they break NAT, at least their internet breaks. i.e. they'll know its broken. When they change the default policy on the firewall to Accept/Allow all, everything will still work...until all their machines are infected with enough stuff to break them. > Nah... They'll chucklehead forward something to 135-139/TCP on the box with all the important stuff just fine. NAT won't save them from this. >> Hmm... Linux has a firewall. MacOS has a firewall. Windows XP SP2 or later >> has a perfectly functional firewall out of the box, and earlier Windows had >> a firewall but it didn't do 'default deny inbound' out of the box. > > Linux can have a firewall. Not all distros default to having any rules. XP can (if you want to call it that). I don't have any experience with MacOS. Both my kids run Win2k (to support old software that doesn't run well/at all post-2k). I doubt that's all that unusual. > And the rest of the world should pay for your kid's legacy requirements why? >> Are you *really* trying to suggest that a PC is not fit-for-purpose >> for that usage, and *requires* a NAT and other hand-holding? > > Here's an exercise. Wipe a PC. Put it on that cable modem with no firewall. Install XP on it. See if you can get any service packs installed before the box is infected. > 1. Yes, I can. I simply didn't put an IPv4 address on it. ;-) 2. I wouldn't hold XP up as the gold standard of hosts here. Owen From mysidia at gmail.com Tue Apr 27 18:36:32 2010 From: mysidia at gmail.com (James Hess) Date: Tue, 27 Apr 2010 18:36:32 -0500 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100420145332.58995.qmail@joyce.lan> <20100427173622.GA24745@chilli.nosignal.org> <4BD72386.6010303@matthew.at> <19110.1272392139@localhost> <20861.1272394046@localhost> <26157.1272400265@localhost> Message-ID: On Tue, Apr 27, 2010 at 4:25 PM, Jon Lewis wrote: > breaks. ?i.e. they'll know its broken. ?When they change the default policy > on the firewall to Accept/Allow all, everything will still work...until all > their machines are infected with enough stuff to break them. The same is true with IPv4 + NAT, in terms of real-world net security. Because security attacks against end-user equipment commonly come from either an e-mail message the user is expected to errantly click on, or a malicious website, designed to exploit the latest $MsOffice_Acrobat_Javascript_OR_Flash_Vuln_DU_Jour. If user accidentally turns off their outbound filtering software, even the IPv4 user behind a NAT setup still have a pretty bad security posture. Fortunately, the IPv6 address space is so large and sparse, that scanning it would be quite a feat, even if a random outside attacker already knew for a fact that a certain /64 probably contains a vulnerable host. Scanning IPv6 addresses by brute force, is as computationally hard as figuring out the 16-bit port number pairs of an IPv4 NAT user's open connection, in order to fool their NAT device and partially hijack the user's HTTP connection and inject malicious code into their stream. By the way, if an attacker actually can figure out the port number pairs of a session recognized by the NAT device, the illusion of "security" offered by the NAT setup potentially starts to crumble.... either way it's 32-bits to be guessed within a fairly limited timeframe. -- -J From marka at isc.org Tue Apr 27 18:38:06 2010 From: marka at isc.org (Mark Andrews) Date: Wed, 28 Apr 2010 09:38:06 +1000 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: Your message of "Tue, 27 Apr 2010 17:25:18 -0400." References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72386.6010303@matthew.at> <19110.1272392139@localhost> <20861.1272394046@localhost> <26157.1272400265@localhost> Message-ID: <201004272338.o3RNc6O7032082@drugs.dv.isc.org> In message , Jon Lewis writes: > Both my kids run Win2k (to support old software that doesn't run > well/at all post-2k). I doubt that's all that unusual. Then they won't have IPv6 and hence are irrelevent to the discussion about IPv6 NAT. As for built in firewalls, even my brother printer as a firewall built into it and it supports IPv6. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From felipe at starbyte.net Tue Apr 27 19:21:54 2010 From: felipe at starbyte.net (Felipe Zanchet Grazziotin) Date: Tue, 27 Apr 2010 21:21:54 -0300 Subject: IPv6 rDNS - how will it be done? Message-ID: Hi list, this is my first post, so be nice. :) Wondering about IPv6 deployments to end-users, imagine we deploy a full /48 address to each client. How is the reverse DNS for each possible IPv6 address going to be? Nowadays I'm used to do IPv4 reverse using old Class C, which has (up to) 256 entries. Are we really going to make reverse DNS entries for each of those 2^80 addresses? Or going to deploy rDNS only at the PtP links and relevant servers? Kind regards, Felipe From marka at isc.org Tue Apr 27 19:42:09 2010 From: marka at isc.org (Mark Andrews) Date: Wed, 28 Apr 2010 10:42:09 +1000 Subject: IPv6 rDNS - how will it be done? In-Reply-To: Your message of "Tue, 27 Apr 2010 21:21:54 -0300." References: Message-ID: <201004280042.o3S0g9Lm032957@drugs.dv.isc.org> In message , Felipe Zanchet Grazziotin writes: > Hi list, > > this is my first post, so be nice. :) > > Wondering about IPv6 deployments to end-users, imagine we deploy a full /48 > address to each client. > How is the reverse DNS for each possible IPv6 address going to be? > > Nowadays I'm used to do IPv4 reverse using old Class C, which has (up to) > 256 entries. Are we really going to make reverse DNS entries for each of > those 2^80 addresses? Or going to deploy rDNS only at the PtP links and > relevant servers? > > Kind regards, > Felipe Windows will just populate the reverse zone as needed, if you let it, using dynamic update. If you have properly deployed BCP 39 and have anti-spoofing ingres filtering then you can just let any address from the /48 add/remove PTR records. Other OS's will follow suite. Alternatively you can delegate the reverse for the /48 to servers run by the customers. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From xenophage at godshell.com Tue Apr 27 19:47:03 2010 From: xenophage at godshell.com (Jason 'XenoPhage' Frisvold) Date: Tue, 27 Apr 2010 20:47:03 -0400 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: <201004280042.o3S0g9Lm032957@drugs.dv.isc.org> References: <201004280042.o3S0g9Lm032957@drugs.dv.isc.org> Message-ID: <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> On Apr 27, 2010, at 8:42 PM, Mark Andrews wrote: > Windows will just populate the reverse zone as needed, if you let > it, using dynamic update. If you have properly deployed BCP 39 > and have anti-spoofing ingres filtering then you can just let any > address from the /48 add/remove PTR records. Other OS's will > follow suite. Is DDNS really considered to be the end-all answer for this? It seems we're putting an awful lot of trust in the user when doing this.. I'd rather see some sort of macro expansion in bind/tinydns/etc that would allow a range of addresses to be added. > Alternatively you can delegate the reverse for the /48 to servers > run by the customers. This works for commercial customers, but I'm not sure I'd want to delegate this to a residential customer. > Mark --------------------------- Jason 'XenoPhage' Frisvold xenophage at godshell.com --------------------------- "Any sufficiently advanced magic is indistinguishable from technology." - Niven's Inverse of Clarke's Third Law From richard.barnes at gmail.com Tue Apr 27 19:50:20 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Tue, 27 Apr 2010 20:50:20 -0400 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> References: <201004280042.o3S0g9Lm032957@drugs.dv.isc.org> <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> Message-ID: Na?ve question: If you used macro expansion, wouldn't you end up providing responses for a lot of addresses that aren't in use? Maybe that's not a problem? On Tue, Apr 27, 2010 at 8:47 PM, Jason 'XenoPhage' Frisvold wrote: > On Apr 27, 2010, at 8:42 PM, Mark Andrews wrote: >> Windows will just populate the reverse zone as needed, if you let >> it, using dynamic update. ?If you have properly deployed BCP 39 >> and have anti-spoofing ingres filtering then you can just let any >> address from the /48 add/remove PTR records. ?Other OS's will >> follow suite. > > Is DDNS really considered to be the end-all answer for this? ?It seems we're putting an awful lot of trust in the user when doing this.. ?I'd rather see some sort of macro expansion in bind/tinydns/etc that would allow a range of addresses to be added. > >> Alternatively you can delegate the reverse for the /48 to servers >> run by the customers. > > This works for commercial customers, but I'm not sure I'd want to delegate this to a residential customer. > >> Mark > > --------------------------- > Jason 'XenoPhage' Frisvold > xenophage at godshell.com > --------------------------- > "Any sufficiently advanced magic is indistinguishable from technology." > - Niven's Inverse of Clarke's Third Law > > > > > From jeroen at mompl.net Tue Apr 27 19:55:57 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Tue, 27 Apr 2010 17:55:57 -0700 Subject: Mail Submission Protocol In-Reply-To: <4BD0324B.3010805@ipax.at> References: <90AFE804-3CC3-4FE1-A6D6-FD0F79B4AD10@dotat.at> <4BD0324B.3010805@ipax.at> Message-ID: <4BD7879D.3090208@mompl.net> Raoul Bhatia [IPAX] wrote: > i recently had the problem that an lotus notes server insisted on > sending emails to one of our clients via port 465. so having mandatory > authentication there actually broke delivery for an exchange sender. Leave it "broken" for the other end that is. Only way to force them to fix it. The only acceptable, and standard, way to submit email these days is using port 587 with TLS. And if you have users with broken clients, they can use webmail behind https. I am against facilitating (and thus perpetuating the existence of) old broken clients by making available port 465. Regards, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ From xenophage at godshell.com Tue Apr 27 19:58:32 2010 From: xenophage at godshell.com (Jason 'XenoPhage' Frisvold) Date: Tue, 27 Apr 2010 20:58:32 -0400 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: References: <201004280042.o3S0g9Lm032957@drugs.dv.isc.org> <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> Message-ID: <97251A9C-46A0-4F6E-9A4E-5CAA5C09B718@godshell.com> On Apr 27, 2010, at 8:50 PM, Richard Barnes wrote: > Na?ve question: If you used macro expansion, wouldn't you end up > providing responses for a lot of addresses that aren't in use? Maybe > that's not a problem? Presumably the op would only use macros where needed, ie dynamically assigned addresses. So, for a pool of addresses assigned for DSL/Cable/FIOS subscribers, that pool would have forward/reverse set up. Note: I am definitely not up on my IPv6 knowledge, so there may be a Really Good Reason(tm) that one should not do this.. However, I was under the impression that having both forward and reverse for dynamic IPs was a best practice.. --------------------------- Jason 'XenoPhage' Frisvold xenophage at godshell.com --------------------------- "Any sufficiently advanced magic is indistinguishable from technology." - Niven's Inverse of Clarke's Third Law From drc at virtualized.org Tue Apr 27 20:00:59 2010 From: drc at virtualized.org (David Conrad) Date: Tue, 27 Apr 2010 18:00:59 -0700 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> References: <201004280042.o3S0g9Lm032957@drugs.dv.isc.org> <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> Message-ID: On Apr 27, 2010, at 5:47 PM, Jason 'XenoPhage' Frisvold wrote: > On Apr 27, 2010, at 8:42 PM, Mark Andrews wrote: >> Windows will just populate the reverse zone as needed, if you let >> it, using dynamic update. If you have properly deployed BCP 39 >> and have anti-spoofing ingres filtering then you can just let any >> address from the /48 add/remove PTR records. Other OS's will >> follow suite. > > Is DDNS really considered to be the end-all answer for this? Seems it is that or not bothering with reverse anymore. > It seems we're putting an awful lot of trust in the user when doing this.. I'd rather see some sort of macro expansion in bind/tinydns/etc that would allow a range of addresses to be added. Hmm. A macro expansion for a /48 would mean 1,208,925,819,614,629,174,706,176 leaves. An interesting stress test for name servers... :-). Slightly more seriously, there have been discussions in the past about doing dynamic synthesis of v6 reverses, but that gets icky (particularly if you invoke the dreaded "DNSSEC" curse) and I don't know any production server that actually does this now. Dynamic DNS is probably the least offensive solution if you really want reverses for your v6 nodes. Regards, -drc From xenophage at godshell.com Tue Apr 27 20:10:07 2010 From: xenophage at godshell.com (Jason 'XenoPhage' Frisvold) Date: Tue, 27 Apr 2010 21:10:07 -0400 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: References: <201004280042.o3S0g9Lm032957@drugs.dv.isc.org> <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> Message-ID: <07CAAF4D-E31E-4E8D-B7AD-5DFEE623F0AD@godshell.com> On Apr 27, 2010, at 9:00 PM, David Conrad wrote: > Hmm. A macro expansion for a /48 would mean 1,208,925,819,614,629,174,706,176 leaves. An interesting stress test for name servers... :-). Um.. sure. :) Your computer can't handle that? How about a programmatic expansion? Only create the necessary record when asked for it. > Slightly more seriously, there have been discussions in the past about doing dynamic synthesis of v6 reverses, but that gets icky (particularly if you invoke the dreaded "DNSSEC" curse) and I don't know any production server that actually does this now. Dynamic DNS is probably the least offensive solution if you really want reverses for your v6 nodes. DNSSEC does seem to throw the proverbial wrench in the works.. At least, from what I understand.. I'm still not sold on DNSSEC and that, partly, has to do with a lack of knowledge.. If you allow a client to set their own reverse, don't you run into issues where the client can spoof their identity? ie, set their reverse to whitehouse.gov or bankofamerica.com ? Or is it possible to configure DDNS in such a way as to only allow subdomain names where the domain is tacked on automagically? > Regards, > -drc --------------------------- Jason 'XenoPhage' Frisvold xenophage at godshell.com --------------------------- "Any sufficiently advanced magic is indistinguishable from technology." - Niven's Inverse of Clarke's Third Law From LarrySheldon at cox.net Tue Apr 27 20:19:21 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 27 Apr 2010 20:19:21 -0500 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: References: <201004280042.o3S0g9Lm032957@drugs.dv.isc.org> <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> Message-ID: <4BD78D19.7010101@cox.net> On 4/27/2010 19:50, Richard Barnes wrote: > Na?ve question: If you used macro expansion, wouldn't you end up > providing responses for a lot of addresses that aren't in use? Maybe > that's not a problem? If you get a request, you will have to respond in any case. I have a theory about data-base lookups--finding something is always faster than not finding anything, unless you are using a human brain. (A human brain can respond "I don't know that" without an inventory of everything it does know.) (That may be to only truly unique thing about humans. And no, I have not kept up with neural networks work.) -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From richard.barnes at gmail.com Tue Apr 27 20:25:13 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Tue, 27 Apr 2010 21:25:13 -0400 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: <4BD78D19.7010101@cox.net> References: <201004280042.o3S0g9Lm032957@drugs.dv.isc.org> <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> <4BD78D19.7010101@cox.net> Message-ID: Interesting theory, but seems kind of wrong. Wouldn't the time to look up or fail be tied to the complexity of how the key space is populated? In any case, it seems like the time to succeed or fail will usually be about the same, since you'll try to access the value for a key and either find something there or fail. On Tue, Apr 27, 2010 at 9:19 PM, Larry Sheldon wrote: > On 4/27/2010 19:50, Richard Barnes wrote: >> Na?ve question: If you used macro expansion, wouldn't you end up >> providing responses for a lot of addresses that aren't in use? ?Maybe >> that's not a problem? > > If you get a request, you will have to respond in any case. > > I have a theory about data-base lookups--finding something is always > faster than not finding anything, unless you are using a human brain. > > (A human brain can respond "I don't know that" without an inventory of > everything it does know.) > > (That may be to only truly unique thing about humans. ?And no, I have > not kept up with neural networks work.) > > -- > Somebody should have said: > A democracy is two wolves and a lamb voting on what to have for dinner. > > Freedom under a constitutional republic is a well armed lamb contesting > the vote. > > Requiescas in pace o email > Ex turpi causa non oritur actio > Eppure si rinfresca > > ICBM Targeting Information: ?http://tinyurl.com/4sqczs > http://tinyurl.com/7tp8ml > > > > From drc at virtualized.org Tue Apr 27 20:26:27 2010 From: drc at virtualized.org (David Conrad) Date: Tue, 27 Apr 2010 18:26:27 -0700 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: <07CAAF4D-E31E-4E8D-B7AD-5DFEE623F0AD@godshell.com> References: <201004280042.o3S0g9Lm032957@drugs.dv.isc.org> <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> <07CAAF4D-E31E-4E8D-B7AD-5DFEE623F0AD@godshell.com> Message-ID: On Apr 27, 2010, at 6:10 PM, Jason 'XenoPhage' Frisvold wrote: > How about a programmatic expansion? Only create the necessary record when asked for it. The downsides I know of (off the top of my head) with dynamic synthesis are (a) challenges if you want DNSSEC and (b) increased susceptibility to D(D)oS attack. There are probably others. At some point, one has to ask if the ability to map the address into a name is worth the effort... > If you allow a client to set their own reverse, don't you run into issues where the client can spoof their identity? ie, set their reverse to whitehouse.gov or bankofamerica.com ? Yep, but those are boring examples. I've seen (typically University computer science) networks with some truly fascinating (in scatological, religious and/or reproductive senses) reverse names. Since anyone who relies on the reverse for anything other than a hint that the address might be part of a managed network deserves what they get, the names were good for a chuckle. > Or is it possible to configure DDNS in such a way as to only allow subdomain names where the domain is tacked on automagically? Most DDNS servers support some form of filtering. However, the better way, at least in IPv4, is to have the DHCP server do the dynamic updates, not the client. However, since some view DHCPv6 as Evil Pure and Simple by way of the Eighth Dimension(tm), this may not be an option. Regards, -drc From richard.barnes at gmail.com Tue Apr 27 20:27:16 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Tue, 27 Apr 2010 21:27:16 -0400 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: <07CAAF4D-E31E-4E8D-B7AD-5DFEE623F0AD@godshell.com> References: <201004280042.o3S0g9Lm032957@drugs.dv.isc.org> <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> <07CAAF4D-E31E-4E8D-B7AD-5DFEE623F0AD@godshell.com> Message-ID: Presumably, if you've already got a script that's provisioning reverse results, you could amend it to add name constraints. No idea if this is possible with current DynDNS software, though. --Richard On Tue, Apr 27, 2010 at 9:10 PM, Jason 'XenoPhage' Frisvold wrote: > On Apr 27, 2010, at 9:00 PM, David Conrad wrote: >> Hmm. A macro expansion for a /48 would mean 1,208,925,819,614,629,174,706,176 leaves. An interesting stress test for name servers... :-). > > Um.. sure. ?:) ?Your computer can't handle that? > > How about a programmatic expansion? ?Only create the necessary record when asked for it. > >> Slightly more seriously, there have been discussions in the past about doing dynamic synthesis of v6 reverses, but that gets icky (particularly if you invoke the dreaded "DNSSEC" curse) and I don't know any production server that actually does this now. ?Dynamic DNS is probably the least offensive solution if you really want reverses for your v6 nodes. > > DNSSEC does seem to throw the proverbial wrench in the works.. ?At least, from what I understand.. ?I'm still not sold on DNSSEC and that, partly, has to do with a lack of knowledge.. > > If you allow a client to set their own reverse, don't you run into issues where the client can spoof their identity? ?ie, set their reverse to whitehouse.gov or bankofamerica.com ? ?Or is it possible to configure DDNS in such a way as to only allow subdomain names where the domain is tacked on automagically? > >> Regards, >> -drc > > --------------------------- > Jason 'XenoPhage' Frisvold > xenophage at godshell.com > --------------------------- > "Any sufficiently advanced magic is indistinguishable from technology." > - Niven's Inverse of Clarke's Third Law > > > > > From LarrySheldon at cox.net Tue Apr 27 20:28:33 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 27 Apr 2010 20:28:33 -0500 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: References: <201004280042.o3S0g9Lm032957@drugs.dv.isc.org> <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> <4BD78D19.7010101@cox.net> Message-ID: <4BD78F41.7080904@cox.net> On 4/27/2010 20:25, Richard Barnes wrote: > > > > Interesting theory, but seems kind of wrong. Wouldn't the time to > look up or fail be tied to the complexity of how the key space is > populated? In any case, it seems like the time to succeed or fail > will usually be about the same, since you'll try to access the value > for a key and either find something there or fail. The theory is based on the notion that if you find something you stop looking for it. If what you are looking for is not there, you have to search all of the key-space, regardless of the index method. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From steve at ipv6canada.com Mon Apr 26 19:29:31 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Mon, 26 Apr 2010 20:29:31 -0400 Subject: Connectivity to an IPv6-only site In-Reply-To: <4BD1432F.4070406@ibctech.ca> References: <4BD1432F.4070406@ibctech.ca> Message-ID: <4BD62FEB.3070500@ipv6canada.com> On 2010.04.23 02:50, Steve Bertrand wrote: > http://onlyv6.com > All findings will be publicly posted. I'm currently evaluating my options to best automate some of the findings that I've got so far (I didn't ask for a common format for replies, so most will be manual). However, an interesting item that I've noted thus far, is that ~50% of all successful connections do not have rDNS. Originally, I thought that the majority of these simply didn't have their delegated reverse zones on v6-reachable DNS servers, but this is not necessarily so. I copied the web log onto a dual-stack box and re-ran the DNS tests, and only two of the non-resolvable ip6.arpa addresses resolved over v4. fwiw, for those who have been asking, inbound SMTP is now working, and I've got a basic IMAP/POP3 daemon running. If you still want a test account, let me know. steve at onlyv6.com Thanks everyone for all of the support. Cheers, Steve From marka at isc.org Tue Apr 27 20:33:48 2010 From: marka at isc.org (Mark Andrews) Date: Wed, 28 Apr 2010 11:33:48 +1000 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: Your message of "Tue, 27 Apr 2010 20:47:03 -0400." <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> References: <201004280042.o3S0g9Lm032957@drugs.dv.isc.org> <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> Message-ID: <201004280133.o3S1XnB8033433@drugs.dv.isc.org> In message <268EBCE2-9D47-488E-8223-29B5A6323CEB at godshell.com>, "Jason 'XenoPhage' Frisvold" wri tes: > On Apr 27, 2010, at 8:42 PM, Mark Andrews wrote: > > Windows will just populate the reverse zone as needed, if you let > > it, using dynamic update. If you have properly deployed BCP 39 > > and have anti-spoofing ingres filtering then you can just let any > > address from the /48 add/remove PTR records. Other OS's will > > follow suite. > > Is DDNS really considered to be the end-all answer for this? It works if you let it. > It seems = > we're putting an awful lot of trust in the user when doing this. What trust? The OS just does it. The user doesn't need to think about this. > I'd = > rather see some sort of macro expansion in bind/tinydns/etc that would = > allow a range of addresses to be added. Macro expansion won't work. 1208925819614629174706176 PTR records is a hell of a lot of records and that's just 1 /48. :-) > > Alternatively you can delegate the reverse for the /48 to servers > > run by the customers. > > This works for commercial customers, but I'm not sure I'd want to = > delegate this to a residential customer. Some will be capable others won't. I would leave it as a option but not the default. Some thing that the account's control panel can turn on and off. I would however use a different set of servers for the /48's to that of serving the /32 (or whatever) as you can just change the delegation without having to also add and remove zones which you would if they are on the same servers. I would also provide customers with forward zones that they can populate again using the /48 to control access. e.g. .customer.isp.com. is the hexadecimal representation of the /48. ..customer.isp.com. AAAA : They don't need to use it but it should be there to provide complete the loop. If HE was following this schema then bsdi would default to: bsdi.200104701f00.customer.he.net AAAA 2001:470:1f00:ffff::5a1 bsdi.200104701f00.customer.he.net AAAA 2001:470:1f00:820:2e0:29ff:fe19:c02d But as I care about the name of the machine it is: bsdi.dv.isc.org. AAAA 2001:470:1f00:ffff::5a1 bsdi.dv.isc.org. AAAA 2001:470:1f00:820:2e0:29ff:fe19:c02d Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From LarrySheldon at cox.net Tue Apr 27 20:39:03 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 27 Apr 2010 20:39:03 -0500 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: <4BD78F41.7080904@cox.net> References: <201004280042.o3S0g9Lm032957@drugs.dv.isc.org> <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> <4BD78D19.7010101@cox.net> <4BD78F41.7080904@cox.net> Message-ID: <4BD791B7.8010702@cox.net> On 4/27/2010 20:28, Larry Sheldon wrote: > On 4/27/2010 20:25, Richard Barnes wrote: >> >> >> >> Interesting theory, but seems kind of wrong. Wouldn't the time to >> look up or fail be tied to the complexity of how the key space is >> populated? In any case, it seems like the time to succeed or fail >> will usually be about the same, since you'll try to access the value >> for a key and either find something there or fail. > > The theory is based on the notion that if you find something you stop > looking for it. If what you are looking for is not there, you have to > search all of the key-space, regardless of the index method. That is why, when I was actively designing (or supervising the design) of data-bases, we tried to make the most likely hits at the beginning of the key-space. In general, easier to say than to do. And not as intuitive as you might think. (In the old days, there was the closely related entertainment of predicting which benefited most from cached-disc systems, random files or sequential files.) -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From johnl at iecc.com Tue Apr 27 20:41:23 2010 From: johnl at iecc.com (John Levine) Date: 28 Apr 2010 01:41:23 -0000 Subject: Starting up a WiMAX ISP In-Reply-To: <892926.15240.qm@web33401.mail.mud.yahoo.com> Message-ID: <20100428014123.91390.qmail@joyce.lan> >+ I have those numbers I can beat the pavement and find out what people >will pay for my service and then I will know based on my table if there >is a snowball's chance in hell of this working. Don't forget that you're competing against rural ILECs that drink deeply from the well of USF funding. My local telco (Trumansburg) called me today to point out that I was paying $76/mo for a package of phone, 3Mb/382Kb DSL, voice mail and caller ID, but if I added in national long distance and a few other features, they'd give me the package rate of $66. They offer 3MB DSL all over their service area, even those long long rural runs. You think you can compete with that? Lightlink does OK against Verizon in Ithaca in the relatively dense area at the foot of Cayuga Lake, but with, as other people have noted, the owners doing nearly all the work. R's, John From steve at ipv6canada.com Tue Apr 27 20:19:13 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Tue, 27 Apr 2010 21:19:13 -0400 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: References: <201004280042.o3S0g9Lm032957@drugs.dv.isc.org> <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> Message-ID: <4BD78D11.3040303@ipv6canada.com> On 2010.04.27 21:00, David Conrad wrote: > On Apr 27, 2010, at 5:47 PM, Jason 'XenoPhage' Frisvold wrote: >> On Apr 27, 2010, at 8:42 PM, Mark Andrews wrote: >>> Windows will just populate the reverse zone as needed, if you let >>> it, using dynamic update. If you have properly deployed BCP 39 >>> and have anti-spoofing ingres filtering then you can just let any >>> address from the /48 add/remove PTR records. Other OS's will >>> follow suite. >> >> Is DDNS really considered to be the end-all answer for this? > > Seems it is that or not bothering with reverse anymore. There are other solutions, which has become a major focus of mine based on some of the results I've gathered from my little test. About 50% (currently 50.59%) of all successful visits to my site do not have rDNS configured for their IPv6... That is a problem that needs a solution. The OP has a great question here. Steve From johnl at iecc.com Tue Apr 27 20:46:57 2010 From: johnl at iecc.com (John Levine) Date: 28 Apr 2010 01:46:57 -0000 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: Message-ID: <20100428014657.91479.qmail@joyce.lan> >Hmm. A macro expansion for a /48 would mean >1,208,925,819,614,629,174,706,176 leaves. An interesting stress test >for name servers... :-). My inclination would be to use a wildcard that returns something like not-in-service.some-network.net, and let the clients add records for the addresses they use. For spoof resistance, how about doing a forward lookup on the purported name and only installing it if it gets a matching AAAA record? R's, John From bclark at spectraaccess.com Tue Apr 27 20:47:41 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Tue, 27 Apr 2010 21:47:41 -0400 Subject: Starting up a WiMAX ISP In-Reply-To: <20100428014123.91390.qmail@joyce.lan> References: <20100428014123.91390.qmail@joyce.lan> Message-ID: <4BD793BD.5050906@spectraaccess.com> John Levine wrote: > package rate of $66. They offer 3MB DSL all over their service area, > even those long long rural runs. You think you can compete with that? > > Of course what they offer over those "long long rural runs" and what they can actually provide are two different things. DSL performance decreases with distance rather dramatically.. From johnl at iecc.com Tue Apr 27 21:13:24 2010 From: johnl at iecc.com (John R. Levine) Date: 27 Apr 2010 22:13:24 -0400 Subject: Starting up a WiMAX ISP In-Reply-To: <4BD793BD.5050906@spectraaccess.com> References: <20100428014123.91390.qmail@joyce.lan> <4BD793BD.5050906@spectraaccess.com> Message-ID: > Of course what they offer over those "long long rural runs" and what they can > actually provide are two different things. DSL performance decreases with > distance rather dramatically.. That's what I thought, but my friend out on the sheep farm in the next county says he gets 3Mb just like I do in the village three blocks from the CO. (Yes, he knows what he's talking about.) They must spend a lot on repeaters and concentrators. R's, John From drc at virtualized.org Tue Apr 27 21:13:47 2010 From: drc at virtualized.org (David Conrad) Date: Tue, 27 Apr 2010 19:13:47 -0700 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: <20100428014657.91479.qmail@joyce.lan> References: <20100428014657.91479.qmail@joyce.lan> Message-ID: <5D2F7A42-AD4B-4FB8-8BFA-FA5458BEB742@virtualized.org> On Apr 27, 2010, at 6:46 PM, John Levine wrote: >> Hmm. A macro expansion for a /48 would mean >> 1,208,925,819,614,629,174,706,176 leaves. An interesting stress test >> for name servers... :-). > My inclination would be to use a wildcard that returns something like > not-in-service.some-network.net, and let the clients add records for > the addresses they use. While better than 1 septillion zone entries, you still have the problem of how to let the clients add the records. DDNS is one approach. Manual intervention (e.g., as part of a customer provisioning system) is another as long as you don't use privacy extensions. > For spoof resistance, how about doing a forward lookup on the > purported name and only installing it if it gets a matching AAAA > record? Sounds like a reasonable DDNS filtering approach. Regards, -drc From felipe at starbyte.net Tue Apr 27 21:27:47 2010 From: felipe at starbyte.net (Felipe Zanchet Grazziotin) Date: Tue, 27 Apr 2010 23:27:47 -0300 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: <5D2F7A42-AD4B-4FB8-8BFA-FA5458BEB742@virtualized.org> References: <20100428014657.91479.qmail@joyce.lan> <5D2F7A42-AD4B-4FB8-8BFA-FA5458BEB742@virtualized.org> Message-ID: On Tue, Apr 27, 2010 at 11:13 PM, David Conrad wrote: > On Apr 27, 2010, at 6:46 PM, John Levine wrote: > > > For spoof resistance, how about doing a forward lookup on the > > purported name and only installing it if it gets a matching AAAA > > record? > > Sounds like a reasonable DDNS filtering approach. > > On controlled environments it might work. Don't know how larger ISPs would set AAAA records before for bazillion possible combinations of computer.subnet.customer.isp.tld. If going dynamic, are you willing to lower your DNS TTL to handle that? Maybe doing wildchar evatulation for /64 subnets? "Everything under this subnet is my-subnet.customer.isp.tld". > Regards, > -drc > > > Kindly, Felipe From mysidia at gmail.com Tue Apr 27 21:31:13 2010 From: mysidia at gmail.com (James Hess) Date: Tue, 27 Apr 2010 21:31:13 -0500 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: <97251A9C-46A0-4F6E-9A4E-5CAA5C09B718@godshell.com> References: <201004280042.o3S0g9Lm032957@drugs.dv.isc.org> <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> <97251A9C-46A0-4F6E-9A4E-5CAA5C09B718@godshell.com> Message-ID: On Tue, Apr 27, 2010 at 7:58 PM, Jason 'XenoPhage' Frisvold wrote: > On Apr 27, 2010, at 8:50 PM, Richard Barnes wrote: >...However, I was under the impression that having both forward and reverse for >dynamic IPs was a best practice.. Perhaps we should back up a bit and delete 'how' from the subject line of this thread, and first ask 'Will it be done?' and where will RDNS be implemented? It is best practice within IPv4 networks. The IPv6 internet is a new network, and prevalent practices will not necessarily turn out to be what we consider best from V4. 'Best practice' is going to have to meet with administrative necessity in some form at some point. A reality may be that not all hosts necessarily have a meaningful hostname that they should be addressed by, or that the 'operator' (web browser user) wants to be known; Useful RDNS records may become more confined to hosts that actually provide a globally accessible service. Residential subscribers of ISP you-are-not-allowed-to-run-a-server level of DSL/Cable service will likely not have their own domain name, providing RDNS delegation would be mostly a waste of resources. Providing DDNS updates to RDNS is likely to be abused in various ways, even if it can be secured (malware would love this -- instant fully RDNS-cognizant mail server). The prevalent practice is almost certainly going to be for res. ISPs to provide a NXDOMAIN response to RDNS queries, or a generic response like is common with V4. Probably "custom RDNS" would be considered a business service, and like all business services, have its own pricing schedule, and involve subscriber providing IP addresses of DNS servers to delegate to. If Res. subscribers are lucky the big ISPs might provide a proprietary app to run on their PC to magically register it with RDNS, and enable for connectivity. With the downside that there can now be an enforced per-PC surcharge. Consumer DSL providers would probably love this.... $60/month, connectivity for one PC to the internet at X/speed included..... . $1/day extra for each additional PC registered with the DNS, $0.10/hour for each Xbox/gaming console/HTPC/Media streaming device registered for internet access. *zip bang voom* 4 years later... IPv6 NAT, the prevalent technology present in every $50 IPv6 router, an unofficial hack that might some day get an RFC made about it.... -- -J From aaron at heyaaron.com Tue Apr 27 21:33:39 2010 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Tue, 27 Apr 2010 19:33:39 -0700 Subject: VPN over Comcast In-Reply-To: References: <79AF0C3901752A49881FE4CB31F7AA4001A16D06@abn-borg2.NETABN.LOCAL> <323E4F47-7850-4F1B-8EE0-C01AB2B89674@delong.com> Message-ID: <20100428023339.GB12122@chrysalis> On 2010-04-27 at 14:56:04 -0400, schilling wrote: > http://ckdake.com/content/2008/disable-gateway-smart-packet-detection.html > showed a feature of "Gateway Smart Packet Detection" in some SMC > cable modem. On one of our cable modems I had this manifest itself by dropping every other packet. I spent several hours trying to figure that one out, resetting the modem, and talking with L1 support. Finally someone higher up said 'Turn off SPD'. -A From matthew at matthew.at Tue Apr 27 22:55:59 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 27 Apr 2010 20:55:59 -0700 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <5005DE88-68DD-44F7-8154-5448D33D7F3F@delong.com> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72386.6010303@matthew.at> <63667EAD-622B-4A21-A794-6DBFCE091079@delong.com> <4BD731B6.6030505@matthew.at> <5005DE88-68DD-44F7-8154-5448D33D7F3F@delong.com> Message-ID: <4BD7B1CF.4090502@matthew.at> Owen DeLong wrote: > On Apr 27, 2010, at 11:49 AM, Matthew Kaufman wrote: > > >> Owen DeLong wrote: >> >>> On Apr 27, 2010, at 10:48 AM, Matthew Kaufman wrote: >>> >>> >>> >>>> Andy Davidson wrote: >>>> >>>> >>>>> On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote: >>>>> >>>>> >>>>>>> Did you use Yahoo IM, AIM, or Skype? >>>>>>> >>>>>>> >>>>>> Yes, yes, and yes. Works fine. >>>>>> >>>>>> >>>>> What about every other service/protocol that users use today, and might be invented tomorrow ? Do & will they all work with NAT ? >>>>> >>>>> >>>> Anyone inventing a new service/protocol that doesn't work with NAT isn't planning on success. >>>> >>>> >>> Respectfully, I disagree. There are many possible innovations that are available in a NAT-less world and it is desirable to get to that point rather than hamper future innovation with this obsolete baggage. >>> >>> >> I would argue that every one of those innovations, if even passably useful, can also be implemented in a NAT-full world. >> > > Perhaps, but, often at significant additional code, development time, QA resources and other costs. > Also, often at a degraded level requiring a non-NAT'd third-party broker to intermediate between any two NAT'd parties attempting to trade information. > Yes, there's additional development, but if NAT was more standardized (which it has a chance of being for IPv6, if we'd just stop arguing about whether or not it is going to happen... it'll happen, the question is whether or not there'll be a standard to follow) that development cost could be nearly a one-time library cost vs. custom code to deal with every situation and changing situations. > >>> >>> >>>>> Do many others work as well or act reliably through NAT ? >>>>> >>>>> >>>> Yes. >>>> >>>> >>> In reality, it's more like some yes, some not so much. >>> >>> >> == Some designed to work properly in the face of NAT, some ignored reality at their peril. >> > > We can agree to disagree about this. The reality is that there are cool things you can do with peer to peer networking that simply aren't possible in an enforced client-server model. > Agreed. > NAT enforces a client-server model and permanently and irrevocably relegates some administrative domains to the client role. This is an unfair disadvantage to the users within those domains when it is not by the choice of the administrator (and NAT in IPv4 so far, often is not). > No. Most NAT *doesn't* enforce a client-server model, it enforces a deliberate signaling model for establishing peer-to-peer communication, and allows open client-server communication (and most communication is, and will forever be, client-server). Assuming, again, that the NATs behave reasonably when trying to do peer-to-peer communication through them, which most (over 90% of what's deployed for IPv4) do. And *all* could, if there were standards people could code to. Which, again, for IPv6 there could be, if we'd stop claiming that NAT will never happen / is a bad idea and so shouldn't be standardized / etc. > >>> >>> >>>>> Will it stop or hamper the innovation of new services on the >>>>> internet ? >>>>> >>>>> >>>> Hasn't so far. >>>> >>>> >>> Here I have to call BS... I know of a number of cases where it has. >>> >>> >> Ok, you called it... so where's the list of such services that haven't materialized as a result of NAT? >> >> > Haven't materialized, for one, is an attempt to redefine the question. Note that the original question included "hamper". I would argue that the cost of maintaining a NAT compatibility lab and the QA staff to use it is a sufficient burden to call it "hamper". > Again, such a lab would not be needed if NAT operation were codified in standards. Which could happen, if not for the vocal set who keeps arguing against them, even when there's 5+ good reasons for them, even in IPv6. > For the ones that did not materialize, however, I am at an unfortunate disadvantage in the argument. I can tell you that I know of at least 5 such cases. However, I cannot reveal the details because I am under NDA to the companies that were developing these products. I can tell you that in 3 of the 5 cases, adapting them to cope with a NAT world would have required the company to run an external service in perpetuity (or at least so long as the application would function, no server, no function) in order to do the match-making between clients that could not directly reach each-other. > > I guess a good analogy is this: > > In a NAT world, you have only matchmaking services and all of your ability to meet potential mates is strictly controlled through these matchmaking services. There are many services available independent of each other, and, each has its own limitations, biases, and quirks. However, you cannot meet potential mates without involving at least one matchmaker. > True, but that's essentially true for all software, and certainly true for all "web-based" software. > In a NAT-Free world, you have the ability to use a matchmaking service if you like, but, you also have the ability to meet potential mates at bars, in the grocery store, on the street, in restaurants, through chance meetings, introductions by a friend, or even at work. > Really? There's still the name/service to address lookup problem. If the controlling entity goes away, you're again dead in the water. We're just lucky that some of those services (e.g., DNS) have a group who's agreed to run them in perpetuity as far as we can tell. If every root nameserver moved to a new IP address on a random whim tomorrow, most of these apps you talk about would stop working. No different than losing access to the aforementioned matchmaking service. > It is possible that if you never knew it was possible to meet potential mates in all of these other ways, you would happily deal with a vast number of matchmaking services hoping to find a useful result. On the other hand, if you were to ask the average person who has experienced the latter scenario if they would be willing to limit their choices to only using a dating service, my guess would be that most people would reject the idea outright. > Some people want the matchmaking controlled by an entity other than the de facto one, actually. Lots of benefits to trying to register your highly-mobile computer in a peer-to-peer introduction system designed for that instead of in a DNS that isn't. Matthew Kaufman ps. In the spirit of disclosure, I should point out that I've shipped a peer-to-peer networking protocol that works through most NATs and which is almost certainly already installed on the computer you are using now. From matthew at matthew.at Tue Apr 27 22:59:12 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 27 Apr 2010 20:59:12 -0700 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100420145332.58995.qmail@joyce.lan> <20100427173622.GA24745@chilli.nosignal.org> <4BD72386.6010303@matthew.at> <19110.1272392139@localhost> <20861.1272394046@localhost> <26157.1272400265@localhost> Message-ID: <4BD7B290.5020609@matthew.at> James Hess wrote: > > > Fortunately, the IPv6 address space is so large and sparse, that > scanning it would be quite a feat, even if a random outside attacker > already knew for a fact that a certain /64 probably contains a > vulnerable host. All I need to do is run a popular web site on the IPv6 Internet, and I get all the addresses of connected hosts I want. That address-space-scanning is hard is nearly irrelevant. Matthew Kaufman From josh.hoppes at gmail.com Tue Apr 27 23:04:58 2010 From: josh.hoppes at gmail.com (Josh Hoppes) Date: Tue, 27 Apr 2010 23:04:58 -0500 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? Message-ID: I'll preface this that I'm more of an end user then a network administrator, but I do feel I have a good enough understanding of the protocols and network administration to submit my two cents. The issue I see with this level of NAT, is the fact that I don't expect that UPNP be implemented at that level. I would see UPNP as being a security risk and prone to denial of service attacks when you have torrent clients attempting to grab every available port. Now that's going to create problems with services like Xbox Live which require UPNP to fully function since at least on one persons connection so they can "host" the game. When you're looking at player counts in the millions I'm fairly sure that they are going to be effected by CGN. That's one application I expect to see break by such large scale NAT implementations. From adrian at creative.net.au Tue Apr 27 23:16:20 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Wed, 28 Apr 2010 12:16:20 +0800 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD7B290.5020609@matthew.at> References: <20100427173622.GA24745@chilli.nosignal.org> <4BD72386.6010303@matthew.at> <19110.1272392139@localhost> <20861.1272394046@localhost> <26157.1272400265@localhost> <4BD7B290.5020609@matthew.at> Message-ID: <20100428041620.GJ25706@skywalker.creative.net.au> On Tue, Apr 27, 2010, Matthew Kaufman wrote: > >Fortunately, the IPv6 address space is so large and sparse, that > >scanning it would be quite a feat, even if a random outside attacker > >already knew for a fact that a certain /64 probably contains a > >vulnerable host. > All I need to do is run a popular web site on the IPv6 Internet, and I > get all the addresses of connected hosts I want. That > address-space-scanning is hard is nearly irrelevant. or troll popular IPv6 bittorent end points when that becomes popular. Adrian From steve at ipv6canada.com Wed Apr 28 01:13:09 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Wed, 28 Apr 2010 02:13:09 -0400 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: References: Message-ID: <4BD7D1F5.7050804@ipv6canada.com> On 2010.04.28 00:04, Josh Hoppes wrote: > I'll preface this that I'm more of an end user then a network > administrator, but I do feel I have a good enough understanding of the > protocols and > network administration to submit my two cents. You are always welcome to do so. > The issue I see with this level of NAT, is the fact that I don't > expect that UPNP be implemented at that level. > I would see UPNP as being a security risk and prone to denial of > service attacks when you have torrent clients attempting to grab every > available port. > > Now that's going to create problems with services like Xbox Live which > require UPNP to fully function since at least on one persons > connection > so they can "host" the game. Josh, fwiw, Not trying to hijack this thread, but please go put this over on the ARIN-discuss list. You can subscribe here: http://lists.arin.net/mailman/listinfo/arin-discuss Gaming vendors is a major outreach consideration from what I gathered from around the ARIN meeting, and it would be fantastic if you could take that discussion over there for them (and others) to see... Steve From dot at dotat.at Wed Apr 28 02:19:38 2010 From: dot at dotat.at (Tony Finch) Date: Wed, 28 Apr 2010 08:19:38 +0100 Subject: Mail Submission Protocol In-Reply-To: <4BD7879D.3090208@mompl.net> References: <90AFE804-3CC3-4FE1-A6D6-FD0F79B4AD10@dotat.at> <4BD0324B.3010805@ipax.at> <4BD7879D.3090208@mompl.net> Message-ID: <06CC21A8-F121-43D5-8B2A-B02120E70AE3@dotat.at> Happily Microsoft have fixed their smtps stupidity, so you only need to support it on the server if you need to support users running old versions of Outlook etc. There was never anything particularly wrong with smtps, apart from a dogma in the IETF that it is architecturally wrong. The consensus now is that it was wrong to rescind the port allocation, because that completely failed to stop people (er, Microsoft) from deploying smtps, and just led to interop problems. Tony (on his iPod). -- f.anthony.n.finch http://dotat.at/ On 28 Apr 2010, at 01:55, Jeroen van Aart wrote: > Raoul Bhatia [IPAX] wrote: > > i recently had the problem that an lotus notes server insisted on >> sending emails to one of our clients via port 465. so having >> mandatory >> authentication there actually broke delivery for an exchange sender. > > Leave it "broken" for the other end that is. Only way to force them > to fix it. > > The only acceptable, and standard, way to submit email these days is > using port 587 with TLS. And if you have users with broken clients, > they can use webmail behind https. I am against facilitating (and > thus perpetuating the existence of) old broken clients by making > available port 465. > > Regards, > Jeroen > > -- > http://goldmark.org/jeff/stupid-disclaimers/ > From dot at dotat.at Wed Apr 28 02:29:22 2010 From: dot at dotat.at (Tony Finch) Date: Wed, 28 Apr 2010 08:29:22 +0100 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: <4BD78D19.7010101@cox.net> References: <201004280042.o3S0g9Lm032957@drugs.dv.isc.org> <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> <4BD78D19.7010101@cox.net> Message-ID: Bloom filters work that way. Tony (on his iPod). -- f.anthony.n.finch http://dotat.at/ On 28 Apr 2010, at 02:19, Larry Sheldon wrote: > > (A human brain can respond "I don't know that" without an inventory of > everything it does know.) > > (That may be to only truly unique thing about humans. And no, I have > not kept up with neural networks work.) From mark at streamservice.nl Wed Apr 28 02:31:25 2010 From: mark at streamservice.nl (Mark Scholten) Date: Wed, 28 Apr 2010 09:31:25 +0200 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: References: <201004280042.o3S0g9Lm032957@drugs.dv.isc.org> <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> Message-ID: <00ff01cae6a4$cedb3d20$6c91b760$@nl> > -----Original Message----- > From: David Conrad [mailto:drc at virtualized.org] > Sent: Wednesday, April 28, 2010 3:01 AM > To: Jason 'XenoPhage' Frisvold > Cc: nanog at nanog.org > Subject: Re: [Nanog] Re: IPv6 rDNS - how will it be done? > > On Apr 27, 2010, at 5:47 PM, Jason 'XenoPhage' Frisvold wrote: > > On Apr 27, 2010, at 8:42 PM, Mark Andrews wrote: > >> Windows will just populate the reverse zone as needed, if you let > >> it, using dynamic update. If you have properly deployed BCP 39 > >> and have anti-spoofing ingres filtering then you can just let any > >> address from the /48 add/remove PTR records. Other OS's will > >> follow suite. > > > > Is DDNS really considered to be the end-all answer for this? > > Seems it is that or not bothering with reverse anymore. > > > It seems we're putting an awful lot of trust in the user when doing > this.. I'd rather see some sort of macro expansion in bind/tinydns/etc > that would allow a range of addresses to be added. > > Hmm. A macro expansion for a /48 would mean > 1,208,925,819,614,629,174,706,176 leaves. An interesting stress test > for name servers... :-). With LUA scripting and PowerDNS you could create a reverse DNS/forward DNS based on the input and match it (IP or hostname). This could be really dynamic and with using some cache it should also be fast. Checking what IPv6 address is in use and providing them a rDNS is also an option of course (but I think that will consume more power/bandwith/etc. on the long term). > > Slightly more seriously, there have been discussions in the past about > doing dynamic synthesis of v6 reverses, but that gets icky > (particularly if you invoke the dreaded "DNSSEC" curse) and I don't > know any production server that actually does this now. Dynamic DNS is > probably the least offensive solution if you really want reverses for > your v6 nodes. As long as you don't use DNSSEC the option above is possible, but with DNSSEC many options will fail I think. Completely dynamic based on the request of a client isn't an option if you ask me (or do we want .local addresses in the rDNS?). > > Regards, > -drc > From gordslater at ieee.org Wed Apr 28 02:35:42 2010 From: gordslater at ieee.org (gordon b slater) Date: Wed, 28 Apr 2010 08:35:42 +0100 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD7D1F5.7050804@ipv6canada.com> References: <4BD7D1F5.7050804@ipv6canada.com> Message-ID: <1272440142.21101.1.camel@ub-g-d2> On Wed, 2010-04-28 at 02:13 -0400, Steve Bertrand wrote: > > I would see UPNP as being a security risk and prone to denial of > > service attacks when you have torrent clients attempting to grab > every +1 apologies if I've said this here before - UPNP = unstoppable Peek and Poke Gord From zaphodb at zaphods.net Wed Apr 28 03:53:45 2010 From: zaphodb at zaphods.net (Stefan Schmidt) Date: Wed, 28 Apr 2010 10:53:45 +0200 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: <00ff01cae6a4$cedb3d20$6c91b760$@nl> References: <201004280042.o3S0g9Lm032957@drugs.dv.isc.org> <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> <00ff01cae6a4$cedb3d20$6c91b760$@nl> Message-ID: On 28.04.2010, at 09:31, Mark Scholten wrote: >> >> Hmm. A macro expansion for a /48 would mean >> 1,208,925,819,614,629,174,706,176 leaves. An interesting stress test >> for name servers... :-). > > With LUA scripting and PowerDNS you could create a reverse DNS/ > forward DNS > based on the input and match it (IP or hostname). This could be really > dynamic and with using some cache it should also be fast. Checking > what IPv6 > address is in use and providing them a rDNS is also an option of > course (but > I think that will consume more power/bandwith/etc. on the long term). Lua scripting is available for PowerDNS recursor only i fear, you would want a authoritative DNS solution here and there already is one: This script [1] by Wijnand Modderman is a pipe backend for PowerDNS Server which will provide you with IPv6 forward and reverse entries much like DJB's walldns does for IPv4. Due to the way backends are exhausted for answers subsequently in PowerDNS Server i can have my mysql backend provide IN AAAA and PTR records for hosts that i want named specifically and then let the pipe backend handle all the rest of my /48. >> Slightly more seriously, there have been discussions in the past >> about >> doing dynamic synthesis of v6 reverses, but that gets icky >> (particularly if you invoke the dreaded "DNSSEC" curse) and I don't >> know any production server that actually does this now. Dynamic >> DNS is >> probably the least offensive solution if you really want reverses for >> your v6 nodes. > > As long as you don't use DNSSEC the option above is possible, but with > DNSSEC many options will fail I think. Completely dynamic based on the > request of a client isn't an option if you ask me (or do we > want .local > addresses in the rDNS?). DNSSEC support for PowerDNS Server is on it's way [2] and i think it should integrate with most available backend types not for long, however whats still missing is indeed the dynamic DNS support aka TSIG - i don't need it but i happen to know there have been a few requests for DDNS support in PowerDNS recently, so maybe that will happen too. Stefan [1] http://zaphods.net/~zaphodb/pdns-ipv6-reverse-backend.py [2] http://mailman.powerdns.com/pipermail/pdns-users/2010-April/006671.html From david.iluvatar at gmail.com Wed Apr 28 04:02:56 2010 From: david.iluvatar at gmail.com (=?ISO-8859-1?Q?David_P=E9rez?=) Date: Wed, 28 Apr 2010 11:02:56 +0200 Subject: IPv6 rDNS - how will it be done? Message-ID: Hi! In some internal DNS applications, I've missed the so useful pipe feature of the sendmail alias (user: | /script), I mean, being able to forward a DNS request to a script that returns the resolution response. Maybe something similar would be useful in this IPv6 rDNS scenario too. Does anyone of you know if there's any chance to direct a zone to a script instead of to a file? Regards, David. ----------------------- Message: 1 Date: 28 Apr 2010 01:46:57 -0000 From: John Levine Subject: Re: [Nanog] Re: IPv6 rDNS - how will it be done? To: nanog at nanog.org Message-ID: <20100428014657.91479.qmail at joyce.lan> Content-Type: text/plain; charset=iso-8859-1 >Hmm. A macro expansion for a /48 would mean >1,208,925,819,614,629,174,706,176 leaves. An interesting stress test >for name servers... :-). My inclination would be to use a wildcard that returns something like not-in-service.some-network.net, and let the clients add records for the addresses they use. For spoof resistance, how about doing a forward lookup on the purported name and only installing it if it gets a matching AAAA record? R's, John From zaphodb at zaphods.net Wed Apr 28 04:09:19 2010 From: zaphodb at zaphods.net (Stefan Schmidt) Date: Wed, 28 Apr 2010 11:09:19 +0200 Subject: IPv6 rDNS - how will it be done? In-Reply-To: References: Message-ID: On 28.04.2010, at 11:02, David P?rez wrote: > Hi! Ahoi, > In some internal DNS applications, I've missed the so useful pipe > feature of > the sendmail alias (user: | /script), I mean, being able to forward > a DNS > request to a script that returns the resolution response. Maybe > something similar would be useful in this IPv6 rDNS scenario too. Does > anyone of you know if there's any chance to direct a zone to a script > instead of to a file? Yes, just look at what i just posted and at http://doc.powerdns.com/pipebackend-dynamic-resolution.html http://doc.powerdns.com/backends-detail.html#PIPEBACKEND . Stefan From lemo1980 at gmail.com Wed Apr 28 04:10:00 2010 From: lemo1980 at gmail.com (lemo1980) Date: Wed, 28 Apr 2010 11:10:00 +0200 Subject: IPAM In-Reply-To: <20100426195212.GB64420@macbook.catpipe.net> References: <4BD5B7FD.9040707@bryanfields.net> <4BD5BEEA.3060801@neovera.com> <20100426195212.GB64420@macbook.catpipe.net> Message-ID: We want to go with incognito ipam solution. http://www.incognito.com/products/address-commander/ 2010/4/26 Phil Regnauld > Michael Hertrick (mike.hertrick) writes: > > > > I found netdot recently. It's a work in progress, but is coming along. > > IPAM (with v6 support) is just one component; it has a lot of other > > features and uses as well, too many to list here. Just check out the > > web site: > > > > http://netdot.uoregon.edu > > I'm working on a FreeBSD port of this one, which should make it > much > easier to install. > > Cheers, > Phil > > > From regnauld at nsrc.org Wed Apr 28 04:34:55 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Wed, 28 Apr 2010 11:34:55 +0200 Subject: [dns-operations] Desire to migrate back to BIND Message-ID: <20100428093454.GA34653@macbook.catpipe.net> Had forgotten to answer the list... On 28/04/2010, at 07.07, Steve Bertrand wrote: > What I ask of the members of the community, is if you can make a > recommendation on a piece of software that can bridge the gap so > that my > colleagues can use the pointy-clicky method of making simple changes > (eg: A/MX, add domain etc) while keeping in mind that budget > considerations are crucial, and there will always be the potential for > someone making changes to the zone files directly (namely me). Hi Steve, There is BIND-DLZ and MyDNS to look at but I think both work directly using a bind db driver so no possibility of editing the zone "by hand" (unless you hack some export/import script using the zone transfer functionality. My company developed something that works with both GUI and text zone edition including versioning, but it's not open source unfortunately. It can drive any auth. nameserver software, not just bind. I'm sure there might be other solutions around that do this as well (though I haven't found one yet ;) Cheers, Phil From franck at genius.com Wed Apr 28 04:54:18 2010 From: franck at genius.com (Franck Martin) Date: Wed, 28 Apr 2010 21:54:18 +1200 (MAGST) Subject: [dns-operations] Desire to migrate back to BIND In-Reply-To: <20100428093454.GA34653@macbook.catpipe.net> Message-ID: <30262889.1326.1272448457942.JavaMail.franck@franck-martins-macbook-pro.local> Webmin? ----- Original Message ----- From: "Phil Regnauld" To: "NANOG list" Sent: Wednesday, 28 April, 2010 9:34:55 PM Subject: Re: [dns-operations] Desire to migrate back to BIND Had forgotten to answer the list... On 28/04/2010, at 07.07, Steve Bertrand wrote: > What I ask of the members of the community, is if you can make a > recommendation on a piece of software that can bridge the gap so > that my > colleagues can use the pointy-clicky method of making simple changes > (eg: A/MX, add domain etc) while keeping in mind that budget > considerations are crucial, and there will always be the potential for > someone making changes to the zone files directly (namely me). Hi Steve, There is BIND-DLZ and MyDNS to look at but I think both work directly using a bind db driver so no possibility of editing the zone "by hand" (unless you hack some export/import script using the zone transfer functionality. My company developed something that works with both GUI and text zone edition including versioning, but it's not open source unfortunately. It can drive any auth. nameserver software, not just bind. I'm sure there might be other solutions around that do this as well (though I haven't found one yet ;) Cheers, Phil From a.harrowell at gmail.com Wed Apr 28 06:28:30 2010 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Wed, 28 Apr 2010 12:28:30 +0100 Subject: Starting up a WiMAX ISP In-Reply-To: References: <20100428014123.91390.qmail@joyce.lan> <4BD793BD.5050906@spectraaccess.com> Message-ID: <201004281228.43833.a.harrowell@gmail.com> On Wednesday 28 April 2010 03:13:24 John R. Levine wrote: > > Of course what they offer over those "long long rural runs" and what they can > > actually provide are two different things. DSL performance decreases with > > distance rather dramatically.. > > That's what I thought, but my friend out on the sheep farm in the next > county says he gets 3Mb just like I do in the village three blocks from > the CO. (Yes, he knows what he's talking about.) They must spend a lot > on repeaters and concentrators. > > R's, > John > > There is a great deal of relevant experience here: http://www.wirelesscowboys.com/ -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From deleskie at gmail.com Wed Apr 28 07:02:46 2010 From: deleskie at gmail.com (jim deleskie) Date: Wed, 28 Apr 2010 09:02:46 -0300 Subject: comcast enterprise/carrier services In-Reply-To: <20100427134729.2920ABFF@resin14.mta.everyone.net> References: <20100427134729.2920ABFF@resin14.mta.everyone.net> Message-ID: You might read it that way, I read it as looking for a sales droid recommendation. I'm sure Comcast has more then one. On Tue, Apr 27, 2010 at 5:47 PM, Scott Weeks wrote: > > --- carlos at race.com wrote: > > Looking for a sales contact for Comcast enterprise/carrier services for > > > ------Original Message------ > From: Scott Weeks > > Please, please, PLEASE do not encourage sales droids like this. > > > --- deleskie at gmail.com wrote: ------ > > I'm wondering how can someone recomend a vendor for X be diffrent from, Can someone recond a box that does Y. I'm no fan of blind calls from sales droids anymore more then the next person but I see this posting as relevant or more then many post here. > ----------------------------------------------------- > > > > He is not asking for a vendor comparison from list members. ?He is asking Comcast sales lurkers to contact him. ?Otherwise, he would've gone to http://business.comcast.com/ethernet/dedicated-internet.aspx and found the info there. > > scott > > From steve at ipv6canada.com Wed Apr 28 07:09:49 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Wed, 28 Apr 2010 08:09:49 -0400 Subject: [dns-operations] Desire to migrate back to BIND In-Reply-To: <20100428093454.GA34653@macbook.catpipe.net> References: <20100428093454.GA34653@macbook.catpipe.net> Message-ID: <4BD8258D.2000901@ipv6canada.com> On 2010.04.28 05:34, Phil Regnauld wrote: > Had forgotten to answer the list... > > On 28/04/2010, at 07.07, Steve Bertrand wrote: > >> What I ask of the members of the community, is if you can make a >> recommendation on a piece of software that can bridge the gap so >> that my >> colleagues can use the pointy-clicky method of making simple changes >> (eg: A/MX, add domain etc) while keeping in mind that budget >> considerations are crucial, and there will always be the potential for >> someone making changes to the zone files directly (namely me). > > Hi Steve, > > There is BIND-DLZ and MyDNS to look at but I think both work directly > using a bind db driver so no possibility of editing the zone "by hand" > (unless you hack some export/import script using the zone transfer > functionality. Thanks for the recommendations... What I'm most confused about, is how this ended up on this list ;) Steve From steve at ipv6canada.com Wed Apr 28 07:11:11 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Wed, 28 Apr 2010 08:11:11 -0400 Subject: [dns-operations] Desire to migrate back to BIND In-Reply-To: <30262889.1326.1272448457942.JavaMail.franck@franck-martins-macbook-pro.local> References: <30262889.1326.1272448457942.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4BD825DF.6080006@ipv6canada.com> On 2010.04.28 05:54, Franck Martin wrote: > Webmin? Webmin has already been recommended, and I appreciate the thought. However...there's just no way that I'm going there... Steve From regnauld at nsrc.org Wed Apr 28 07:18:30 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Wed, 28 Apr 2010 14:18:30 +0200 Subject: [dns-operations] Desire to migrate back to BIND In-Reply-To: <4BD8258D.2000901@ipv6canada.com> References: <20100428093454.GA34653@macbook.catpipe.net> <4BD8258D.2000901@ipv6canada.com> Message-ID: <20100428121829.GB34653@macbook.catpipe.net> Steve Bertrand (steve) writes: > > Thanks for the recommendations... > > What I'm most confused about, is how this ended up on this list ;) Duh. I did a reply from my iPhone, and then reread the mail that came in, saw your "what I ask from the community" and realized I'd forgotten to copy the list. Then I typed "n" instead of "d" an it completed to Nanog instead of dns-operations at lists.dns-oarc.net :) Sorry for the noise :( From jbates at brightok.net Wed Apr 28 08:14:48 2010 From: jbates at brightok.net (Jack Bates) Date: Wed, 28 Apr 2010 08:14:48 -0500 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: <5D2F7A42-AD4B-4FB8-8BFA-FA5458BEB742@virtualized.org> References: <20100428014657.91479.qmail@joyce.lan> <5D2F7A42-AD4B-4FB8-8BFA-FA5458BEB742@virtualized.org> Message-ID: <4BD834C8.9020503@brightok.net> David Conrad wrote: > While better than 1 septillion zone entries, you still have the problem of how to let the clients add the records. DDNS is one approach. Manual intervention (e.g., as part of a customer provisioning system) is another as long as you don't use privacy extensions. Realtime updates to zonedata as the IP is seen. Dual detections of IP (ddns, which we won't allow, but easy detection of IP assigned) and edge detection in security/tracking layer (perhaps as fallback, 5-10minute delay) in case their setup isn't trying ddns to our nameservers. Jack From joe.abley at icann.org Wed Apr 28 08:29:37 2010 From: joe.abley at icann.org (Joe Abley) Date: Wed, 28 Apr 2010 06:29:37 -0700 Subject: DNSSEC Deployment in ARPA Children Message-ID: <00798CDC-AC6C-4E59-AB7D-D698250126BA@icann.org> Colleagues, ICANN plans to begin a test deployment of DNSSEC in various zones starting on 2010-04-29: IN-ADDR-SERVERS.ARPA IP6.ARPA IP6-SERVERS.ARPA IRIS.ARPA URI.ARPA URN.ARPA These zones will be signed using RSASHA256 and NSEC with 2048-bit KSKs and 1024-bit ZSKs. Given DNSSEC deployment experience to date, ICANN does not expect the signing of these zones to cause any operational problems. However, should you have any concerns please feel free to contact us at ticket at dns.icann.org or phone +1 310 301 5810 (e-mail/ticket preferred). At the end of the test period, given no observed or reported harmful effects, ICANN will arrange for trust anchors for these zones to be included in ARPA as DS RRSets and will invite the five RIRs to submit DS RRSet add/delete requests in IP6.ARPA when they are ready. We anticipate the testing period to last at least two weeks. Regards, Joe Abley Director DNS Operations, ICANN From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Apr 28 08:37:04 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 28 Apr 2010 23:07:04 +0930 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD72D1E.60506@otd.com> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72D1E.60506@otd.com> Message-ID: <20100428230704.4119ebd3@opy.nosense.org> On Tue, 27 Apr 2010 14:29:50 -0400 Dave Israel wrote: > On 4/27/2010 1:36 PM, Andy Davidson wrote: > > On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote: > > > >>> Did you use Yahoo IM, AIM, or Skype? > >>> > >> Yes, yes, and yes. Works fine. > >> > > What about every other service/protocol that users use today, > > and might be invented tomorrow ? Do & will they all work with > > NAT ? > > > > Sure, I can invent a service/protocol that doesn't work with NAT. While > I am at it, I'll make it not work with IPv4, IPv6, Ethernet, an > architectures using less than 256 bits of memory addressing. I bet > it'll be popular! > > One already exists. It's called DCCP, or Datagram Congestion Control Protocol - it's like UDP with congestion management. It'd be great to use for Video and Voip, which could then vary the codec parameters to suit congestion should it occur. Shame NAT has stopped it being widely deployed. SCTP could be used to perform peer to peer IM and file transfers, where the file transfer takes place within the existing SCTP connection, rather than having to establish a separate connection. Shame NAT has stopped it being widely deployed. > > Do many others work as well or act reliably through NAT ? > > > > Yes, nearly everything that end users use works great through NAT, > because end users are often behind NAT and for a service to be popular, > it has to be NAT-friendly. Protocols that are not NAT friendly and yet > survive are generally LAN applications that are resting on their > NAT-unferiendliness and calling it security. > > > Will it stop or hamper the innovation of new services on the > > internet ? > > > > Nope. > > > The answer to these questions isn't a good one for users, so > > as the community that are best placed to defend service quality > > and innovation by preserving the end to end principal, it is > > our responsibility to defend it to the best of our ability. > > > > The end to end principle only helps service quality and innovation when > the services are built on an end to end model. In a client-server world > where addresses only identify groups of endpoints and individual > identification is done at higher layers (which is what the ipv4+NAT > Internet is looking like), end to endness is an anomaly, not the norm. > > > So get busy - v6 awareness, availability and abundancy are > > overdue for our end users. > > > > Nearly all of the end users don't give a rat's hindquarters about ipv6. > It gives them nothing they know that they want. Meanwhile, those who do > know they want it are getting used to working around it, using PAT > tricks and STUN services. Should people *have* to use those services? > No. But there's so many other things that we shouldn't have to do, but > we do anyway because that's how it works, that these NAT-circumvention > tricks are not a dealbreaker. > > Meanwhile, the NATification of the Internet continuously increases the > contrast between services (with real addresses) and clients (with shared > addresses). Over time, this differentiation will increase and become > more and more a standard (a de facto one if not an actual codified > one.) Clients will have shared, ephemeral addresses, and services will > have stable ones. This helps ensure that clients cannot generally > communicate without a facilitating service, and every transaction will > then have a middleman, somebody you have to pay somehow to get your > services. You may pay in cash, by watching commercials, by sacrificing > personal information, or by submitting your communciations to analysis > by others, but somehow, you will pay. The vast majority of users won't > care; they communicate that way now, and it does not bother them much. > It's only those few who want to communicate without paying, in time, > money, or privacy, or to communicate in ways other than the standard > protocols, who will really suffer. And their complaints will have to > fight against the voice of those who will say, well, if you make it end > to end, then businesses lose money, and people will be able to share > files again and violate copyrights, and all these things will cost jobs > and tax dollars, etc, etc. > > If you want to avoid that future, I strongly suggest you deploy ipv6 and > pressure others to do the same. But you're going to need to use valid > arguments, about privacy and protection from the deprecations of > unscrupulous middlemen, instead of insisting that the Internet will > break down and die and locusts will descend from the heavens and eat our > first born if we don't. > > -Dave > > From mark.mayfield at metro-inet.us Wed Apr 28 08:38:20 2010 From: mark.mayfield at metro-inet.us (Mark Mayfield) Date: Wed, 28 Apr 2010 08:38:20 -0500 Subject: VPN over Comcast In-Reply-To: <79AF0C3901752A49881FE4CB31F7AA4001A16D06@abn-borg2.NETABN.LOCAL> References: <79AF0C3901752A49881FE4CB31F7AA4001A16D06@abn-borg2.NETABN.LOCAL> Message-ID: <96CD2407B3027C4DACC7A0222BD3C4789FA41BFF0E@RVMAIL802.metro-inet.us> In June of last year, when Comcast did firmware updates on the business gateways in the MSP area, we lost all (3) of our sites with Netgear gateways, but not the sites SMC gateways (the management interface is almost identical, but the brand is marked on the modem). Business support was apparently aware of a Cisco VPN problem through the Netgear, and simply replaced the Netgear units with SMC, and we haven't had issues since. This is IOS to ASA site-to-site VPN. Mark Mayfield City of Roseville Network Systems Engineer 2660 Civic Center Drive Roseville, MN 55113 -----Original Message----- From: Michael Malitsky [mailto:malitsky at netabn.com] Sent: Tuesday, April 27, 2010 12:43 PM To: nanog at nanog.org Subject: VPN over Comcast I will probably be laughed at, but I'll ask just in case. We are having particularly bad luck trying to run VPN tunnels over Comcast cable in the Chicago area. The symptoms are basically complete loss of connectivity (lasting minutes to sometimes hours), or sometimes flapping for a period of time. More often than not, a reboot of the cable modem is required. The most interesting ones involve the following: a PIX or ASA configured as an EZvpn client, connecting to a 3000 concentrator, authentication over RADIUS. When I go to look at the RADIUS logs, I see connections from the same box with small intervals. Timeout is 8 hours, so theoretically I should see 3 connections in a 24-hr period. In some cases, I see dozens, in the most egregious cases, thousands over a 24-hour period. I am taking that as an indicator of a really unstable Comcast circuit. We have not had this problem with any other ISP, anywhere in the country. I am pretty much down to telling customers to find another provider... Any thoughts or ideas on the matter will be appreciated. PS. To be fair (?) to Comcast, this is not a ubiquitous problem. It affects about 25% of the installations I get to see. Sincerely, Michael Malitsky Confidentiality Statement: The documents accompanying this transmission contain confidential information that is legally privileged. This information is intended only for the use of the individuals or entities listed above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or action taken in reliance on the contents of these documents is strictly prohibited. If you have received this information in error, please notify the sender immediately and arrange for the return or destruction of these documents. From MAdcock at hisna.com Wed Apr 28 08:42:11 2010 From: MAdcock at hisna.com (Adcock, Matt [HISNA]) Date: Wed, 28 Apr 2010 06:42:11 -0700 Subject: comcast enterprise/carrier services References: <859604546CD1FF488BDB6EA94C896AFBE0568C@racexchange.race.local> Message-ID: IMHO the cable provider and enterprise provider subsets have no intersection. I've never had a good experience with a cable provider trying to pretend to be an enterprise provider. Thanks, Matt ? ?Matt Adcock, Manager 334-481-6629 (w) / 334-312-5393 (m) / MAdcock at hisna.com 700 Hyundai Blvd.?/ Montgomery, AL 36105 P The average office worker uses 10,000 sheets of paper = 1.2 trees, per year By not printing this email, you?ve saved paper, ink and millions of trees ? From: Carlos Alcantar [mailto:carlos at race.com] Sent: Tue 4/27/2010 12:27 PM To: nanog at nanog.org Subject: comcast enterprise/carrier services Looking for a sales contact for Comcast enterprise/carrier services for there Ethernet product thanks. Carlos Alcantar Race Telecommunications, Inc. 101 Haskins Way South San Francisco, CA 94080 P: 650.649.3550 x143 F: 650.649.3551 E: carlos (at) race.com ? 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 ? -------------- next part -------------- A non-text attachment was scrubbed... Name: vertical_bar.gif Type: image/gif Size: 1391 bytes Desc: vertical_bar.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.gif Type: image/gif Size: 1745 bytes Desc: logo.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: horizontal_bar.gif Type: image/gif Size: 1418 bytes Desc: horizontal_bar.gif URL: From LarrySheldon at cox.net Wed Apr 28 08:54:37 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 28 Apr 2010 08:54:37 -0500 Subject: [Nanog] Re: IPv6 rDNS - how will it be done? In-Reply-To: References: <201004280042.o3S0g9Lm032957@drugs.dv.isc.org> <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com> <4BD78D19.7010101@cox.net> Message-ID: <4BD83E1D.1040100@cox.net> On 4/28/2010 02:29, Tony Finch wrote: > Bloom filters work that way. I charge the time to order, index, hash the key space so that can work. I don't know what a fair distribution of that cost would be. > Tony (on his iPod). Larry on his.....oh, who cares? -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From william.mccall at gmail.com Wed Apr 28 09:09:23 2010 From: william.mccall at gmail.com (William McCall) Date: Wed, 28 Apr 2010 09:09:23 -0500 Subject: DDoS mitigation services from SPs Message-ID: All: I did some searching and have not found any concrete replies on the list, but what carriers can offer L3 DDoS mitigation? Specifically, I noticed an old UUnet offering, but it seems like I must be speaking the wrong language to my sales drones. Specifically, we're dealing with AT&T, Qwest and Verizon Business. My thought is that they all offered some type of service like this, but my security folks have been driving this and having limited success. Names of other SPs (we're looking at Verisign) is helpful, but we are stuck with the Dallas area. Note: I am not interested in changing DNS records and prefixes should be able to be advertised through BGP like normal. (Apparently, people like to do funky DNS stuff to make this work and sometimes don't want to do BGP in other scenarios.) Thanks in advance, -- William McCall From ops.lists at gmail.com Wed Apr 28 09:14:12 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 28 Apr 2010 19:44:12 +0530 Subject: DDoS mitigation services from SPs In-Reply-To: References: Message-ID: Might also try Prolexic. Or level3, which resells Prolexic. And then there's other forms of redundancy - ultradns or similar for your nameservers, for example. On Wed, Apr 28, 2010 at 7:39 PM, William McCall wrote: > All: > > I did some searching and have not found any concrete replies on the > list, but what carriers can offer L3 DDoS mitigation? Specifically, I > noticed an old UUnet offering, but it seems like I must be speaking > the wrong language to my sales drones. Specifically, we're dealing > with AT&T, Qwest and Verizon Business. My thought is that they all > offered some type of service like this, but my security folks have > been driving this and having limited success. > > Names of other SPs (we're looking at Verisign) is helpful, but we are > stuck with the Dallas area. > > Note: I am not interested in changing DNS records and prefixes should > be able to be advertised through BGP like normal. (Apparently, people > like to do funky DNS stuff to make this work and sometimes don't want > to do BGP in other scenarios.) > > Thanks in advance, > > -- > William McCall > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From sfouant at shortestpathfirst.net Wed Apr 28 09:25:07 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Wed, 28 Apr 2010 10:25:07 -0400 Subject: DDoS mitigation services from SPs In-Reply-To: References: Message-ID: <001301cae6de$9b06e910$d114bb30$@net> > -----Original Message----- > From: William McCall [mailto:william.mccall at gmail.com] > Sent: Wednesday, April 28, 2010 10:09 AM > To: nanog at nanog.org > Subject: DDoS mitigation services from SPs > > All: > > I did some searching and have not found any concrete replies on the > list, but what carriers can offer L3 DDoS mitigation? Specifically, I > noticed an old UUnet offering, but it seems like I must be speaking > the wrong language to my sales drones. Specifically, we're dealing > with AT&T, Qwest and Verizon Business. My thought is that they all > offered some type of service like this, but my security folks have > been driving this and having limited success. > > Names of other SPs (we're looking at Verisign) is helpful, but we are > stuck with the Dallas area. > > Note: I am not interested in changing DNS records and prefixes should > be able to be advertised through BGP like normal. (Apparently, people > like to do funky DNS stuff to make this work and sometimes don't want > to do BGP in other scenarios.) Verizon Business and AT&T both have DDoS Detection & Mitigation Services available, as do other providers such as Tata, Prolexic, and Verisign. Providers like AT&T, Verizon, and Tata unfortunately do not sell services off-net, so you'll need to have the sites you want protected connected to their networks. Similarly, these providers tend to put "all their eggs in one basket" by using a singular technology for their service. On the other hand, providers like Prolexic and Verisign have very robust offerings selling off-net and utilizing multiple vendors as they understand a one-size-fits-all doesn't work. I'd strongly advocate talking to the Verisign folks as they really seem to be attracting all the top talent right now - I'd be willing to bet their offering is the one that others will eventually emulate. Cheers, Stefan Fouant, CISSP, JNCIEx2 www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From jabley at hopcount.ca Wed Apr 28 09:49:37 2010 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 28 Apr 2010 10:49:37 -0400 Subject: Connectivity to an IPv6-only site In-Reply-To: References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> <538D27E2-4771-4420-821D-BA8879B6822A@delong.com> <5598.1272031635@localhost> <201004231645.o3NGj5e5066388@drugs.dv.isc.org> <14793.1272042510@localhost> <4BD35F5B.8060904@brightok.net> <4BD5A473.9050309@sprunk.org> Message-ID: On 2010-04-26, at 11:07, Christopher Morrow wrote: > On Mon, Apr 26, 2010 at 10:34 AM, Stephen Sprunk wrote: > >> Don't forget the hotspot vendor that returns an address of 0.0.0.1 for >> every A query if you have previously done an AAAA query for the same >> name (and timed out). That's a fun one. > > so... aside from the every 3 months bitching on this list (and some on > v6ops maybe) about these sorts of things, what's happening to > tell/educate/warn/notice the hotspot-vendors that this sort of > practice (along with 'everything is at 1.1.1.1!') is just a bad plan? > How can users, even more advanced users, tell a hotspot vendor in a > meaningful way that their 'solution' is broken? It seems like a good step in the right direction would be to determine an approach that makes sense and to document it. Such an approach which made minimal exotic demands of client or hotspot (or back-end) systems might seem attractive to hotspot operators if it seemed likely to minimise support costs, or reduce development costs through re-use of free software components, or something. Does such an approach exist? Is it documented? Joe From matthew at matthew.at Wed Apr 28 10:44:41 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 28 Apr 2010 08:44:41 -0700 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <20100428230704.4119ebd3@opy.nosense.org> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72D1E.60506@otd.com> <20100428230704.4119ebd3@opy.nosense.org> Message-ID: <4BD857E9.2010407@matthew.at> Mark Smith wrote: > On Tue, 27 Apr 2010 14:29:50 -0400 > Dave Israel wrote: > > >> On 4/27/2010 1:36 PM, Andy Davidson wrote: >> >>> On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote: >>> >>> >>>>> Did you use Yahoo IM, AIM, or Skype? >>>>> >>>>> >>>> Yes, yes, and yes. Works fine. >>>> >>>> >>> What about every other service/protocol that users use today, >>> and might be invented tomorrow ? Do & will they all work with >>> NAT ? >>> >>> >> Sure, I can invent a service/protocol that doesn't work with NAT. While >> I am at it, I'll make it not work with IPv4, IPv6, Ethernet, an >> architectures using less than 256 bits of memory addressing. I bet >> it'll be popular! >> >> >> > > One already exists. It's called DCCP, or Datagram Congestion Control > Protocol - it's like UDP with congestion management. It'd be great to > use for Video and Voip, which could then vary the codec parameters to > suit congestion should it occur. Shame NAT has stopped it being widely > deployed. > > SCTP could be used to perform peer to peer IM and file transfers, where > the file transfer takes place within the existing SCTP connection, > rather than having to establish a separate connection. Shame NAT has > stopped it being widely deployed. > Mark, I think you made Dave's point perfectly. Sure, history will be littered with protocols developed after NAT was widespread but whose designers willfully ignored reality (often committees filled with a bunch of people who wanted to acknowledge reality and a few strong voices who want to pretend there's a world without NAT both now and in the IPv6 future). Many of these won't see wide deployment as a result. You can add SIP and SDP to the list, as those were designed with an FTP-like belief that you can know your local address and send it around in the payload and expect the right thing to happen. (FTP at least had the excuse that it predated NAT deployment)... though SIP, for some inexplicable reason, has survived to make it to wide deployment anyway. Or you can run things like DCCP and SCTP encapsulated in UDP (works just fine), or design a new protocol that combines the best of DCCP and SCTP and DTLS and mix in some IP mobility and other features and deploy it to almost every Internet host (what I did... the protocol is RTMFP and it is in every copy of Flash Player since version 10.0), or design a new protocol for your application which does what DCCP and DTLS do only for your own widely deployed application (as the Skype folks did). All of these are excellent approaches for having something which *actually works*, though impefectly as the backlash against NATs in groups such as the IETF has lead to a big lack of standards around how they should work. Either applications learn to deal with NAT, in which case they thrive on both the heavily-NATed still-mostly-IPv4 Internet of the future *or* the has-NAT mostly-IPv6 Internet of the future (a great way to hedge your bets if you're writing protocols and applications)... or they don't learn to deal with NAT, in which case they don't work on todays IPv4 Internet *and* they won't work on the heavily-NATed still-mostly-IPv4 Internet of one possible future *or* the has-NAT mostly-IPv6 Internet of the future. Those won't be nearly as popular. And in case you don't have handy a short list of why the IPv6 Internet will be filled with NAT, I'll give you three items to start with: 1. SOX, HIPPA, and other audit checklist compliance currently requires NAT for (theoretical) fail-closed and topology hiding. If IPv6 NAT exists, this requirement may not go away. 2. There will be a requirement for client hosts which have IPv6 SLAAC implementations that expose their MAC address in the low address bits to have those bits hidden from the outside Internet. 3. Organizations not large enough to qualify for (or who don't wish to bother with) PI space will deploy NAT so as to avoid internal renumbering of things which must have static addresses (Intranet servers, DNS resolvers, etc.). This is because the IPv6 future where every LAN is carrying multiple PA addresses to every host wasn't sufficiently well designed for it to actually work for either the multihoming case or the interior-network/outside-Internet case. The good news is that it might be sufficient to do pure NAT and not NAPT, and it might be possible still to get some good standards around how these devices should behave... both of which aren't happening for the IPv4 Internet, unfortunately. Matthew Kaufman From jesse.proudman-lists at blueboxgrp.com Wed Apr 28 11:04:26 2010 From: jesse.proudman-lists at blueboxgrp.com (Jesse Proudman) Date: Wed, 28 Apr 2010 09:04:26 -0700 Subject: DDoS mitigation services from SPs In-Reply-To: <001301cae6de$9b06e910$d114bb30$@net> References: <001301cae6de$9b06e910$d114bb30$@net> Message-ID: <9F61CDCF-FEF2-4A94-840D-81A30BD9338E@blueboxgrp.com> Does any one have a contact at Prolexic? I've been attempting to get in touch with their sales force for 2-3 weeks with no success. Thanks, Jesse Proudman Blue Box Group, LLC p. 800-613-4305 x 801 www.blueboxgrp.com On Apr 28, 2010, at 7:25 AM, Stefan Fouant wrote: > Verizon Business and AT&T both have DDoS Detection & Mitigation Services > available, as do other providers such as Tata, Prolexic, and Verisign. > Providers like AT&T, Verizon, and Tata unfortunately do not sell services > off-net, so you'll need to have the sites you want protected connected to > their networks. Similarly, these providers tend to put "all their eggs in > one basket" by using a singular technology for their service. On the other > hand, providers like Prolexic and Verisign have very robust offerings > selling off-net and utilizing multiple vendors as they understand a > one-size-fits-all doesn't work. I'd strongly advocate talking to the > Verisign folks as they really seem to be attracting all the top talent right > now - I'd be willing to bet their offering is the one that others will > eventually emulate. From emanuelp at gmail.com Wed Apr 28 12:25:44 2010 From: emanuelp at gmail.com (Emanuel Paul) Date: Wed, 28 Apr 2010 14:25:44 -0300 Subject: IPAM In-Reply-To: References: <4BD5B7FD.9040707@bryanfields.net> <4BD5BEEA.3060801@neovera.com> <20100426195212.GB64420@macbook.catpipe.net> Message-ID: IPPlan currently does have IPv6 functionality, but we're still on BETA phase. The BETA is pretty stable and feature rich, but we're have some work to do before we officially release it. BETA version can be found on: http://sourceforge.net/projects/iptrack/files/ On Wed, Apr 28, 2010 at 6:10 AM, lemo1980 wrote: > We want to go with incognito ipam solution. > http://www.incognito.com/products/address-commander/ > > 2010/4/26 Phil Regnauld > >> Michael Hertrick (mike.hertrick) writes: >> > >> > I found netdot recently. ?It's a work in progress, but is coming along. >> > ?IPAM (with v6 support) is just one component; it has a lot of other >> > features and uses as well, too many to list here. ?Just check out the >> > web site: >> > >> > http://netdot.uoregon.edu >> >> ? ? ? ? I'm working on a FreeBSD port of this one, which should make it >> much >> ? ? ? ?easier to install. >> >> ? ? ? ?Cheers, >> ? ? ? ? Phil >> >> >> > From jeffrey.lyon at blacklotus.net Wed Apr 28 12:33:25 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 28 Apr 2010 13:33:25 -0400 Subject: DDoS mitigation services from SPs In-Reply-To: <9F61CDCF-FEF2-4A94-840D-81A30BD9338E@blueboxgrp.com> References: <001301cae6de$9b06e910$d114bb30$@net> <9F61CDCF-FEF2-4A94-840D-81A30BD9338E@blueboxgrp.com> Message-ID: I'm not sure they have a sales force anymore, one of the VP's is handling sales inquiries now so it's not a surprise that responses are latent or worse. Jeff On Wed, Apr 28, 2010 at 12:04 PM, Jesse Proudman wrote: > Does any one have a contact at Prolexic? ?I've been attempting to get in touch with their sales force for 2-3 weeks with no success. > > Thanks, > > Jesse Proudman > Blue Box Group, LLC > p. 800-613-4305 x 801 > www.blueboxgrp.com > > On Apr 28, 2010, at 7:25 AM, Stefan Fouant wrote: > >> Verizon Business and AT&T both have DDoS Detection & Mitigation Services >> available, as do other providers such as Tata, Prolexic, and Verisign. >> Providers like AT&T, Verizon, and Tata unfortunately do not sell services >> off-net, so you'll need to have the sites you want protected connected to >> their networks. ?Similarly, these providers tend to put "all their eggs in >> one basket" by using a singular technology for their service. ?On the other >> hand, providers like Prolexic and Verisign have very robust offerings >> selling off-net and utilizing multiple vendors as they understand a >> one-size-fits-all doesn't work. ?I'd strongly advocate talking to the >> Verisign folks as they really seem to be attracting all the top talent right >> now - I'd be willing to bet their offering is the one that others will >> eventually emulate. > > > > -- 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 tsands at rackspace.com Wed Apr 28 15:31:56 2010 From: tsands at rackspace.com (Tom Sands) Date: Wed, 28 Apr 2010 15:31:56 -0500 Subject: DDoS mitigation services from SPs In-Reply-To: <9F61CDCF-FEF2-4A94-840D-81A30BD9338E@blueboxgrp.com> References: <001301cae6de$9b06e910$d114bb30$@net> <9F61CDCF-FEF2-4A94-840D-81A30BD9338E@blueboxgrp.com> Message-ID: <28949_1272486774_o3SKVWoO031564_4BD89B3C.7010102@rackspace.com> Michael Renshaw Director of Global Partner Sales O 954-620-6002 x1018 D 954-620-1318 mrenshaw at prolexic.com -------------------------------------------------------------------------------- Tom Sands Chief Network Engineer Rackspace (210)312-4391 -------------------------------------------------------------------------------- Jesse Proudman wrote: > Does any one have a contact at Prolexic? I've been attempting to get in touch with their sales force for 2-3 weeks with no success. > > Thanks, > > Jesse Proudman > Blue Box Group, LLC > p. 800-613-4305 x 801 > www.blueboxgrp.com > > On Apr 28, 2010, at 7:25 AM, Stefan Fouant wrote: > >> Verizon Business and AT&T both have DDoS Detection & Mitigation Services >> available, as do other providers such as Tata, Prolexic, and Verisign. >> Providers like AT&T, Verizon, and Tata unfortunately do not sell services >> off-net, so you'll need to have the sites you want protected connected to >> their networks. Similarly, these providers tend to put "all their eggs in >> one basket" by using a singular technology for their service. On the other >> hand, providers like Prolexic and Verisign have very robust offerings >> selling off-net and utilizing multiple vendors as they understand a >> one-size-fits-all doesn't work. I'd strongly advocate talking to the >> Verisign folks as they really seem to be attracting all the top talent right >> now - I'd be willing to bet their offering is the one that others will >> eventually emulate. > > > > Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Apr 28 16:29:12 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 29 Apr 2010 06:59:12 +0930 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD857E9.2010407@matthew.at> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72D1E.60506@otd.com> <20100428230704.4119ebd3@opy.nosense.org> <4BD857E9.2010407@matthew.at> Message-ID: <20100429065912.2f478885@opy.nosense.org> On Wed, 28 Apr 2010 08:44:41 -0700 Matthew Kaufman wrote: > Mark Smith wrote: > > On Tue, 27 Apr 2010 14:29:50 -0400 > > Dave Israel wrote: > > > > > >> On 4/27/2010 1:36 PM, Andy Davidson wrote: > >> > >>> On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote: > >>> > >>> > >>>>> Did you use Yahoo IM, AIM, or Skype? > >>>>> > >>>>> > >>>> Yes, yes, and yes. Works fine. > >>>> > >>>> > >>> What about every other service/protocol that users use today, > >>> and might be invented tomorrow ? Do & will they all work with > >>> NAT ? > >>> > >>> > >> Sure, I can invent a service/protocol that doesn't work with NAT. While > >> I am at it, I'll make it not work with IPv4, IPv6, Ethernet, an > >> architectures using less than 256 bits of memory addressing. I bet > >> it'll be popular! > >> > >> > >> > > > > One already exists. It's called DCCP, or Datagram Congestion Control > > Protocol - it's like UDP with congestion management. It'd be great to > > use for Video and Voip, which could then vary the codec parameters to > > suit congestion should it occur. Shame NAT has stopped it being widely > > deployed. > > > > SCTP could be used to perform peer to peer IM and file transfers, where > > the file transfer takes place within the existing SCTP connection, > > rather than having to establish a separate connection. Shame NAT has > > stopped it being widely deployed. > > > Mark, I think you made Dave's point perfectly. Sure, history will be > littered with protocols developed after NAT was widespread but whose > designers willfully ignored reality (often committees filled with a > bunch of people who wanted to acknowledge reality and a few strong > voices who want to pretend there's a world without NAT both now and in > the IPv6 future). Many of these won't see wide deployment as a result. > I'm not people are understanding or know the true reality. NAT broke the Internet's architecture, by turning IP from being a peer-to-peer protocol into a master/slave one (think mainframes and dumb terminals). Read RFC1958 if you don't understand what that means, specifically the 'end-to-end' principle part. IPv6's fundamental goal is to restore end-to-end. > You can add SIP and SDP to the list, as those were designed with an > FTP-like belief that you can know your local address and send it around > in the payload and expect the right thing to happen. (FTP at least had > the excuse that it predated NAT deployment)... though SIP, for some > inexplicable reason, has survived to make it to wide deployment anyway. > > Or you can run things like DCCP and SCTP encapsulated in UDP (works just > fine), or design a new protocol that combines the best of DCCP and SCTP > and DTLS and mix in some IP mobility and other features and deploy it to > almost every Internet host (what I did... the protocol is RTMFP and it > is in every copy of Flash Player since version 10.0), or design a new > protocol for your application which does what DCCP and DTLS do only for > your own widely deployed application (as the Skype folks did). All of > these are excellent approaches for having something which *actually > works*, though impefectly as the backlash against NATs in groups such as > the IETF has lead to a big lack of standards around how they should work. > > Either applications learn to deal with NAT, in which case they thrive on > both the heavily-NATed still-mostly-IPv4 Internet of the future *or* the > has-NAT mostly-IPv6 Internet of the future (a great way to hedge your > bets if you're writing protocols and applications)... or they don't > learn to deal with NAT, in which case they don't work on todays IPv4 > Internet *and* they won't work on the heavily-NATed still-mostly-IPv4 > Internet of one possible future *or* the has-NAT mostly-IPv6 Internet of > the future. Those won't be nearly as popular. > > And in case you don't have handy a short list of why the IPv6 Internet > will be filled with NAT, I'll give you three items to start with: > > 1. SOX, HIPPA, and other audit checklist compliance currently requires > NAT for (theoretical) fail-closed and topology hiding. If IPv6 NAT > exists, this requirement may not go away. > 2. There will be a requirement for client hosts which have IPv6 SLAAC > implementations that expose their MAC address in the low address bits to > have those bits hidden from the outside Internet. > 3. Organizations not large enough to qualify for (or who don't wish to > bother with) PI space will deploy NAT so as to avoid internal > renumbering of things which must have static addresses (Intranet > servers, DNS resolvers, etc.). This is because the IPv6 future where > every LAN is carrying multiple PA addresses to every host wasn't > sufficiently well designed for it to actually work for either the > multihoming case or the interior-network/outside-Internet case. > > The good news is that it might be sufficient to do pure NAT and not > NAPT, and it might be possible still to get some good standards around > how these devices should behave... both of which aren't happening for > the IPv4 Internet, unfortunately. > > Matthew Kaufman > From crosevear at skytap.com Wed Apr 28 16:38:18 2010 From: crosevear at skytap.com (Carl Rosevear) Date: Wed, 28 Apr 2010 14:38:18 -0700 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <20100429065912.2f478885@opy.nosense.org> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72D1E.60506@otd.com> <20100428230704.4119ebd3@opy.nosense.org> <4BD857E9.2010407@matthew.at> <20100429065912.2f478885@opy.nosense.org> Message-ID: I'm not normally one to respond to NANOG messages with opinions.... but... Yeah, NAT broke the internet. Yes you can engineer around it. There is NO reason to hold onto NAT as a standard. With v6 we have the opportunity to do it right (or at least semi-right) from the beginning, lets not choose to break it all from the beginning. Don't worry, if you understand basic routing these concepts shouldn't be hard for you. And don't worry, there is still plenty of market for residential "firewalls" and all but yeah maybe they'll actually have to be a firewall/router as opposed to just a NAT box. So there is my opinion; I don't understand why anyone thinks NAT should be a fundamental part of the v6 internet even after reading almost every message in this thread. It is just a stop-gap v4 measure and yeah, before people understood real security it was a security thing. Lets just move ahead with the good stuff! There'll be plenty of legacy/nostalgia around for years for those who still want to work with it. Just an opinion, Carl From drc at virtualized.org Wed Apr 28 16:54:04 2010 From: drc at virtualized.org (David Conrad) Date: Wed, 28 Apr 2010 14:54:04 -0700 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72D1E.60506@otd.com> <20100428230704.4119ebd3@opy.nosense.org> <4BD857E9.2010407@matthew.at> <20100429065912.2f478885@opy.nosense.org> Message-ID: <01F57362-8092-48CB-8336-15B9CC1713C2@virtualized.org> On Apr 28, 2010, at 2:38 PM, Carl Rosevear wrote: > I don't understand why anyone thinks NAT should be a fundamental part of the v6 internet Perhaps the ability to change service providers without having to renumber? Regards, -drc From felipe at starbyte.net Wed Apr 28 17:03:58 2010 From: felipe at starbyte.net (Felipe Zanchet Grazziotin) Date: Wed, 28 Apr 2010 19:03:58 -0300 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <01F57362-8092-48CB-8336-15B9CC1713C2@virtualized.org> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72D1E.60506@otd.com> <20100428230704.4119ebd3@opy.nosense.org> <4BD857E9.2010407@matthew.at> <20100429065912.2f478885@opy.nosense.org> <01F57362-8092-48CB-8336-15B9CC1713C2@virtualized.org> Message-ID: On Wed, Apr 28, 2010 at 6:54 PM, David Conrad wrote: > On Apr 28, 2010, at 2:38 PM, Carl Rosevear wrote: > > I don't understand why anyone thinks NAT should be a fundamental part of > the v6 internet > > Perhaps the ability to change service providers without having to renumber? > Couldn't we use link scope (or other local) addresses to local networks, and have gateways that do 1:1 translation between those addresses and PA space ? Call it NATv6, whatever. Nobody is going to remember addresses by hand, name servers (DNS or local scope as avahi) will be the rule. And DHCPv6 (or router advertisement) is how you provide your hosts access. Maybe internal servers, such as smbfs or NFS, could be only at link scope addresses? No need to renumerate, and full protection from outsiders. > > Regards, > -drc > > > Seriously, Felipe From dave.nanog at alfordmedia.com Wed Apr 28 17:04:25 2010 From: dave.nanog at alfordmedia.com (Dave Pooser) Date: Wed, 28 Apr 2010 17:04:25 -0500 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <20100429065912.2f478885@opy.nosense.org> Message-ID: > IPv6's fundamental goal is to restore end-to-end. For some. For many, IPv6's fundamental goal is to keep doing what we've been doing without running out of addresses. The fact that the two camps have orthogonal goals is probably part of the reason the rate of growth on IPv6 is so slow. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com From nenolod at systeminplace.net Wed Apr 28 17:06:57 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Wed, 28 Apr 2010 17:06:57 -0500 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <01F57362-8092-48CB-8336-15B9CC1713C2@virtualized.org> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72D1E.60506@otd.com> <20100428230704.4119ebd3@opy.nosense.org> <4BD857E9.2010407@matthew.at> <20100429065912.2f478885@opy.nosense.org> <01F57362-8092-48CB-8336-15B9CC1713C2@virtualized.org> Message-ID: <1272492417.29108.7.camel@petrie> On Wed, 2010-04-28 at 14:54 -0700, David Conrad wrote: > On Apr 28, 2010, at 2:38 PM, Carl Rosevear wrote: > > I don't understand why anyone thinks NAT should be a fundamental part of the v6 internet > > Perhaps the ability to change service providers without having to renumber? DHCPv6 solves that issue if implemented correctly in the CPE firewall/router appliance. William From marka at isc.org Wed Apr 28 17:07:15 2010 From: marka at isc.org (Mark Andrews) Date: Thu, 29 Apr 2010 08:07:15 +1000 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: Your message of "Wed, 28 Apr 2010 14:54:04 MST." <01F57362-8092-48CB-8336-15B9CC1713C2@virtualized.org> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72D1E.60506@otd.com> <20100428230704.4119ebd3@opy.nosense.org> <4BD857E9.2010407@matthew.at> <20100429065912.2f478885@opy.nosense.org> <01F57362-8092-48CB-8336-15B9CC1713C2@virtualized.org> Message-ID: <201004282207.o3SM7FGj058287@drugs.dv.isc.org> In message <01F57362-8092-48CB-8336-15B9CC1713C2 at virtualized.org>, David Conrad writes: > On Apr 28, 2010, at 2:38 PM, Carl Rosevear wrote: > > I don't understand why anyone thinks NAT should be a fundamental part = > of the v6 internet=20 > > Perhaps the ability to change service providers without having to = > renumber? We have that ability already. Doesn't require NAT. > Regards, > -drc -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From thegameiam at yahoo.com Wed Apr 28 17:16:54 2010 From: thegameiam at yahoo.com (David Barak) Date: Wed, 28 Apr 2010 15:16:54 -0700 (PDT) Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <20100429065912.2f478885@opy.nosense.org> Message-ID: <915400.38265.qm@web31809.mail.mud.yahoo.com> --- On Wed, 4/28/10, Mark Smith wrote: > > I'm not people are understanding or know the true reality. > NAT broke the > Internet's architecture, by turning IP from being a > peer-to-peer > protocol into a master/slave one (think mainframes and dumb > terminals). > Read RFC1958 if you don't understand what that means, > specifically the > 'end-to-end' principle part. IPv6's fundamental goal is to > restore > end-to-end. And this, in a few short sentences, is why IPv6 adoption has been so incredibly slow and frustrating. For some of us, IPv6's primary benefit is solving the "32 bits aren't enough" problem. For others, the commercial Internet architecture which evolved is aesthetically offensive, and they see IPv6 as the corrective mechanism. Only one of those two has any sort of time constraint (read: necessity), and it isn't the latter. The end-to-end principle is grand, I agree - but there are lots of commercial considerations which I find have a higher priority for my customers. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From drc at virtualized.org Wed Apr 28 17:31:32 2010 From: drc at virtualized.org (David Conrad) Date: Wed, 28 Apr 2010 15:31:32 -0700 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <201004282207.o3SM7FGj058287@drugs.dv.isc.org> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72D1E.60506@otd.com> <20100428230704.4119ebd3@opy.nosense.org> <4BD857E9.2010407@matthew.at> <20100429065912.2f478885@opy.nosense.org> <01F57362-8092-48CB-8336-15B9CC1713C2@virtualized.org> <201004282207.o3SM7FGj058287@drugs.dv.isc.org> Message-ID: Mark, On Apr 28, 2010, at 3:07 PM, Mark Andrews wrote: >> Perhaps the ability to change service providers without having to renumber? > > We have that ability already. Doesn't require NAT. Cool! You've figured out, e.g., how to renumber authoritative name servers that you don't have direct control over! And modify filter lists on a firewalls across an enterprise network! And remotely update provisioning systems and license managers without interrupting services! Etc., etc. http://www.rfc-editor.org/internet-drafts/draft-carpenter-renum-needs-work-05.txt A tiny home office network managed by a highly technical individual with full control over all aspects of the network is not a good model on which to base the definition of "we". Regards, -drc From william.mccall at gmail.com Wed Apr 28 17:50:30 2010 From: william.mccall at gmail.com (William McCall) Date: Wed, 28 Apr 2010 17:50:30 -0500 Subject: DDoS mitigation services from SPs In-Reply-To: References: Message-ID: Thank you all for the information. This has helped us get a move in the right direction with both our carriers and alternative services. --WM On Wed, Apr 28, 2010 at 9:09 AM, William McCall wrote: > All: > > I did some searching and have not found any concrete replies on the > list, but what carriers can offer L3 DDoS mitigation? Specifically, I > noticed an old UUnet offering, but it seems like I must be speaking > the wrong language to my sales drones. Specifically, we're dealing > with AT&T, Qwest and Verizon Business. My thought is that they all > offered some type of service like this, but my security folks have > been driving this and having limited success. > > Names of other SPs (we're looking at Verisign) is helpful, but we are > stuck with the Dallas area. > > Note: I am not interested in changing DNS records and prefixes should > be able to be advertised through BGP like normal. (Apparently, people > like to do funky DNS stuff to make this work and sometimes don't want > to do BGP in other scenarios.) > > Thanks in advance, > > -- > William McCall > From marka at isc.org Wed Apr 28 19:33:02 2010 From: marka at isc.org (Mark Andrews) Date: Thu, 29 Apr 2010 10:33:02 +1000 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: Your message of "Wed, 28 Apr 2010 15:31:32 MST." References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72D1E.60506@otd.com> <20100428230704.4119ebd3@opy.nosense.org> <4BD857E9.2010407@matthew.at> <20100429065912.2f478885@opy.nosense.org> <01F57362-8092-48CB-8336-15B9CC1713C2@virtualized.org> <201004282207.o3SM7FGj058287@drugs.dv.isc.org> Message-ID: <201004290033.o3T0X2Vq060519@drugs.dv.isc.org> In message , David Conrad writes: > Mark, > > On Apr 28, 2010, at 3:07 PM, Mark Andrews wrote: > >> Perhaps the ability to change service providers without having to = > renumber? > >=20 > > We have that ability already. Doesn't require NAT. > > Cool! You've figured out, e.g., how to renumber authoritative name = > servers that you don't have direct control over! Don't do that. It was a deliberate design decision to use names rather than IP addesses in NS records. This allows the operators of the nameservers to change their addresses when they need to. B.T.W. we have the technology to automatically update delegations if we need to and have for the last 10 years. People just need to stop being scared about doing it. > And modify filter = > lists on a firewalls across an enterprise network! And remotely update = > provisioning systems and license managers without interrupting services! = > Etc., etc. > > http://www.rfc-editor.org/internet-drafts/draft-carpenter-renum-needs-work= > -05.txt > > A tiny home office network managed by a highly technical individual with = > full control over all aspects of the network is not a good model on = > which to base the definition of "we". > > Regards, > -drc Well if you insist on using IP addresses rather than real crypto for access control. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Wed Apr 28 19:56:03 2010 From: marka at isc.org (Mark Andrews) Date: Thu, 29 Apr 2010 10:56:03 +1000 Subject: Anyone from UUNET.CA around. Message-ID: <201004290056.o3T0u3CI060983@drugs.dv.isc.org> ------- Forwarded Message Return-Path: MAILER-DAEMON Delivery-Date: Thu Apr 29 10:51:31 2010 Return-Path: <> Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o3T0pUQJ060935 for ; Thu, 29 Apr 2010 10:51:30 +1000 (EST) X-Original-To: marka at isc.org Delivered-To: marka at farside.isc.org Received: from farside.isc.org [2001:4f8:3:bb::5] by drugs.dv.isc.org with IMAP (fetchmail-6.3.14) for (single-drop); Thu, 29 Apr 2010 10:51:30 +1000 (EST) Received: by farside.isc.org (Postfix) id 8AE29E9E84; Thu, 29 Apr 2010 00:51:19 +0000 (UTC) Date: Thu, 29 Apr 2010 00:51:19 +0000 (UTC) From: MAILER-DAEMON at isc.org (Mail Delivery System) Subject: Undelivered Mail Returned to Sender To: marka at isc.org MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="08BABE9E6F.1272502279/farside.isc.org" Message-Id: <20100429005119.8AE29E9E84 at farside.isc.org> This is a MIME-encapsulated message. - --08BABE9E6F.1272502279/farside.isc.org Content-Description: Notification Content-Type: text/plain This is the Postfix program at host farside.isc.org. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the attached returned message. The Postfix program : host firewall.verizonbusiness.com[199.249.25.205] said: 530 5.7.1 This system is not an open relay.: noc at uunet.ca (in reply to RCPT TO command) - --08BABE9E6F.1272502279/farside.isc.org Content-Description: Delivery report Content-Type: message/delivery-status Reporting-MTA: dns; farside.isc.org X-Postfix-Queue-ID: 08BABE9E6F X-Postfix-Sender: rfc822; marka at isc.org Arrival-Date: Thu, 29 Apr 2010 00:50:56 +0000 (UTC) Final-Recipient: rfc822; noc at uunet.ca Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; host firewall.verizonbusiness.com[199.249.25.205] said: 530 5.7.1 This system is not an open relay.: noc at uunet.ca (in reply to RCPT TO command) - --08BABE9E6F.1272502279/farside.isc.org Content-Description: Undelivered Message Content-Type: message/rfc822 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 08BABE9E6F for ; Thu, 29 Apr 2010 00:50:56 +0000 (UTC) (envelope-from marka at isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o3T0osXA060891 for ; Thu, 29 Apr 2010 10:50:54 +1000 (EST) (envelope-from marka at drugs.dv.isc.org) Message-Id: <201004290050.o3T0osXA060891 at drugs.dv.isc.org> To: noc at uunet.ca From: Mark Andrews Subject: It shouldn't be this hard .... Date: Thu, 29 Apr 2010 10:50:54 +1000 Sender: marka at isc.org Can't get to www.uunet.ca connection times out. Non-working address in SOA contact field. - ------- Forwarded Message Return-Path: MAILER-DAEMON Delivery-Date: Thu Apr 29 10:42:06 2010 Return-Path: <> Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o3T0g6Gm060782 for ; Thu, 29 Apr 2010 10:42:06 +1000 (EST) X-Original-To: marka at isc.org Delivered-To: marka at farside.isc.org Received: from farside.isc.org [2001:4f8:3:bb::5] by drugs.dv.isc.org with IMAP (fetchmail-6.3.14) for (single-drop); Thu, 29 Apr 2010 10:42:06 +1000 (EST) Received: by farside.isc.org (Postfix) id 76501E9E81; Thu, 29 Apr 2010 00:38:43 +0000 (UTC) Date: Thu, 29 Apr 2010 00:38:43 +0000 (UTC) From: MAILER-DAEMON at isc.org (Mail Delivery System) Subject: Undelivered Mail Returned to Sender To: marka at isc.org MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="94D16E9E7E.1272501523/farside.isc.org" Message-Id: <20100429003843.76501E9E81 at farside.isc.org> This is a MIME-encapsulated message. - - --94D16E9E7E.1272501523/farside.isc.org Content-Description: Notification Content-Type: text/plain This is the Postfix program at host farside.isc.org. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the attached returned message. The Postfix program : host firewall.verizonbusiness.com[199.249.25.205] said: 550 5.1.1 Address Not Valid: support at ca.mci.com (in reply to RCPT TO command) - - --94D16E9E7E.1272501523/farside.isc.org Content-Description: Delivery report Content-Type: message/delivery-status Reporting-MTA: dns; farside.isc.org X-Postfix-Queue-ID: 94D16E9E7E X-Postfix-Sender: rfc822; marka at isc.org Arrival-Date: Thu, 29 Apr 2010 00:38:40 +0000 (UTC) Final-Recipient: rfc822; support at ca.mci.com Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; host firewall.verizonbusiness.com[199.249.25.205] said: 550 5.1.1 Address Not Valid: support at ca.mci.com (in reply to RCPT TO command) - - --94D16E9E7E.1272501523/farside.isc.org Content-Description: Undelivered Message Content-Type: message/rfc822 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 94D16E9E7E for ; Thu, 29 Apr 2010 00:38:40 +0000 (UTC) (envelope-from marka at isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o3T0cZ78060588 for ; Thu, 29 Apr 2010 10:38:38 +1000 (EST) (envelope-from marka at drugs.dv.isc.org) Message-Id: <201004290038.o3T0cZ78060588 at drugs.dv.isc.org> Date: Thu, 29 Apr 2010 10:38:35 +1000 From: Mark Andrews Subject: Re: Query - No Response To: undisclosed-recipients:; - - ------- Blind-Carbon-Copy To: "ic.nssip" Cc: bind-users at lists.isc.org From: Mark Andrews References: <7097328FE40440F2BF8419D9B6967693 at internal.corp.ds> Subject: Re: Query - No Response In-reply-to: Your message of "Wed, 28 Apr 2010 16:59:21 CST." <7097328FE40440F2BF8419D9B6967693 at internal.corp.ds> Date: Thu, 29 Apr 2010 10:38:35 +1000 Sender: marka at drugs.dv.isc.org In message <7097328FE40440F2BF8419D9B6967693 at internal.corp.ds>, "ic.nssip" writ es: > Hello everyone, > > I have a strange issue on a DNS server that is not able to resolve = > www.cancer.ca [65.110.160.32]. > If somebody has an idea about what is going wrong there, I will really = > appreciate any suggestions on how to make it work. > > Here is my dig and dig +trace test on that server: > > U:\>dig @ns.domain.net www.cancer.ca > > ; <<>> DiG 9.7.0a1 <<>> @ns.domain.net www.cancer.ca > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 154 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.cancer.ca. IN A > > ;; Query time: 171 msec > ;; SERVER: ns.domain.net#53(IP address) > ;; WHEN: Wed Apr 28 15:47:09 2010 > ;; MSG SIZE rcvd: 31 > > > U:\>dig @ns.domain.net www.cancer.ca +trace > > ; <<>> DiG 9.7.0a1 <<>> @ns.domain.net www.cancer.ca +trace > ; (1 server found) > ;; global options: +cmd > . 35864 IN NS l.root-servers.net. > . 35864 IN NS e.root-servers.net. > . 35864 IN NS m.root-servers.net. > . 35864 IN NS j.root-servers.net. > . 35864 IN NS c.root-servers.net. > . 35864 IN NS a.root-servers.net. > . 35864 IN NS k.root-servers.net. > . 35864 IN NS i.root-servers.net. > . 35864 IN NS b.root-servers.net. > . 35864 IN NS f.root-servers.net. > . 35864 IN NS d.root-servers.net. > . 35864 IN NS g.root-servers.net. > . 35864 IN NS h.root-servers.net. > ;; Received 272 bytes from ns.domain.net#53(IP address) in 15 ms > > ca. 172800 IN NS sns-pb.isc.org. > ca. 172800 IN NS l.ca-servers.ca. > ca. 172800 IN NS k.ca-servers.ca. > ca. 172800 IN NS j.ca-servers.ca. > ca. 172800 IN NS b.ca-servers.ca. > ca. 172800 IN NS m.ca-servers.ca. > ca. 172800 IN NS c.ca-servers.ca. > ca. 172800 IN NS f.ca-servers.ca. > ca. 172800 IN NS a.ca-servers.ca. > ca. 172800 IN NS e.ca-servers.ca. > ca. 172800 IN NS d.ca-servers.ca. > ;; Received 462 bytes from 128.8.10.90#53(d.root-servers.net) in 109 ms > > cancer.ca. 86400 IN NS ns2.uunet.ca. > cancer.ca. 86400 IN NS ns.uunet.ca. > ;; Received 104 bytes from 192.228.25.45#53(b.ca-servers.ca) in 281 ms > > www.cancer.ca. 86400 IN A 65.110.160.32 > ;; Received 47 bytes from 142.77.1.1#53(ns.uunet.ca) in 156 ms > > Thank you, > Julian The servers are not authoritative for the zone. Named rejects non-authoritative answers. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4055 ;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.cancer.ca. IN A ;; ANSWER SECTION: www.cancer.ca. 86400 IN A 65.110.160.32 ;; Query time: 792 msec ;; SERVER: 142.77.1.1#53(ns.uunet.ca) ;; WHEN: Thu Apr 29 10:34:28 2010 ;; MSG SIZE rcvd: 47 Mark - - - -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org - - ------- End of Blind-Carbon-Copy - - --94D16E9E7E.1272501523/farside.isc.org-- - ------- End of Forwarded Message - --08BABE9E6F.1272502279/farside.isc.org-- ------- End of Forwarded Message From ssrigha at gmail.com Wed Apr 28 22:23:27 2010 From: ssrigha at gmail.com (shake righa) Date: Thu, 29 Apr 2010 06:23:27 +0300 Subject: SMW4 Routing Implications Message-ID: What have been the routing implications in regards to internet traffic with SMW4 cable beign down? Regards, Shake Righa From ge at linuxbox.org Wed Apr 28 22:50:57 2010 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 29 Apr 2010 06:50:57 +0300 Subject: [only half OT] A socio-psychological analysis of the first internet war (Estonia) Message-ID: <4BD90221.5010800@linuxbox.org> Hi, In the past year I have been working in collaboration with psychologists Robert Cialdini and Rosanna Guadagno on a paper analyzing some of what I saw from the social perspective in Estonia, when I wrote the post-mortem analysis for the 2007 attacks, but didn't understand at the time. Aside to botnets and and flood-based attacks, many of the attacks were "live mobs", or an "online riot" if you like, where individuals simply sent pings toward Estonian addresses. While it doesn't seem like pings would cause so much damage -- en masse they certainly did. Then of course, there is also the psychological aspect... ... When everyone and their grandmother attacked with pings, spammers, professionals and others who know what they are doing then got involved, attacking using more sophisticated tools. We analyze how the Russian-speaking population online was manipulated to attack Estonia (and Georgia) in the "cyber war" incidents, and how it could happen again (regardless of if any actor is behind it). The psychological aspect of this is indeed off-topic to NANOG, but the attack is analogous to network peak usages with user interest in high-bandwidth content, and how large networks prepare for such peaks. This is about the DDoS attacks, and how a human DDoS has been and can be initiated again. It also under-scores the power of individual activism on the internet, and how it can also be abused. I hope some here would find the research useful for their own interest, if nothing else. Otherwise, sorry for wasting your bandwidth and thanks for your time. Article on El Reg: http://www.theregister.co.uk/2010/04/28/web_war_one_anonymity/ Paper (for download with pay :( ): http://www.liebertonline.com/doi/abs/10.1089/cyber.2009.0134 Thanks, and any comments appreciated. If on psychology, please do it off-list, though. Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From Valdis.Kletnieks at vt.edu Wed Apr 28 23:36:24 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 29 Apr 2010 00:36:24 -0400 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: Your message of "Wed, 28 Apr 2010 14:54:04 PDT." <01F57362-8092-48CB-8336-15B9CC1713C2@virtualized.org> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72D1E.60506@otd.com> <20100428230704.4119ebd3@opy.nosense.org> <4BD857E9.2010407@matthew.at> <20100429065912.2f478885@opy.nosense.org> <01F57362-8092-48CB-8336-15B9CC1713C2@virtualized.org> Message-ID: <15038.1272515784@localhost> On Wed, 28 Apr 2010 14:54:04 PDT, David Conrad said: > On Apr 28, 2010, at 2:38 PM, Carl Rosevear wrote: > > I don't understand why anyone thinks NAT should be a fundamental part > > of the v6 internet > > Perhaps the ability to change service providers without having to renumber? RFC4193 or PI address space, depending what problem you're trying to solve by not renumbering. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From lars.eggert at nokia.com Thu Apr 29 04:35:08 2010 From: lars.eggert at nokia.com (Lars Eggert) Date: Thu, 29 Apr 2010 12:35:08 +0300 Subject: wanted: your old NAT home router Message-ID: <3CB1CD73-4A8D-480C-B41C-03EDC19FB642@nokia.com> Hi, for a measurement study done together with Markku Kojo's team at the University of Helsinki, we're looking to collect as many different NAT home routers as possible. If you have an old clunker lying around somewhere, please contact me off-list. I'll cover shipping via DHL. Feel free to forward this email as you see fit. The boxes will find a permanent home at the University of Helsinki. Study results will be published openly. The intent is that this collection become a resource for the community to be shared for future studies. Caveat: The boxes should NAT between Ethernet interfaces - we don't have DSL or cable access equipment in the lab setup at the moment. Thanks, Lars -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2490 bytes Desc: not available URL: From randy at psg.com Thu Apr 29 05:31:59 2010 From: randy at psg.com (Randy Bush) Date: Thu, 29 Apr 2010 03:31:59 -0700 Subject: SMW4 Routing Implications In-Reply-To: References: Message-ID: > What have been the routing implications in regards to internet traffic > with SMW4 cable beign down? though i am sure there are experts who will answer, that question is not formally answerable as o if you are strictly talking about routing, then we have a problem of visibility. i.e. the edge paths do not show up in monitors. o if you are talking about traffic, then looking at routing only gives a small clue and very very far from a rigorous answer. randy From regnauld at nsrc.org Thu Apr 29 05:49:20 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 29 Apr 2010 12:49:20 +0200 Subject: wanted: your old NAT home router In-Reply-To: <3CB1CD73-4A8D-480C-B41C-03EDC19FB642@nokia.com> References: <3CB1CD73-4A8D-480C-B41C-03EDC19FB642@nokia.com> Message-ID: <20100429104920.GB44670@macbook.catpipe.net> Lars Eggert (lars.eggert) writes: > Hi, > > for a measurement study done together with Markku Kojo's team at the University of Helsinki, we're looking to collect as many different NAT home routers as possible. If you have an old clunker lying around somewhere, please contact me off-list. I'll cover shipping via DHL. Feel free to forward this email as you see fit. > > The boxes will find a permanent home at the University of Helsinki. Study results will be published openly. The intent is that this collection become a resource for the community to be shared for future studies. > > Caveat: The boxes should NAT between Ethernet interfaces - we don't have DSL or cable access equipment in the lab setup at the moment. What about getting someone to donate an old DSLAM ? Wouldn't that help ? Phil From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Apr 29 06:08:23 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 29 Apr 2010 20:38:23 +0930 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <201004290033.o3T0X2Vq060519@drugs.dv.isc.org> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72D1E.60506@otd.com> <20100428230704.4119ebd3@opy.nosense.org> <4BD857E9.2010407@matthew.at> <20100429065912.2f478885@opy.nosense.org> <01F57362-8092-48CB-8336-15B9CC1713C2@virtualized.org> <201004282207.o3SM7FGj058287@drugs.dv.isc.org> <201004290033.o3T0X2Vq060519@drugs.dv.isc.org> Message-ID: <20100429203823.6645a731@opy.nosense.org> On Thu, 29 Apr 2010 10:33:02 +1000 Mark Andrews wrote: > > In message , David Conrad > writes: > > Mark, > > > > On Apr 28, 2010, at 3:07 PM, Mark Andrews wrote: > > >> Perhaps the ability to change service providers without having to = > > renumber? > > >=20 > > > We have that ability already. Doesn't require NAT. > > > > Cool! You've figured out, e.g., how to renumber authoritative name = > > servers that you don't have direct control over! > > Don't do that. It was a deliberate design decision to use names > rather than IP addesses in NS records. This allows the operators > of the nameservers to change their addresses when they need to. > > B.T.W. we have the technology to automatically update delegations > if we need to and have for the last 10 years. People just need to > stop being scared about doing it. > > > And modify filter = > > lists on a firewalls across an enterprise network! And remotely update = > > provisioning systems and license managers without interrupting services! = > > Etc., etc. > > > > http://www.rfc-editor.org/internet-drafts/draft-carpenter-renum-needs-work= > > -05.txt > > > > A tiny home office network managed by a highly technical individual with = > > full control over all aspects of the network is not a good model on = > > which to base the definition of "we". > > > > Regards, > > -drc > > Well if you insist on using IP addresses rather than real crypto for access > control. > I suppose it'll protect us when Skynet emerges. I think the current security threat is the people behind the machines, not the machines themselves and their IP addresses. Regards, Mark. From lars.eggert at nokia.com Thu Apr 29 06:01:49 2010 From: lars.eggert at nokia.com (Lars Eggert) Date: Thu, 29 Apr 2010 14:01:49 +0300 Subject: wanted: your old NAT home router In-Reply-To: <20100429104920.GB44670@macbook.catpipe.net> References: <3CB1CD73-4A8D-480C-B41C-03EDC19FB642@nokia.com> <20100429104920.GB44670@macbook.catpipe.net> Message-ID: <3D0A48C9-B597-4014-B986-6A70C9CC96EF@nokia.com> Hi, On 2010-4-29, at 13:49, Phil Regnauld wrote: > What about getting someone to donate an old DSLAM ? Wouldn't that help ? it certainly would, in the longer term. I've also been pointed at "mini-DSLAMs" that are reasonably cheap. (We're planning to have a first draft study ready mid-May, and for that, the best we can do is add more Ethernet-Ethernet NATs to the testbed.) Lars -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2490 bytes Desc: not available URL: From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Apr 29 06:19:29 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 29 Apr 2010 20:49:29 +0930 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100429065912.2f478885@opy.nosense.org> Message-ID: <20100429204929.185dbf75@opy.nosense.org> On Wed, 28 Apr 2010 17:04:25 -0500 Dave Pooser wrote: > > IPv6's fundamental goal is to restore end-to-end. > > For some. For many, IPv6's fundamental goal is to keep doing what we've been > doing without running out of addresses. The fact that the two camps have > orthogonal goals is probably part of the reason the rate of growth on IPv6 > is so slow. Well they should realise that end-to-end is what made the Internet the success in the first place. On the Original Internet, when you had an IP address, one moment you could be a client, another you could be a server, or another you could be a peer - or you could be any or all three roles at the same time. What role you wanted to play was completely and absolutely up to you - no third parties to ask permission of, no router upgrades involved. You just started the (client/server/peer-to-peer) software, and off you went. The applications exist at the edge of the Internet - in the software operating on the end-nodes. The Internet itself is supposed to be a dumb, best effort packet transport between the edges - nothing more. That is why the Original Internet was good at running any application you threw at it, including new ones - because it never cared what those applications were. It just tried to do it's job of getting packets from edge sources to edge destinations, regardless of what was in them. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Apr 29 06:26:57 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 29 Apr 2010 20:56:57 +0930 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <4BD5A72C.301@jsbc.cc> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> <4BD4DFB9.5070105@dougbarton.us> <4BD5A72C.301@jsbc.cc> Message-ID: <20100429205657.2fd96085@opy.nosense.org> On Mon, 26 Apr 2010 07:46:04 -0700 Jim Burwell wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 4/26/2010 03:36, Mikael Abrahamsson wrote: > > On Sun, 25 Apr 2010, Owen DeLong wrote: > > > >> I fail to see how link local is any more difficult than any > >> other IPv6 address. > > > > They're different because you have to know your local network > > interface name as well. > > > >> Windows might get interesting as windows interface naming is, > >> uh, creative at best. > > > > Exactly. > > > Installation software could make this easy. It could either prompt > the user to type in the address on a sticker then enumerate all > interfaces on the system and attempt to contact the router on each NIC. > > Another possibility is that it could enumerate all the interfaces, > then use the IPv6 link-local scope all routers multicast (ff02::2) to > enumerate a list of routers found on each link, sort them and/or > filter them by ethernet OUI, and present a list of choices for the > user to click on to configure the router. The user could also easily > match the enet address on a little slip of paper or sticker on the > router to this list, or through some initial settings on the router > which allow info to be pulled from it somehow, present a list of > unconfigured routers, etc, etc. > > Point is, I can imagine a lot of ways this could be made user-proof > via software/firmware combination that requires no advanced networking > knowledge. > It's called multicast DNS. It's easier for that to deal just with vanilla IPv6 addresses (i.e. via application calls to getaddrinfo()), rather than IPv6 LL addrs + interface names. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkvVpywACgkQ2fXFxl4S7sSCuwCg07Gwxz6NDYuTkVYr5gP5LUMC > n4EAoIdqZQ7C/01X0EcV3vnZiTD4b7Vc > =hDQN > -----END PGP SIGNATURE----- > > > From john-nanog at johnpeach.com Thu Apr 29 07:25:25 2010 From: john-nanog at johnpeach.com (John Peach) Date: Thu, 29 Apr 2010 08:25:25 -0400 Subject: Anyone from UUNET.CA around. In-Reply-To: <201004290056.o3T0u3CI060983@drugs.dv.isc.org> References: <201004290056.o3T0u3CI060983@drugs.dv.isc.org> Message-ID: <20100429082525.18a903e3@godzilla> On Thu, 29 Apr 2010 10:56:03 +1000 Mark Andrews wrote: > > ------- Forwarded Message [snip] > > : host firewall.verizonbusiness.com[199.249.25.205] said: 530 > 5.7.1 This system is not an open relay.: noc at uunet.ca (in reply to RCPT TO > command) I sent verizonbusiness a complaint about spam yesterday and they were so clueful that they forwarded it to the abuse address where I sent the complaint from, rather the the origin of the spam. Not only did they screw that up, but nothing was redacted, making it a worthless complaint even if they had managed to read the headers. [snip] From j.varaillon at cosmoline.com Thu Apr 29 08:58:39 2010 From: j.varaillon at cosmoline.com (Varaillon Jean Christophe) Date: Thu, 29 Apr 2010 16:58:39 +0300 Subject: Starting up a WiMAX ISP In-Reply-To: <201004281228.43833.a.harrowell@gmail.com> References: <20100428014123.91390.qmail@joyce.lan> <4BD793BD.5050906@spectraaccess.com> <201004281228.43833.a.harrowell@gmail.com> Message-ID: <000701cae7a4$12db1180$38913480$%varaillon@cosmoline.com> Hi, Based on what the markets currently offers and what your potential customers need, you can figure out the packages that you could to sell (Internet, voip, vpn, guaranteed bandwidth...). This would give you the resources that should be considered per customer. It would also give you a hint to select the CPE (wifi, POTS, firewall...) Then, it is necessary to locate, physically the area with the greatest potential of getting customers. This would give an idea of where should the base stations be located, how many customers would be aggregated at one Base Station (having in mind how many customers will be connected concurrently) and how much downlink traffic is to be expected. In case you go for a model where the ASN-GW is centralized, all the traffic has to go from each base station to the ASN-GW. The backhauling could be done using Ethernet RF point-to-point link, re-using the mast where the Wimax antenna is. The ASN site, aggregates all the backhaul links into a switch, which then connects to the ASN-GW (BRAS like). This is where the AAA, (DHCP), DNS, NTP, NMS/EMS are also located. In my opinion, the critical point really resides on the radio part (license, authorization, legal complains, interferences...). Jean-Christophe VARAILLON -----Original Message----- From: Alexander Harrowell [mailto:a.harrowell at gmail.com] Sent: Wednesday, April 28, 2010 2:29 PM To: nanog at nanog.org Subject: Re: Starting up a WiMAX ISP On Wednesday 28 April 2010 03:13:24 John R. Levine wrote: > > Of course what they offer over those "long long rural runs" and what > > they can > > actually provide are two different things. DSL performance > > decreases with distance rather dramatically.. > > That's what I thought, but my friend out on the sheep farm in the next > county says he gets 3Mb just like I do in the village three blocks > from the CO. (Yes, he knows what he's talking about.) They must > spend a lot on repeaters and concentrators. > > R's, > John > > There is a great deal of relevant experience here: http://www.wirelesscowboys.com/ -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them From msmith at internap.com Thu Apr 29 10:04:36 2010 From: msmith at internap.com (Michael Smith) Date: Thu, 29 Apr 2010 11:04:36 -0400 Subject: [only half OT] A socio-psychological analysis of the first internetwar (Estonia) In-Reply-To: <4BD90221.5010800@linuxbox.org> References: <4BD90221.5010800@linuxbox.org> Message-ID: <65C5927BEED3C2428307863DB5C6C6FB03EB04B4@cx49.800onemail.com> No GPL for the full paper, huh? Back to the cathedral.... What's the toll in case I can get some buddies to pitch-in to buy access to the full content? -----Original Message----- From: Gadi Evron [mailto:ge at linuxbox.org] Sent: Wednesday, April 28, 2010 11:51 PM To: NANOG Subject: [only half OT] A socio-psychological analysis of the first internetwar (Estonia) Hi, In the past year I have been working in collaboration with psychologists Robert Cialdini and Rosanna Guadagno on a paper analyzing some of what I saw from the social perspective in Estonia, when I wrote the post-mortem analysis for the 2007 attacks, but didn't understand at the time. Aside to botnets and and flood-based attacks, many of the attacks were "live mobs", or an "online riot" if you like, where individuals simply sent pings toward Estonian addresses. While it doesn't seem like pings would cause so much damage -- en masse they certainly did. Then of course, there is also the psychological aspect... ... When everyone and their grandmother attacked with pings, spammers, professionals and others who know what they are doing then got involved, attacking using more sophisticated tools. We analyze how the Russian-speaking population online was manipulated to attack Estonia (and Georgia) in the "cyber war" incidents, and how it could happen again (regardless of if any actor is behind it). The psychological aspect of this is indeed off-topic to NANOG, but the attack is analogous to network peak usages with user interest in high-bandwidth content, and how large networks prepare for such peaks. This is about the DDoS attacks, and how a human DDoS has been and can be initiated again. It also under-scores the power of individual activism on the internet, and how it can also be abused. I hope some here would find the research useful for their own interest, if nothing else. Otherwise, sorry for wasting your bandwidth and thanks for your time. Article on El Reg: http://www.theregister.co.uk/2010/04/28/web_war_one_anonymity/ Paper (for download with pay :( ): http://www.liebertonline.com/doi/abs/10.1089/cyber.2009.0134 Thanks, and any comments appreciated. If on psychology, please do it off-list, though. Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From nonobvious at gmail.com Thu Apr 29 10:22:47 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Thu, 29 Apr 2010 08:22:47 -0700 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <6109E1B3-E845-4111-966A-0613338D6719@delong.com> References: <20100420145332.58995.qmail@joyce.lan> <20100427173622.GA24745@chilli.nosignal.org> <4BD72386.6010303@matthew.at> <19110.1272392139@localhost> <20861.1272394046@localhost> <26157.1272400265@localhost> <6109E1B3-E845-4111-966A-0613338D6719@delong.com> Message-ID: On Tue, Apr 27, 2010 at 3:24 PM, Owen DeLong wrote: >> Here's an exercise. ?Wipe a PC. ?Put it on that cable modem with no firewall. ?Install XP on it. ?See if you can get any service packs installed before the box is infected. > 1. ? ? ?Yes, I can. ?I simply didn't put an IPv4 address on it. ;-) > 2. ? ? ?I wouldn't hold XP up as the gold standard of hosts here. One of my coworkers was IPv6ing his home network. He had to turn off the Windows firewall on the machine with the IPv6 tunnel for a couple of minutes to install some stubborn software. Then he had to reimage the box because it was pwned, and he's pretty sure that the infection came in over the IPv6 tunnel, not the hardware-firewalled IPv4. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From paul at telcodata.us Thu Apr 29 10:29:43 2010 From: paul at telcodata.us (Paul Timmins) Date: Thu, 29 Apr 2010 11:29:43 -0400 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <01F57362-8092-48CB-8336-15B9CC1713C2@virtualized.org> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72D1E.60506@otd.com> <20100428230704.4119ebd3@opy.nosense.org> <4BD857E9.2010407@matthew.at> <20100429065912.2f478885@opy.nosense.org> <01F57362-8092-48CB-8336-15B9CC1713C2@virtualized.org> Message-ID: <4BD9A5E7.1090904@telcodata.us> David Conrad wrote: > On Apr 28, 2010, at 2:38 PM, Carl Rosevear wrote: > >> I don't understand why anyone thinks NAT should be a fundamental part of the v6 internet >> > > Perhaps the ability to change service providers without having to renumber? Number your internal network on ULA, and put public addresses on your machines as well. RFC3484 support in your OS will cause your machine to use ULA to talk to other ULA interfaces, and the public IP to the rest of the internet. If you change ISPs, send out an RA with the new addresses, wait a bit, then send out an RA with lifetime 0 on the old address. All the machines should drop their old ISP's IP, and start using the new ISP, as well as continue using ULA like nothing's changed for the internal file sharing/printing/whatever From owen at delong.com Thu Apr 29 10:29:53 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 29 Apr 2010 08:29:53 -0700 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <20100429205657.2fd96085@opy.nosense.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD45D01.8060501@hoyle.me.uk> <32096853-5736-40E5-8A8C-14684DA08E30@delong.com> <20100426082033.335e28da@opy.nosense.org> <4BD4DFB9.5070105@dougbarton.us> <4BD5A72C.301@jsbc.cc> <20100429205657.2fd96085@opy.nosense.org> Message-ID: On Apr 29, 2010, at 4:26 AM, Mark Smith wrote: > On Mon, 26 Apr 2010 07:46:04 -0700 > Jim Burwell wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 4/26/2010 03:36, Mikael Abrahamsson wrote: >>> On Sun, 25 Apr 2010, Owen DeLong wrote: >>> >>>> I fail to see how link local is any more difficult than any >>>> other IPv6 address. >>> >>> They're different because you have to know your local network >>> interface name as well. >>> >>>> Windows might get interesting as windows interface naming is, >>>> uh, creative at best. >>> >>> Exactly. >>> >> Installation software could make this easy. It could either prompt >> the user to type in the address on a sticker then enumerate all >> interfaces on the system and attempt to contact the router on each NIC. >> >> Another possibility is that it could enumerate all the interfaces, >> then use the IPv6 link-local scope all routers multicast (ff02::2) to >> enumerate a list of routers found on each link, sort them and/or >> filter them by ethernet OUI, and present a list of choices for the >> user to click on to configure the router. The user could also easily >> match the enet address on a little slip of paper or sticker on the >> router to this list, or through some initial settings on the router >> which allow info to be pulled from it somehow, present a list of >> unconfigured routers, etc, etc. >> >> Point is, I can imagine a lot of ways this could be made user-proof >> via software/firmware combination that requires no advanced networking >> knowledge. >> > > It's called multicast DNS. It's easier for that to deal just with > vanilla IPv6 addresses (i.e. via application calls to getaddrinfo()), > rather than IPv6 LL addrs + interface names. > Actually, mDNS will handle IPv6 LL just fine. The interface name is automatically provided along with the scope in the return values from getaddrinfo(): struct addrinfo { int ai_flags; /* input flags */ int ai_family; /* protocol family for socket */ int ai_socktype; /* socket type */ int ai_protocol; /* protocol for socket */ socklen_t ai_addrlen; /* length of socket-address */ struct sockaddr *ai_addr; /* socket-address for socket */ char *ai_canonname; /* canonical name for service location */ struct addrinfo *ai_next; /* pointer to next in list */ }; struct sockaddr is an abstraction to an address-family specific structure. The IPv6 structure (sockaddr_in6) is as follows: struct sockaddr_in6 { __uint8_t sin6_len; /* length of this struct(sa_family_t)*/ sa_family_t sin6_family; /* AF_INET6 (sa_family_t) */ in_port_t sin6_port; /* Transport layer port # (in_port_t)*/ __uint32_t sin6_flowinfo; /* IP6 flow information */ struct in6_addr sin6_addr; /* IP6 address */ __uint32_t sin6_scope_id; /* scope zone index */ }; Note that the sockaddr_in6 structure will contain an in6_addr structure and a sin6_scope_id (which specifies the scope of the address and should, according to RFC 4007 contain enough information to identify the zone (interface) as well). Thus you should be able to pass the return value of getaddrinfo() with an mDNS result containing a link local address to connect() and expect it to work just fine. Owen From nonobvious at gmail.com Thu Apr 29 10:45:06 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Thu, 29 Apr 2010 08:45:06 -0700 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: <4BD5A12E.50907@sprunk.org> References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD5A12E.50907@sprunk.org> Message-ID: On Mon, Apr 26, 2010 at 7:20 AM, Stephen Sprunk wrote: > The vast majority of residential customers have a single subnet, so they > can get by just fine using IPv6 link-local addresses. ?The vanishingly > small percentage that have multiple subnets are presumably savvy enough > to set up ULA-R addresses. ?There is no need for ULA-C in this scenario. Actually it's pretty common for residential customers to have multiple subnets, one wired and one wireless, even if they're both NAT'd to 192.168.x.x. They may may or not be doing anything with the wired subnet, and their wireless router may also be providing a wired subnet bridged with the wireless, and it's all happening in little consumer-appliance boxes that work by magic, but it's out there. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From William.Murphy at uth.tmc.edu Thu Apr 29 10:53:01 2010 From: William.Murphy at uth.tmc.edu (Murphy, William) Date: Thu, 29 Apr 2010 10:53:01 -0500 Subject: Edu versus Speakeasy Speedtest Message-ID: I work for an Edu with multi-gigabit Internet connectivity and I get questions from users saying "Why am I only getting 14Mb when I run this speed test?" I have got to believe that the various Internet speed tests (Speakeasy or dslreports) are rate limited to prevent someone from shutting them down. I am able to get 300-400Mb running from a PC inside my network to NDT servers located on Internet2, so that tells me my border and internal network is healthy. Can someone on this list shed some light regarding reliability and accuracy of these various speed tests especially for an Edu with lots'o bandwidth? Thanks. Bill Murphy University of Texas Health Science Center - Houston -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4408 bytes Desc: not available URL: From robertg at garlic.com Thu Apr 29 10:56:01 2010 From: robertg at garlic.com (Robert Glover) Date: Thu, 29 Apr 2010 15:56:01 +0000 Subject: Edu versus Speakeasy Speedtest In-Reply-To: References: Message-ID: <1224652054-1272556568-cardhu_decombobulator_blackberry.rim.net-838544338-@bda452.bisx.prod.on.blackberry> Adjust your TCP window size. -----Original Message----- From: "Murphy, William" Date: Thu, 29 Apr 2010 10:53:01 To: nanog at nanog.org Subject: Edu versus Speakeasy Speedtest I work for an Edu with multi-gigabit Internet connectivity and I get questions from users saying "Why am I only getting 14Mb when I run this speed test?" I have got to believe that the various Internet speed tests (Speakeasy or dslreports) are rate limited to prevent someone from shutting them down. I am able to get 300-400Mb running from a PC inside my network to NDT servers located on Internet2, so that tells me my border and internal network is healthy. Can someone on this list shed some light regarding reliability and accuracy of these various speed tests especially for an Edu with lots'o bandwidth? Thanks. Bill Murphy University of Texas Health Science Center - Houston From bclark at spectraaccess.com Thu Apr 29 11:04:58 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Thu, 29 Apr 2010 12:04:58 -0400 Subject: Edu versus Speakeasy Speedtest In-Reply-To: <1224652054-1272556568-cardhu_decombobulator_blackberry.rim.net-838544338-@bda452.bisx.prod.on.blackberry> References: <1224652054-1272556568-cardhu_decombobulator_blackberry.rim.net-838544338-@bda452.bisx.prod.on.blackberry> Message-ID: <4BD9AE2A.6050101@spectraaccess.com> All the new OS's (IE Windows7) automatically adjust TCP window size. Personally I've never found those website speed test to be that accurate on fast connections (over 15Mbps full duplex). The only way to really confirm bandwidth is by running IPERF. Robert Glover wrote: > Adjust your TCP window size. > > -----Original Message----- > From: "Murphy, William" > Date: Thu, 29 Apr 2010 10:53:01 > To: nanog at nanog.org > Subject: Edu versus Speakeasy Speedtest > > I work for an Edu with multi-gigabit Internet connectivity and I get > questions from users saying "Why am I only getting 14Mb when I run this > speed test?" I have got to believe that the various Internet speed tests > (Speakeasy or dslreports) are rate limited to prevent someone from shutting > them down. I am able to get 300-400Mb running from a PC inside my network > to NDT servers located on Internet2, so that tells me my border and internal > network is healthy. Can someone on this list shed some light regarding > reliability and accuracy of these various speed tests especially for an Edu > with lots'o bandwidth? Thanks. > > > > Bill Murphy > > University of Texas Health Science Center - Houston > > > > > > > From bpfankuch at cpgreeley.com Thu Apr 29 11:10:44 2010 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Thu, 29 Apr 2010 10:10:44 -0600 Subject: Edu versus Speakeasy Speedtest In-Reply-To: <4BD9AE2A.6050101@spectraaccess.com> References: <1224652054-1272556568-cardhu_decombobulator_blackberry.rim.net-838544338-@bda452.bisx.prod.on.blackberry> <4BD9AE2A.6050101@spectraaccess.com> Message-ID: <01759D50DC387C45A018FE1817CE27D76BC3AE63A1@CPExchange1.cpgreeley.com> Agreed. Most of the sites are not accurate for large bandwidth locations. Speedtest.net is flash based, however I find that slightly more accurate up to about 50-100mbit range. -----Original Message----- From: Bret Clark [mailto:bclark at spectraaccess.com] Sent: Thursday, April 29, 2010 10:05 AM To: nanog at nanog.org Subject: Re: Edu versus Speakeasy Speedtest All the new OS's (IE Windows7) automatically adjust TCP window size. Personally I've never found those website speed test to be that accurate on fast connections (over 15Mbps full duplex). The only way to really confirm bandwidth is by running IPERF. Robert Glover wrote: > Adjust your TCP window size. > > -----Original Message----- > From: "Murphy, William" > Date: Thu, 29 Apr 2010 10:53:01 > To: nanog at nanog.org > Subject: Edu versus Speakeasy Speedtest > > I work for an Edu with multi-gigabit Internet connectivity and I get > questions from users saying "Why am I only getting 14Mb when I run > this speed test?" I have got to believe that the various Internet > speed tests (Speakeasy or dslreports) are rate limited to prevent > someone from shutting them down. I am able to get 300-400Mb running > from a PC inside my network to NDT servers located on Internet2, so > that tells me my border and internal network is healthy. Can someone > on this list shed some light regarding reliability and accuracy of > these various speed tests especially for an Edu with lots'o bandwidth? Thanks. > > > > Bill Murphy > > University of Texas Health Science Center - Houston > > > > > > > From scott at sberkman.net Thu Apr 29 11:12:13 2010 From: scott at sberkman.net (Scott Berkman) Date: Thu, 29 Apr 2010 12:12:13 -0400 Subject: Edu versus Speakeasy Speedtest In-Reply-To: <4BD9AE2A.6050101@spectraaccess.com> References: <1224652054-1272556568-cardhu_decombobulator_blackberry.rim.net-838544338-@bda452.bisx.prod.on.blackberry> <4BD9AE2A.6050101@spectraaccess.com> Message-ID: <006401cae7b6$bb1e9c10$315bd430$@net> 2 things. 1: http://speakeasy.net/speedtest/issues.php (See the section on inaccurate results over 20Mbps and that the test is meant for "residential broadband services") 2: Speakeasy is a commerical ISP for both residential and business users. That means it is in their best interest to encourage you to purchase their services. I have no issues with Speakeasy and have used them personally with great success in the past (great support but prices are a little high for most residential users), but why would you test one provider's service with a sales tool from another (competing) provider and expect accuracy? -Scott -----Original Message----- From: Bret Clark [mailto:bclark at spectraaccess.com] Sent: Thursday, April 29, 2010 12:05 PM To: nanog at nanog.org Subject: Re: Edu versus Speakeasy Speedtest All the new OS's (IE Windows7) automatically adjust TCP window size. Personally I've never found those website speed test to be that accurate on fast connections (over 15Mbps full duplex). The only way to really confirm bandwidth is by running IPERF. Robert Glover wrote: > Adjust your TCP window size. > > -----Original Message----- > From: "Murphy, William" > Date: Thu, 29 Apr 2010 10:53:01 > To: nanog at nanog.org > Subject: Edu versus Speakeasy Speedtest > > I work for an Edu with multi-gigabit Internet connectivity and I get > questions from users saying "Why am I only getting 14Mb when I run this > speed test?" I have got to believe that the various Internet speed tests > (Speakeasy or dslreports) are rate limited to prevent someone from shutting > them down. I am able to get 300-400Mb running from a PC inside my network > to NDT servers located on Internet2, so that tells me my border and internal > network is healthy. Can someone on this list shed some light regarding > reliability and accuracy of these various speed tests especially for an Edu > with lots'o bandwidth? Thanks. > > > > Bill Murphy > > University of Texas Health Science Center - Houston > > > > > > > From owen at delong.com Thu Apr 29 11:23:37 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 29 Apr 2010 09:23:37 -0700 Subject: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] In-Reply-To: References: <20100421043432.GB25523@vacation.karoshi.com.> <4D227B33-7D6C-4B4C-AF1D-41C338205411@delong.com> <20100422071720.7f7403b5@opy.nosense.org> <20100425113106.6b12817c@opy.nosense.org> <4BD5A12E.50907@sprunk.org> Message-ID: On Apr 29, 2010, at 8:45 AM, Bill Stewart wrote: > On Mon, Apr 26, 2010 at 7:20 AM, Stephen Sprunk wrote: > >> The vast majority of residential customers have a single subnet, so they >> can get by just fine using IPv6 link-local addresses. The vanishingly >> small percentage that have multiple subnets are presumably savvy enough >> to set up ULA-R addresses. There is no need for ULA-C in this scenario. > > Actually it's pretty common for residential customers to have multiple subnets, > one wired and one wireless, even if they're both NAT'd to 192.168.x.x. > They may may or not be doing anything with the wired subnet, > and their wireless router may also be providing a wired subnet bridged > with the wireless, If it's bridged, they are not separate subnets. This is the most common configuration. For one thing, if they are both NAT'd, things on wireless the consumer expects to be able to talk to things on wired tend not to work. (This is only partially due to NAT, but, largely due to lazy code that assumes everything is on one subnet which is usually a safe assumption. The reason this became a usually safe assumption is another example of damage done by NAT). > and it's all happening in little consumer-appliance boxes that work by magic, > but it's out there. > Not quite the way you seem to think it is. Owen From tmagill at providecommerce.com Thu Apr 29 08:43:48 2010 From: tmagill at providecommerce.com (Thomas Magill) Date: Thu, 29 Apr 2010 06:43:48 -0700 Subject: International TE Message-ID: I am interested in only accepting international traffic from one of our secondary providers only. Most providers I have dealt with have a TE community list which allows me to prepend or not not advertise to their upstream peers. However, my primary provider does not have this. My goal is to not advertise internationally through this provider. I am considering just setting the communities for my provider's upstream peers (about 7 of them) to tell them to not advertise internationally. I am also trying to get my primary provider to implement this functionality. Are there any better ways to do this? Also, if anyone has a consolidated list of provider TE communities that would be a great resource. Thomas Magill Network Engineer Office: (858) 909-3777 Cell: (858) 869-9685 tmagill at providecommerce.com provide-commerce 4840 Eastgate Mall San Diego, CA 92121 ProFlowers | redENVELOPE | Cherry Moon Farms | Shari's Berries From smooge at gmail.com Thu Apr 29 12:48:51 2010 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 29 Apr 2010 11:48:51 -0600 Subject: Edu versus Speakeasy Speedtest In-Reply-To: References: Message-ID: On Thu, Apr 29, 2010 at 9:53 AM, Murphy, William wrote: > I work for an Edu with multi-gigabit Internet connectivity and I get > questions from users saying "Why am I only getting 14Mb when I run this > speed test?" ?I have got to believe that the various Internet speed tests > (Speakeasy or dslreports) are rate limited to prevent someone from shutting > them down. ?I am able to get 300-400Mb running from a PC inside my network > to NDT servers located on Internet2, so that tells me my border and internal > network is healthy. ?Can someone on this list shed some light regarding > reliability and accuracy of these various speed tests especially for an Edu > with lots'o bandwidth? ?Thanks. > > > > Bill Murphy > > University of Texas Health Science Center - Houston > Best analogy I ever saw to teach Phd's why the net was slow: Take a vacuum cleaner with extensions. Make a set of end connectors from smaller and smaller tubes (garden hose, and straw I think they were duct taped to vacuum cleaner ends). Have the complainer try to clean up a mess with each of the ends. Ask them why it took much longer with the straw versus the regular end. For the dimwitted (eg 2-3 Phd's and various honors) elaborate that the vacuum cleaner is like your computer.. for things local and on Internet2 you get a regular hose. On going to DSlreports etc you are going at some point through a straw. [Actually i think the tube had a straw duct taped at the middle... and had things painted on it saying "What we control. What we don't control. What they control. What they don't control" ] At this point most people realized networking wasnt' the people to complain to] -- Stephen J Smoogen. ?The core skill of innovators is error recovery, not failure avoidance.? Randy Nelson, President of Pixar University. "We have a strategic plan. It's called doing things."" ? Herb Kelleher, founder Southwest Airlines From arievayner at gmail.com Thu Apr 29 13:41:18 2010 From: arievayner at gmail.com (Arie Vayner) Date: Thu, 29 Apr 2010 21:41:18 +0300 Subject: International TE In-Reply-To: References: Message-ID: Thomas, Check this link: http://onesc.net/communities/ You can always play with as-path prepending and advertising a more specific subnets through different providers... Arie On Thu, Apr 29, 2010 at 4:43 PM, Thomas Magill wrote: > I am interested in only accepting international traffic from one of our > secondary providers only. Most providers I have dealt with have a TE > community list which allows me to prepend or not not advertise to their > upstream peers. However, my primary provider does not have this. My > goal is to not advertise internationally through this provider. I am > considering just setting the communities for my provider's upstream > peers (about 7 of them) to tell them to not advertise internationally. > I am also trying to get my primary provider to implement this > functionality. > > > > Are there any better ways to do this? Also, if anyone has a > consolidated list of provider TE communities that would be a great > resource. > > > > Thomas Magill > Network Engineer > > Office: (858) 909-3777 > > Cell: (858) 869-9685 > tmagill at providecommerce.com > > > provide-commerce > 4840 Eastgate Mall > > San Diego, CA 92121 > > > > ProFlowers | redENVELOPE > | Cherry Moon Farms > | Shari's Berries > > > > > From virendra.rode at gmail.com Thu Apr 29 14:45:31 2010 From: virendra.rode at gmail.com (virendra rode) Date: Thu, 29 Apr 2010 12:45:31 -0700 Subject: SMW4 Routing Implications In-Reply-To: References: Message-ID: <4BD9E1DB.6080806@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, shake righa wrote: > What have been the routing implications in regards to internet traffic > with SMW4 > cable beign down? - ----------------------------------- Latency and slowness then again things are starting to change (mid-2010) in terms of traffic balance as fibers are being lit across diverse paths. regards, /virendra > > > > Regards, > Shake Righa > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFL2eHbpbZvCIJx1bcRAjLfAKDl8ouIT9zH2pzjs/1uIafx8E281gCgvRXn NdDyrX58kLpasNXDEcVgMCo= =/YYx -----END PGP SIGNATURE----- From jolsen at devry.com Thu Apr 29 15:11:07 2010 From: jolsen at devry.com (Olsen, Jason) Date: Thu, 29 Apr 2010 15:11:07 -0500 Subject: Terry Childs conviction Message-ID: <63AF18E6CB3D3A47A965A11168C9736F02BB8EEC@MAIL3P.dvuadmin.net> I'm a bit surprised that after the furor here on NANOG when the story first broke (in 2008) that there's been no discussion about the recent outcome of his trial (convicted, one count of felony network tampering). http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2010/04/27/BA4V1D5Q22.D TL&tsp=1 -JFO From james.cutler at consultant.com Thu Apr 29 15:21:26 2010 From: james.cutler at consultant.com (Cutler James R) Date: Thu, 29 Apr 2010 16:21:26 -0400 Subject: Terry Childs conviction In-Reply-To: <63AF18E6CB3D3A47A965A11168C9736F02BB8EEC@MAIL3P.dvuadmin.net> References: <63AF18E6CB3D3A47A965A11168C9736F02BB8EEC@MAIL3P.dvuadmin.net> Message-ID: On Apr 29, 2010, at 4:11 PM, Olsen, Jason wrote: I'm a bit surprised that after the furor here on NANOG when the story first broke (in 2008) that there's been no discussion about the recent outcome of his trial (convicted, one count of felony network tampering). === I'm not surprised. It has little or no direct operational impact. James R. Cutler james.cutler at consultant.com From hrlinneweh at sbcglobal.net Thu Apr 29 15:25:21 2010 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Thu, 29 Apr 2010 13:25:21 -0700 (PDT) Subject: Terry Childs conviction In-Reply-To: <63AF18E6CB3D3A47A965A11168C9736F02BB8EEC@MAIL3P.dvuadmin.net> References: <63AF18E6CB3D3A47A965A11168C9736F02BB8EEC@MAIL3P.dvuadmin.net> Message-ID: <667687.2850.qm@web180311.mail.gq1.yahoo.com> Anytime you mess with a government entity, without legal guidance, you are at great risk. Mr.Childs took a risk and jury decided he was wrong. He faces 5 years in prison. -henry ________________________________ From: "Olsen, Jason" To: nanog at nanog.org Sent: Thu, April 29, 2010 1:11:07 PM Subject: Terry Childs conviction I'm a bit surprised that after the furor here on NANOG when the story first broke (in 2008) that there's been no discussion about the recent outcome of his trial (convicted, one count of felony network tampering). http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2010/04/27/BA4V1D5Q22.D TL&tsp=1 -JFO From gwbnanog at gmail.com Thu Apr 29 16:03:46 2010 From: gwbnanog at gmail.com (gwbnanog) Date: Thu, 29 Apr 2010 17:03:46 -0400 Subject: Time Warner Cable / Roadrunner contact - routing issue Message-ID: If there is a Time Warner Cable / Roadrunner routing engineer monitoring this list can you please contact me off list regarding a routing issue from your IP block: 76.168.0.0/13 Thank you. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Apr 29 16:24:03 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Fri, 30 Apr 2010 06:54:03 +0930 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100420193147.C69612B2128@mx5.roble.com> <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> <1271813655.6417.431.camel@karl> Message-ID: <20100430065403.08d5c403@opy.nosense.org> On Wed, 21 Apr 2010 14:24:37 -0400 William Herrin wrote: > On Tue, Apr 20, 2010 at 9:34 PM, Karl Auer wrote: > > On Tue, 2010-04-20 at 12:59 -0700, Owen DeLong wrote: > >> On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote: > >> > NAT _always_ fails-closed > >> Stateful Inspection can be implemented fail-closed. > > > > Not to take issue with either statement in particular, but I think there > > needs to be some consideration of what "fail" means. > > Fail means that an inexperienced admin drops a router in place of the > firewall to work around a priority problem while the senior engineer > is on vacation. With NAT protecting unroutable addresses, that failure > mode fails closed. > Fail is expecting a low level staff member, who doesn't know better, to substitute for a senior one, who does. Would you also let a helpdesk teamleader (low level, relatively inexperienced management position) take over the CEO's job if the CEO was available and there was a business crisis? A medical student take over from a doctor in an emergency ward? > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > From andrew.wallace at rocketmail.com Thu Apr 29 16:25:49 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 29 Apr 2010 14:25:49 -0700 (PDT) Subject: [only half OT] A socio-psychological analysis of the first internet war (Estonia) In-Reply-To: <4BD90221.5010800@linuxbox.org> Message-ID: <35052.88342.qm@web59610.mail.ac4.yahoo.com> --- On Thu, 29/4/10, Gadi Evron wrote: > A socio-psychological analysis of the first internet war (Estonia) There has been no cyber war yet. Estonia was not a cyber war. You've got it fundamentally wrong on the world stage infront of everyone. Andrew From nanog at enger.us Thu Apr 29 16:31:25 2010 From: nanog at enger.us (Robert Enger - NANOG) Date: Thu, 29 Apr 2010 14:31:25 -0700 Subject: Edu versus Speakeasy Speedtest In-Reply-To: References: Message-ID: <4BD9FAAD.9050401@enger.us> 1) The capacity that a campus has into I2 or NLR is different than the BW the campus purchases from their commercial provider(s). 2) The commercial BW test sites are not optimized for speed. They do not have unlimited capacity network connections. And, they have not tuned their network stack for HS operation: notably, their OS will impose memory limits on the socket / transmit-buffer pool; so even if a receiver advertises a big window, frequently the transmitter (speed test server) will never queue enough data to fill the pipe 3) Peering capacity is not what it should be into the networks used by some of the BW test sites. On 4/29/2010 8:53 AM, Murphy, William wrote: > I work for an Edu with multi-gigabit Internet connectivity and I get > questions from users saying "Why am I only getting 14Mb when I run this > speed test?" I have got to believe that the various Internet speed tests > (Speakeasy or dslreports) are rate limited to prevent someone from shutting > them down. I am able to get 300-400Mb running from a PC inside my network > to NDT servers located on Internet2, so that tells me my border and internal > network is healthy. Can someone on this list shed some light regarding > reliability and accuracy of these various speed tests especially for an Edu > with lots'o bandwidth? Thanks. > > > > Bill Murphy > > University of Texas Health Science Center - Houston > > > From nenolod at systeminplace.net Thu Apr 29 16:47:02 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 29 Apr 2010 16:47:02 -0500 Subject: Terry Childs conviction In-Reply-To: <63AF18E6CB3D3A47A965A11168C9736F02BB8EEC@MAIL3P.dvuadmin.net> References: <63AF18E6CB3D3A47A965A11168C9736F02BB8EEC@MAIL3P.dvuadmin.net> Message-ID: <1272577622.29108.44.camel@petrie> On Thu, 2010-04-29 at 15:11 -0500, Olsen, Jason wrote: > I'm a bit surprised that after the furor here on NANOG when the story > first broke (in 2008) that there's been no discussion about the recent > outcome of his trial (convicted, one count of felony network tampering). Surely even at DeVry they teach that if you refuse to hand over passwords for property that is not legally yours, that you are committing a crime. I mean, think about it, it's effectively theft, in the same sense that if you refuse to hand over the keys for a car that you don't own, you're committing theft of an automobile. I fail to see the operational relevance to this conviction; it's basic common sense. William From isabeldias1 at yahoo.com Thu Apr 29 16:57:32 2010 From: isabeldias1 at yahoo.com (isabel dias) Date: Thu, 29 Apr 2010 14:57:32 -0700 (PDT) Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100430065403.08d5c403@opy.nosense.org> References: <20100420193147.C69612B2128@mx5.roble.com> <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> <1271813655.6417.431.camel@karl> <20100430065403.08d5c403@opy.nosense.org> Message-ID: <165309.21664.qm@web52607.mail.re2.yahoo.com> CEO position -> >>>>Did you know: > The majority of S&P 500 CEOs are in their 50s > 29% of S&P 500 CEOs have an advanced degree other than an MBA > CEOs in the S&P 401-500 group are more likely to have a shorter tenure with his or her company than other S&P 500 CEOs > 60% of S&P 500 CEOs have been in office less than six years > CEOs of the top 100 S&P 500 companies are more likely than the rest of the S&P 500 CEOs to have been with the same company throughout their entire career Operation Director ->>>>>> some say that age wouldn't be that important, though maturity might. How would they feel about being given this much power? What kinds of goals should they have in mind if they get the job? Don't forget that the person over 30 may be just as new to IT as a fresh college graduate. more ...and more .....you just won't believe how this is smashing your hearts to pieces ...... CAREER HISTORY 1996-2000: Graduate trainee rising to marketing manager Are you sure you don't need a network technician to do the job? ----- Original Message ---- From: Mark Smith To: William Herrin Cc: nanog at nanog.org Sent: Thu, April 29, 2010 10:24:03 PM Subject: Re: Rate of growth on IPv6 not fast enough? On Wed, 21 Apr 2010 14:24:37 -0400 William Herrin wrote: > On Tue, Apr 20, 2010 at 9:34 PM, Karl Auer wrote: > > On Tue, 2010-04-20 at 12:59 -0700, Owen DeLong wrote: > >> On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote: > >> > NAT _always_ fails-closed > >> Stateful Inspection can be implemented fail-closed. > > > > Not to take issue with either statement in particular, but I think there > > needs to be some consideration of what "fail" means. > > Fail means that an inexperienced admin drops a router in place of the > firewall to work around a priority problem while the senior engineer > is on vacation. With NAT protecting unroutable addresses, that failure > mode fails closed. > Fail is expecting a low level staff member, who doesn't know better, to substitute for a senior one, who does. Would you also let a helpdesk teamleader (low level, relatively inexperienced management position) take over the CEO's job if the CEO was available and there was a business crisis? A medical student take over from a doctor in an emergency ward? > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > From dave at knig.ht Thu Apr 29 18:09:27 2010 From: dave at knig.ht (Dave Knight) Date: Thu, 29 Apr 2010 19:09:27 -0400 Subject: DNSSEC Deployment in ARPA Children In-Reply-To: <00798CDC-AC6C-4E59-AB7D-D698250126BA@icann.org> References: <00798CDC-AC6C-4E59-AB7D-D698250126BA@icann.org> Message-ID: On 2010-04-28, at 9:29 AM, Joe Abley wrote: > Colleagues, > > ICANN plans to begin a test deployment of DNSSEC in various zones starting on 2010-04-29: > > IN-ADDR-SERVERS.ARPA > IP6.ARPA > IP6-SERVERS.ARPA > IRIS.ARPA > URI.ARPA > URN.ARPA > > These zones will be signed using RSASHA256 and NSEC with 2048-bit KSKs and 1024-bit ZSKs. The maintenance is complete, all of the zones are now DNSSEC signed. We expect to include trust anchors for these zones following a testing period of around two weeks, given no observed or reported harmful effects. If you observe any issues, or have any concerns please let us know at . Kind regards, Dave Knight Senior DNS Engineer, ICANN From Valdis.Kletnieks at vt.edu Thu Apr 29 19:15:08 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 29 Apr 2010 20:15:08 -0400 Subject: Terry Childs conviction In-Reply-To: Your message of "Thu, 29 Apr 2010 16:47:02 CDT." <1272577622.29108.44.camel@petrie> References: <63AF18E6CB3D3A47A965A11168C9736F02BB8EEC@MAIL3P.dvuadmin.net> <1272577622.29108.44.camel@petrie> Message-ID: <9120.1272586508@localhost> On Thu, 29 Apr 2010 16:47:02 CDT, William Pitcock said: > On Thu, 2010-04-29 at 15:11 -0500, Olsen, Jason wrote: > > I'm a bit surprised that after the furor here on NANOG when the story > > first broke (in 2008) that there's been no discussion about the recent > > outcome of his trial (convicted, one count of felony network tampering). > > Surely even at DeVry they teach that if you refuse to hand over > passwords for property that is not legally yours, that you are > committing a crime. I mean, think about it, it's effectively theft, in > the same sense that if you refuse to hand over the keys for a car that > you don't own, you're committing theft of an automobile. Unfortunately, Terry Childs was withholding the passwords because he thought (with some justification) that they'd adger up the net if they had the passwords. So if you want to make an analogy, it's more like taking the keys away from a drunk so they can't drive. Good luck finding a DA who will indict you for grand theft auto for taking the keys to prevent a DWI. Operational content: What design, procedure, and policy errors did the network owners make that Childs was able to do that to them? (The cynic in me says that if the net management was that screwed up that he *could* do it, he was justified in doing it... :) -------------- 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 mompl.net Thu Apr 29 20:04:39 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 29 Apr 2010 18:04:39 -0700 Subject: Terry Childs conviction In-Reply-To: <667687.2850.qm@web180311.mail.gq1.yahoo.com> References: <63AF18E6CB3D3A47A965A11168C9736F02BB8EEC@MAIL3P.dvuadmin.net> <667687.2850.qm@web180311.mail.gq1.yahoo.com> Message-ID: <4BDA2CA7.8000207@mompl.net> Henry Linneweh wrote: > Anytime you mess with a government entity, without legal guidance, you are at > great risk. Mr.Childs took a risk and jury decided he was wrong. He faces > 5 years in prison. Unlikely. From the article: "However, Judge Teri Jackson is expected to impose a sentence under which Childs would serve a few additional months at most, after she gives him credit for the nearly two years he has spent in county jail since being arrested in July 2008" I didn't know jury trials went this way, if a juror doesn't agree you simply kick the person out. You learn something new every day. :-) "The jury deliberated for several days before a lone holdout against conviction was removed from the panel, for reasons that were not disclosed. After an alternate was put in that juror's place, the panel started over and reached a decision in a matter of hours." And one can argue he behaved like any security conscious IT person should behave, although I'm sure in this case the truth lies more in the middle: "Shikman acknowledged that Childs may have been "paranoid" about protecting the system and undiplomatic with his bosses, but nothing worse (..) "All they had to do was ask him (for the passwords) in a secure and professional way, consistent with policy and standards," Shikman told the jury." Regards, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ From mysidia at gmail.com Thu Apr 29 20:49:18 2010 From: mysidia at gmail.com (James Hess) Date: Thu, 29 Apr 2010 20:49:18 -0500 Subject: Terry Childs conviction In-Reply-To: <9120.1272586508@localhost> References: <63AF18E6CB3D3A47A965A11168C9736F02BB8EEC@MAIL3P.dvuadmin.net> <1272577622.29108.44.camel@petrie> <9120.1272586508@localhost> Message-ID: On Thu, Apr 29, 2010 at 7:15 PM, wrote: > So if you want to make an analogy, it's more like taking the keys away from > a drunk so they can't drive. ?Good luck finding a DA who will indict you for > grand theft auto for taking the keys to prevent a DWI. According to news reports in this case it was not a charge of theft, but a charge of criminal Denial of Service. The service denied being the ability to administer their network devices by their authorized admins: in this case that Childs had been ordered by people with management authority over him on various occasions to provide some access to equipment they owned, and he had refused on all occasions, or deceived them by intentionally providing incomplete or useless access details. It was well within management's authority to demand this, and not in violation of any laws (not equivalent to DWI). It may be of concern to some individuals, but the operational impact to well-managed networks should be zero. Make sure the collective management of the organization that owns the network has a means of directly conveying full access at all times to any user they authorize, that is provided on demand, or that there is a clear password policy that ensures that administration cannot be denied to authorized users ? "Theft" of keys does not equal theft of vehicle, and restraining someone who is not acting rationally and is intent upon committing a crime, directly endangering lives, is completely different Courts might take a much more dim view towards a valet/driver re-assigned to a different job refusing to surrender the keys to the owner's new valet, out of fear the vehicle might get treated in a way they considered poor or reckless. -- -J From david at davidkrider.com Thu Apr 29 20:48:43 2010 From: david at davidkrider.com (David Krider) Date: Thu, 29 Apr 2010 21:48:43 -0400 Subject: Terry Childs conviction In-Reply-To: <1272577622.29108.44.camel@petrie> References: <63AF18E6CB3D3A47A965A11168C9736F02BB8EEC@MAIL3P.dvuadmin.net> <1272577622.29108.44.camel@petrie> Message-ID: <1272592123.11125.5.camel@enterprise.starfleet.mil> On Thu, 2010-04-29 at 16:47 -0500, William Pitcock wrote: > Surely even at DeVry they teach that if you refuse to hand over > passwords for property that is not legally yours, that you are > committing a crime. I mean, think about it, it's effectively theft, in > the same sense that if you refuse to hand over the keys for a car that > you don't own, you're committing theft of an automobile. I've seen a dismissed employee withhold a password. The owner of the company threatened legal action, considering it, like you, theft. My father-in-law is an attorney, so I asked him about the situation. He said that it wouldn't be called "theft," rather "illegal control." http://www.infoworld.com/t/insider-threat/terry-childs-still-faces-one-charge-one-he-shouldnt-face-746 The more-informed reporting on this says that the charge was actually "illegal denial of service." I'm guessing this is what my father-in-law was getting at, or that this is what "illegal control" means when applied to computer equipment. dk From bill at herrin.us Thu Apr 29 20:58:24 2010 From: bill at herrin.us (William Herrin) Date: Thu, 29 Apr 2010 15:58:24 -1000 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: <20100430065403.08d5c403@opy.nosense.org> References: <20100420193147.C69612B2128@mx5.roble.com> <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> <1271813655.6417.431.camel@karl> <20100430065403.08d5c403@opy.nosense.org> Message-ID: On Thu, Apr 29, 2010 at 11:24 AM, Mark Smith wrote: > On Wed, 21 Apr 2010 14:24:37 -0400 > William Herrin wrote: >> Fail means that an inexperienced admin drops a router in place of the >> firewall to work around a priority problem while the senior engineer >> is on vacation. With NAT protecting unroutable addresses, that failure >> mode fails closed. > > Fail is expecting a low level staff member, who doesn't know better, to > substitute for a senior one, who does. Funny thing about junior staff... Their reach is often longer than their grasp. Someone has to have the keys when the senior guy is away... Even if they don't always have the good judgment to know what they can safely do with them. As the senior guy, I'd rather find out about the mistake when the panicked junior calls me on the cell phone because he crashed the network, not when I get back and find the company jewels have been stolen. NAT protecting unroutable addresses gives me a better chance that junior's mistake only causes a network outage. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nenolod at systeminplace.net Thu Apr 29 21:05:14 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 29 Apr 2010 21:05:14 -0500 Subject: Terry Childs conviction In-Reply-To: <1272592123.11125.5.camel@enterprise.starfleet.mil> References: <63AF18E6CB3D3A47A965A11168C9736F02BB8EEC@MAIL3P.dvuadmin.net> <1272577622.29108.44.camel@petrie> <1272592123.11125.5.camel@enterprise.starfleet.mil> Message-ID: <1272593114.29108.46.camel@petrie> On Thu, 2010-04-29 at 21:48 -0400, David Krider wrote: > On Thu, 2010-04-29 at 16:47 -0500, William Pitcock wrote: > > Surely even at DeVry they teach that if you refuse to hand over > > passwords for property that is not legally yours, that you are > > committing a crime. I mean, think about it, it's effectively theft, in > > the same sense that if you refuse to hand over the keys for a car that > > you don't own, you're committing theft of an automobile. > > I've seen a dismissed employee withhold a password. The owner of the > company threatened legal action, considering it, like you, theft. My > father-in-law is an attorney, so I asked him about the situation. He > said that it wouldn't be called "theft," rather "illegal control." Same difference, he still committed a crime and anyone who is defending him seems to not understand this. Whatever we want to call that crime, it's still a crime, and he got the appropriate penalty. William From ernesto at cs.fiu.edu Thu Apr 29 21:21:13 2010 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Thu, 29 Apr 2010 22:21:13 -0400 Subject: Terry Childs conviction In-Reply-To: <1272593114.29108.46.camel@petrie> References: <63AF18E6CB3D3A47A965A11168C9736F02BB8EEC@MAIL3P.dvuadmin.net> <1272577622.29108.44.camel@petrie> <1272592123.11125.5.camel@enterprise.starfleet.mil> <1272593114.29108.46.camel@petrie> Message-ID: Illegal control = Conversion = at least a tort, but could also be a crime. On Apr 29, 2010, at 10:05 PM, William Pitcock wrote: > On Thu, 2010-04-29 at 21:48 -0400, David Krider wrote: >> On Thu, 2010-04-29 at 16:47 -0500, William Pitcock wrote: >>> Surely even at DeVry they teach that if you refuse to hand over >>> passwords for property that is not legally yours, that you are >>> committing a crime. I mean, think about it, it's effectively theft, in >>> the same sense that if you refuse to hand over the keys for a car that >>> you don't own, you're committing theft of an automobile. >> >> I've seen a dismissed employee withhold a password. The owner of the >> company threatened legal action, considering it, like you, theft. My >> father-in-law is an attorney, so I asked him about the situation. He >> said that it wouldn't be called "theft," rather "illegal control." > > Same difference, he still committed a crime and anyone who is defending > him seems to not understand this. Whatever we want to call that crime, > it's still a crime, and he got the appropriate penalty. > > William > > From robert at timetraveller.org Thu Apr 29 21:27:33 2010 From: robert at timetraveller.org (Robert Brockway) Date: Thu, 29 Apr 2010 22:27:33 -0400 (EDT) Subject: Terry Childs conviction In-Reply-To: <1272593114.29108.46.camel@petrie> References: <63AF18E6CB3D3A47A965A11168C9736F02BB8EEC@MAIL3P.dvuadmin.net> <1272577622.29108.44.camel@petrie> <1272592123.11125.5.camel@enterprise.starfleet.mil> <1272593114.29108.46.camel@petrie> Message-ID: On Thu, 29 Apr 2010, William Pitcock wrote: > Same difference, he still committed a crime and anyone who is defending > him seems to not understand this. Whatever we want to call that crime, > it's still a crime, and he got the appropriate penalty. Hi William. I have to agree that it does seem he committed an offence but we will have to agree to disagree on the penalty. Two years (or more) in jail for withholding a password for one week seems disproportionate to me. I wonder how expensive the trial was. Rob -- Email: robert at timetraveller.org IRC: Solver Web: http://www.practicalsysadmin.com Open Source: The revolution that silently changed the world From LarrySheldon at cox.net Thu Apr 29 21:23:01 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 29 Apr 2010 21:23:01 -0500 Subject: Terry Childs conviction In-Reply-To: <1272593114.29108.46.camel@petrie> References: <63AF18E6CB3D3A47A965A11168C9736F02BB8EEC@MAIL3P.dvuadmin.net> <1272577622.29108.44.camel@petrie> <1272592123.11125.5.camel@enterprise.starfleet.mil> <1272593114.29108.46.camel@petrie> Message-ID: <4BDA3F05.7040303@cox.net> On 4/29/2010 21:05, William Pitcock wrote: > On Thu, 2010-04-29 at 21:48 -0400, David Krider wrote: >> On Thu, 2010-04-29 at 16:47 -0500, William Pitcock wrote: >>> Surely even at DeVry they teach that if you refuse to hand over >>> passwords for property that is not legally yours, that you are >>> committing a crime. I mean, think about it, it's effectively theft, in >>> the same sense that if you refuse to hand over the keys for a car that >>> you don't own, you're committing theft of an automobile. >> >> I've seen a dismissed employee withhold a password. The owner of the >> company threatened legal action, considering it, like you, theft. My >> father-in-law is an attorney, so I asked him about the situation. He >> said that it wouldn't be called "theft," rather "illegal control." > > Same difference, he still committed a crime and anyone who is defending > him seems to not understand this. Whatever we want to call that crime, > it's still a crime, and he got the appropriate penalty. I beg to differ (the archives may reflect my objection last time around). I agree that a crime was committed. It was committed by the management that allowed this situation to exist. It is a pretty easy matter to maintain controls that make the passwords secure but still available to management when they need it. The simplest system was one of sealed envelopes in several different District Managers locked desks. Every now and again a manager would take his or her envelope out and test the passwords to see if they worked (usually just before the scheduled password change each month). -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From Valdis.Kletnieks at vt.edu Thu Apr 29 21:27:15 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 29 Apr 2010 22:27:15 -0400 Subject: Rate of growth on IPv6 not fast enough? In-Reply-To: Your message of "Thu, 29 Apr 2010 15:58:24 -1000." References: <20100420193147.C69612B2128@mx5.roble.com> <108FDF80-F74E-4E5C-B27B-868458D9C63A@delong.com> <1271813655.6417.431.camel@karl> <20100430065403.08d5c403@opy.nosense.org> Message-ID: <13139.1272594435@localhost> On Thu, 29 Apr 2010 15:58:24 -1000, William Herrin said: > Funny thing about junior staff... Their reach is often longer than > their grasp. Someone has to have the keys when the senior guy is > away... Isn't that the defense that Terry Childs used? :) (Sorry, couldn't resist. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nenolod at systeminplace.net Thu Apr 29 21:37:16 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 29 Apr 2010 21:37:16 -0500 Subject: Terry Childs conviction In-Reply-To: <4BDA3F05.7040303@cox.net> References: <63AF18E6CB3D3A47A965A11168C9736F02BB8EEC@MAIL3P.dvuadmin.net> <1272577622.29108.44.camel@petrie> <1272592123.11125.5.camel@enterprise.starfleet.mil> <1272593114.29108.46.camel@petrie> <4BDA3F05.7040303@cox.net> Message-ID: <1272595036.29108.47.camel@petrie> On Thu, 2010-04-29 at 21:23 -0500, Larry Sheldon wrote: > On 4/29/2010 21:05, William Pitcock wrote: > > On Thu, 2010-04-29 at 21:48 -0400, David Krider wrote: > >> On Thu, 2010-04-29 at 16:47 -0500, William Pitcock wrote: > >>> Surely even at DeVry they teach that if you refuse to hand over > >>> passwords for property that is not legally yours, that you are > >>> committing a crime. I mean, think about it, it's effectively theft, in > >>> the same sense that if you refuse to hand over the keys for a car that > >>> you don't own, you're committing theft of an automobile. > >> > >> I've seen a dismissed employee withhold a password. The owner of the > >> company threatened legal action, considering it, like you, theft. My > >> father-in-law is an attorney, so I asked him about the situation. He > >> said that it wouldn't be called "theft," rather "illegal control." > > > > Same difference, he still committed a crime and anyone who is defending > > him seems to not understand this. Whatever we want to call that crime, > > it's still a crime, and he got the appropriate penalty. > > I beg to differ (the archives may reflect my objection last time around). > > I agree that a crime was committed. > > It was committed by the management that allowed this situation to exist. > > It is a pretty easy matter to maintain controls that make the passwords > secure but still available to management when they need it. The > simplest system was one of sealed envelopes in several different > District Managers locked desks. Every now and again a manager would > take his or her envelope out and test the passwords to see if they > worked (usually just before the scheduled password change each month). I don't disagree, but he should not have withheld passwords to devices that were not his direct property when asked by a superior. William From ernesto at cs.fiu.edu Thu Apr 29 21:21:13 2010 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Thu, 29 Apr 2010 22:21:13 -0400 Subject: Terry Childs conviction In-Reply-To: <1272593114.29108.46.camel@petrie> References: <63AF18E6CB3D3A47A965A11168C9736F02BB8EEC@MAIL3P.dvuadmin.net> <1272577622.29108.44.camel@petrie> <1272592123.11125.5.camel@enterprise.starfleet.mil> <1272593114.29108.46.camel@petrie> Message-ID: Illegal control = Conversion = at least a tort, but could also be a crime. On Apr 29, 2010, at 10:05 PM, William Pitcock wrote: > On Thu, 2010-04-29 at 21:48 -0400, David Krider wrote: >> On Thu, 2010-04-29 at 16:47 -0500, William Pitcock wrote: >>> Surely even at DeVry they teach that if you refuse to hand over >>> passwords for property that is not legally yours, that you are >>> committing a crime. I mean, think about it, it's effectively theft, in >>> the same sense that if you refuse to hand over the keys for a car that >>> you don't own, you're committing theft of an automobile. >> >> I've seen a dismissed employee withhold a password. The owner of the >> company threatened legal action, considering it, like you, theft. My >> father-in-law is an attorney, so I asked him about the situation. He >> said that it wouldn't be called "theft," rather "illegal control." > > Same difference, he still committed a crime and anyone who is defending > him seems to not understand this. Whatever we want to call that crime, > it's still a crime, and he got the appropriate penalty. > > William > > From jgreco at ns.sol.net Thu Apr 29 22:12:34 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 29 Apr 2010 22:12:34 -0500 (CDT) Subject: Terry Childs conviction In-Reply-To: <1272595036.29108.47.camel@petrie> from "William Pitcock" at Apr 29, 2010 09:37:16 PM Message-ID: <201004300312.o3U3CYD3069212@aurora.sol.net> > > I beg to differ (the archives may reflect my objection last time around). > > > > I agree that a crime was committed. > > > > It was committed by the management that allowed this situation to exist. Agree. > > It is a pretty easy matter to maintain controls that make the passwords > > secure but still available to management when they need it. The > > simplest system was one of sealed envelopes in several different > > District Managers locked desks. Every now and again a manager would > > take his or her envelope out and test the passwords to see if they > > worked (usually just before the scheduled password change each month). > > I don't disagree, but he should not have withheld passwords to devices > that were not his direct property when asked by a superior. Agree. On the other hand, this gets strange. Once you're fired, just how much can you reasonably be compelled to produce for your former employer's convenience? And that's all this is, because no one has suggested that the network was left nonfunctional, or that it wasn't possible for competent engineers to gain access and control of the system. I've seen people try to compare this to returning a cell phone or laptop, but the fact of the matter is, those are physical devices that can be returned. I remember passwords dating back decades. I'm not going to forget some of them short of brain surgery or Alzheimer's. On the other hand, there are many passwords I've forgotten entirely. If my employer from last week comes to me today, and says, "hey, we need access to this resource, hand over your password," maybe I still remember it, or maybe it was written on a sheet of paper that went to the shredder when I quit. What if it's a month, or a year, or a decade? Where does this obligation to regurgitate information end? What if it's not simple? (Childs was accused of handing over "useless" information, which I am interpreting to mean that it was probably a valid password, but not the full context of how to use it.) Need I provide information on how to dial into a remote access server, log into a router, connect via its aux port to another gizmo, and then from there to my final destination? To cover all possible scenarios could be a heck of a lot of documentation to write up. Am I expected to do that for free? What if I forgot it all? What if I went and shredded any documentation I had at home, wiped all the data from my laptop, all because I was trying to do the right thing by not retaining any intellectual property? What Childs did was wrong, but what his superiors did was ethically and morally inexcusable - they created a scenario where he could be criminally punished for their failure to manage their employee (and their network) appropriately. As far as I'm concerned, they're far more guilty, but of course they won't see the inside of a cell. The precedents set by this case are a bit scary. The lesson for operators should be clear: don't let a prima donna build your network without being thoroughly involved in the process. ... 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 gordslater at ieee.org Fri Apr 30 01:26:14 2010 From: gordslater at ieee.org (gordon b slater) Date: Fri, 30 Apr 2010 07:26:14 +0100 Subject: Edu versus Speakeasy Speedtest In-Reply-To: References: Message-ID: <1272608774.30167.10.camel@ub-g-d2> On Thu, 2010-04-29 at 11:48 -0600, Stephen John Smoogen wrote: > Take a vacuum cleaner with extensions. Make a set of end connectors A "series of tubes" anyone? I'd also show them the rrd/MRTG graph at the perimeter. Be clear to them about the units. Never miss the chance to ask for more budget though. Tell them the ACL filters clog and need changing regularly, just be inventive ;) Gord -- darken room - adjust heater current so that elements glow cherry red - apply drive - tune for maximum smoke and minimum sparking From steve at ipv6canada.com Fri Apr 30 02:15:38 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Fri, 30 Apr 2010 03:15:38 -0400 Subject: Edu versus Speakeasy Speedtest In-Reply-To: <4BD9FAAD.9050401@enger.us> References: <4BD9FAAD.9050401@enger.us> Message-ID: <4BDA839A.5030102@ipv6canada.com> On 2010.04.29 17:31, Robert Enger - NANOG wrote: > 1) The capacity that a campus has into I2 or NLR is different than the > BW the campus purchases from their commercial provider(s). > 2) The commercial BW test sites are not optimized for speed. They do > not have unlimited capacity network connections. And, they have not > tuned their network stack for HS operation: notably, their OS will > impose memory limits on the socket / transmit-buffer pool; so even if a > receiver advertises a big window, frequently the transmitter (speed test > server) will never queue enough data to fill the pipe > 3) Peering capacity is not what it should be into the networks used by > some of the BW test sites. Your observation is disturbingly bleak... do you have a recommendation? ...perhaps a site with good bandwidth and a cluster of iperf(1) boxes available? :) Steve From ge at linuxbox.org Fri Apr 30 07:43:17 2010 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 30 Apr 2010 15:43:17 +0300 Subject: [only half OT] A socio-psychological analysis of the first internetwar (Estonia) In-Reply-To: <65C5927BEED3C2428307863DB5C6C6FB03EB04B4@cx49.800onemail.com> References: <4BD90221.5010800@linuxbox.org> <65C5927BEED3C2428307863DB5C6C6FB03EB04B4@cx49.800onemail.com> Message-ID: <4BDAD065.7030103@linuxbox.org> On 4/29/10 6:04 PM, Michael Smith wrote: > No GPL for the full paper, huh? Back to the cathedral.... > > What's the toll in case I can get some buddies to pitch-in to buy access > to the full content? I don't really expect people to pay for it. I hope it will eventually become freely available. Gadi. > > > > -----Original Message----- > From: Gadi Evron [mailto:ge at linuxbox.org] > Sent: Wednesday, April 28, 2010 11:51 PM > To: NANOG > Subject: [only half OT] A socio-psychological analysis of the first > internetwar (Estonia) > > Hi, > > In the past year I have been working in collaboration with psychologists > > Robert Cialdini and Rosanna Guadagno on a paper analyzing some of what I > > saw from the social perspective in Estonia, when I wrote the post-mortem > > analysis for the 2007 attacks, but didn't understand at the time. > > Aside to botnets and and flood-based attacks, many of the attacks were > "live mobs", or an "online riot" if you like, where individuals simply > sent pings toward Estonian addresses. While it doesn't seem like pings > would cause so much damage -- en masse they certainly did. Then of > course, there is also the psychological aspect... > > ... When everyone and their grandmother attacked with pings, spammers, > professionals and others who know what they are doing then got involved, > > attacking using more sophisticated tools. > > We analyze how the Russian-speaking population online was manipulated to > > attack Estonia (and Georgia) in the "cyber war" incidents, and how it > could happen again (regardless of if any actor is behind it). > > The psychological aspect of this is indeed off-topic to NANOG, but the > attack is analogous to network peak usages with user interest in > high-bandwidth content, and how large networks prepare for such peaks. > > This is about the DDoS attacks, and how a human DDoS has been and can be > > initiated again. It also under-scores the power of individual activism > on the internet, and how it can also be abused. > > I hope some here would find the research useful for their own interest, > if nothing else. Otherwise, sorry for wasting your bandwidth and thanks > for your time. > > Article on El Reg: > http://www.theregister.co.uk/2010/04/28/web_war_one_anonymity/ > > Paper (for download with pay :( ): > http://www.liebertonline.com/doi/abs/10.1089/cyber.2009.0134 > > Thanks, and any comments appreciated. If on psychology, please do it > off-list, though. > > Gadi. > -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From jeffnanog at hvnc.net Fri Apr 30 07:49:08 2010 From: jeffnanog at hvnc.net (Jeff) Date: Fri, 30 Apr 2010 08:49:08 -0400 Subject: Edu versus Speakeasy Speedtest In-Reply-To: <4BDA839A.5030102@ipv6canada.com> References: <4BD9FAAD.9050401@enger.us> <4BDA839A.5030102@ipv6canada.com> Message-ID: <4BDAD1C4.9030300@hvnc.net> On 4/30/10 3:15 AM, Steve Bertrand wrote: > > Your observation is disturbingly bleak... do you have a recommendation? > > ...perhaps a site with good bandwidth and a cluster of iperf(1) boxes > available? :) There are better tools than a simple iperf server: http://psps.perfsonar.net/toolkit/ There are many perfsonar sites to choose from in I2/NLR land. Most gigapops and I2 networks run at least one. The problem is the Faculty^Wusers are smart, but not experienced in networking, so they buy into the marketing and eye candy of the speed dials on the Speakeasy and assorted speed testing tool sites. They see low numbers and then are difficult to convince that the devil is in the details. (which is odd, because that's what they do as scientists.) They also typically don't see the $$$$ spent on i2/nlr connections vs the $ spent on commodity internet connections. ;) Jeff From bclark at spectraaccess.com Fri Apr 30 08:01:23 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Fri, 30 Apr 2010 09:01:23 -0400 Subject: Edu versus Speakeasy Speedtest In-Reply-To: <4BDAD1C4.9030300@hvnc.net> References: <4BD9FAAD.9050401@enger.us> <4BDA839A.5030102@ipv6canada.com> <4BDAD1C4.9030300@hvnc.net> Message-ID: <4BDAD4A3.7020104@spectraaccess.com> Jeff wrote: > > The problem is the Faculty^Wusers are smart, but not experienced in > networking, so they buy into the marketing and eye candy of the speed > dials on the Speakeasy and assorted speed testing tool sites. Not just them, we are constantly dealing with our new HS users who go to those sites then call us to complain that they are not getting the speed they are suppose to get...ugh! It's like clock work, a new circuit goes in and a few hours later we're getting the old "I went to Speakeasy...blah blah blah"! Bret From jeff-kell at utc.edu Fri Apr 30 08:08:03 2010 From: jeff-kell at utc.edu (Jeff Kell) Date: Fri, 30 Apr 2010 09:08:03 -0400 Subject: Edu versus Speakeasy Speedtest In-Reply-To: <4BDAD1C4.9030300@hvnc.net> References: <4BD9FAAD.9050401@enger.us> <4BDA839A.5030102@ipv6canada.com> <4BDAD1C4.9030300@hvnc.net> Message-ID: <4BDAD633.7020706@utc.edu> On 4/30/2010 8:49 AM, Jeff wrote: > There are better tools than a simple iperf server: > > http://psps.perfsonar.net/toolkit/ There is also http://netalyzr.icsi.berkeley.edu/ which is an excellent connectivity check, although your mileage may vary with higher-speed bandwidth testing from it. Jeff From msmith at internap.com Fri Apr 30 08:15:16 2010 From: msmith at internap.com (Michael Smith) Date: Fri, 30 Apr 2010 09:15:16 -0400 Subject: [only half OT] A socio-psychological analysis of the firstinternet war (Estonia) In-Reply-To: <35052.88342.qm@web59610.mail.ac4.yahoo.com> References: <4BD90221.5010800@linuxbox.org> <35052.88342.qm@web59610.mail.ac4.yahoo.com> Message-ID: <65C5927BEED3C2428307863DB5C6C6FB03EB092F@cx49.800onemail.com> What is/isn't a "war"? Was US/Vietnam a war? It wasn't declared legally... do you take issue with using the word war due to the nature of the event, or is it simply a question of scale? From what I've read so far of this paper, the incident being called "a war" isn't central to the thesis. Search / replace "war" with "incident" and the discussion works fine. Your issue with the choice of words might be significant on some level, but you haven't refuted any of the conclusions. -----Original Message----- From: andrew.wallace [mailto:andrew.wallace at rocketmail.com] Sent: Thursday, April 29, 2010 5:26 PM To: nanog at nanog.org; ge at linuxbox.org Subject: Re: [only half OT] A socio-psychological analysis of the firstinternet war (Estonia) --- On Thu, 29/4/10, Gadi Evron wrote: > A socio-psychological analysis of the first internet war (Estonia) There has been no cyber war yet. Estonia was not a cyber war. You've got it fundamentally wrong on the world stage infront of everyone. Andrew From owen at delong.com Fri Apr 30 11:16:39 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 30 Apr 2010 09:16:39 -0700 Subject: x-small IPv4 ISPs going to IPv6 In-Reply-To: <2B842A75-E1E6-4B8F-820D-DA3C25148C62@delong.com> References: <50EE5968-A41E-4BBD-92FE-6F025765E5F2@delong.com> <327D7E22-D689-4F39-9B62-80439653D126@delong.com> <2B842A75-E1E6-4B8F-820D-DA3C25148C62@delong.com> Message-ID: As a data point, there are currently 866* x-small IPv4 ISP organizations in the ARIN region. There are a total of 3,562* ISP organizations in the ARIN region (including IPv4 and IPv6). x-small IPv4 providers as such, constitute about 1/4 of the total ARIN ISP constituency. The maximum revenue impact of an IPv6 waiver for them (removing the $1,000 surcharge for IPv6 /32 pricing) would be $833,000 per year, increasing as the number of organizations affected by the waiver increased. This information is provided strictly as a data point and not in the interests of pushing the discussion in either direction. Owen *The data I used to produce these numbers comes from ARIN staff and is current as of earlier April 29, 2010. ARIN will be publishing the data to their statistics page in the next few days. Please don't blame staff for the publication delay. I asked for the numbers late last night and they have been extremely responsive in getting the data to me and have taken the additional initiative to publish it as quickly as they can within their process. From cscora at apnic.net Fri Apr 30 13:11:06 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 1 May 2010 04:11:06 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201004301811.o3UIB61F020562@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. 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 01 May, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 320010 Prefixes after maximum aggregation: 147697 Deaggregation factor: 2.17 Unique aggregates announced to Internet: 155292 Total ASes present in the Internet Routing Table: 33885 Prefixes per ASN: 9.44 Origin-only ASes present in the Internet Routing Table: 29405 Origin ASes announcing only one prefix: 14332 Transit ASes present in the Internet Routing Table: 4480 Transit-only ASes present in the Internet Routing Table: 102 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (36992) 22 Prefixes from unregistered ASNs in the Routing Table: 352 Unregistered ASNs in the Routing Table: 126 Number of 32-bit ASNs allocated by the RIRs: 543 Prefixes from 32-bit ASNs in the Routing Table: 598 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 189 Number of addresses announced to Internet: 2235997952 Equivalent to 133 /8s, 70 /16s and 159 /24s Percentage of available address space announced: 60.3 Percentage of allocated address space announced: 66.3 Percentage of available address space allocated: 90.9 Percentage of address space in use by end-sites: 82.4 Total number of prefixes smaller than registry allocations: 153558 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 76646 Total APNIC prefixes after maximum aggregation: 26650 APNIC Deaggregation factor: 2.88 Prefixes being announced from the APNIC address blocks: 73318 Unique aggregates announced from the APNIC address blocks: 32160 APNIC Region origin ASes present in the Internet Routing Table: 4017 APNIC Prefixes per ASN: 18.25 APNIC Region origin ASes announcing only one prefix: 1102 APNIC Region transit ASes present in the Internet Routing Table: 627 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 511561792 Equivalent to 30 /8s, 125 /16s and 208 /24s Percentage of available APNIC address space announced: 76.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: 133880 Total ARIN prefixes after maximum aggregation: 68916 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 106725 Unique aggregates announced from the ARIN address blocks: 40693 ARIN Region origin ASes present in the Internet Routing Table: 13659 ARIN Prefixes per ASN: 7.81 ARIN Region origin ASes announcing only one prefix: 5267 ARIN Region transit ASes present in the Internet Routing Table: 1351 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 726007328 Equivalent to 43 /8s, 69 /16s and 254 /24s Percentage of available ARIN address space announced: 61.8 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: 73451 Total RIPE prefixes after maximum aggregation: 42731 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 66426 Unique aggregates announced from the RIPE address blocks: 43668 RIPE Region origin ASes present in the Internet Routing Table: 14406 RIPE Prefixes per ASN: 4.61 RIPE Region origin ASes announcing only one prefix: 7449 RIPE Region transit ASes present in the Internet Routing Table: 2156 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 423767200 Equivalent to 25 /8s, 66 /16s and 44 /24s Percentage of available RIPE address space announced: 78.9 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, 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, 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: 28441 Total LACNIC prefixes after maximum aggregation: 6761 LACNIC Deaggregation factor: 4.21 Prefixes being announced from the LACNIC address blocks: 26851 Unique aggregates announced from the LACNIC address blocks: 13904 LACNIC Region origin ASes present in the Internet Routing Table: 1272 LACNIC Prefixes per ASN: 21.11 LACNIC Region origin ASes announcing only one prefix: 409 LACNIC Region transit ASes present in the Internet Routing Table: 223 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 20 Number of LACNIC addresses announced to Internet: 72741888 Equivalent to 4 /8s, 85 /16s and 244 /24s Percentage of available LACNIC address space announced: 72.3 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6759 Total AfriNIC prefixes after maximum aggregation: 1790 AfriNIC Deaggregation factor: 3.78 Prefixes being announced from the AfriNIC address blocks: 5168 Unique aggregates announced from the AfriNIC address blocks: 1463 AfriNIC Region origin ASes present in the Internet Routing Table: 353 AfriNIC Prefixes per ASN: 14.64 AfriNIC Region origin ASes announcing only one prefix: 105 AfriNIC Region transit ASes present in the Internet Routing Table: 78 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC addresses announced to Internet: 14544384 Equivalent to 0 /8s, 221 /16s and 238 /24s Percentage of available AfriNIC address space announced: 43.3 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 1847 8406 480 Korea Telecom (KIX) 17488 1313 138 122 Hathway IP Over Cable Interne 4755 1292 291 148 TATA Communications formerly 7545 1167 231 102 TPG Internet Pty Ltd 17974 1015 281 18 PT TELEKOMUNIKASI INDONESIA 9583 993 73 489 Sify Limited 4134 941 20454 398 CHINANET-BACKBONE 24560 888 304 170 Bharti Airtel Ltd., Telemedia 4808 843 1589 215 CNCGROUP IP network: China169 9829 808 680 36 BSNL National Internet Backbo 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 3977 3837 293 bellsouth.net, inc. 4323 3831 1116 404 Time Warner Telecom 1785 1785 699 131 PaeTec Communications, Inc. 7018 1555 5758 987 AT&T WorldNet Services 20115 1514 1501 660 Charter Communications 2386 1311 585 928 AT&T Data Communications Serv 3356 1213 10920 422 Level 3 Communications, LLC 6478 1212 249 146 AT&T Worldnet Services 22773 1148 2605 71 Cox Communications, Inc. 11492 1124 222 14 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 35805 617 56 6 United Telecom of Georgia 3292 448 1899 389 TDC Tele Danmark 30890 436 99 203 Evolva Telecom 702 414 1869 330 UUNET - Commercial IP service 8551 401 356 37 Bezeq International 8866 395 117 18 Bulgarian Telecommunication C 3301 367 1414 322 TeliaNet Sweden 3320 365 7072 318 Deutsche Telekom AG 3215 346 3218 102 France Telecom Transpac 12479 332 576 5 Uni2 Autonomous System 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 1546 2965 242 UniNet S.A. de C.V. 10620 1014 229 155 TVCABLE BOGOTA 28573 931 739 92 NET Servicos de Comunicao S.A 7303 720 372 104 Telecom Argentina Stet-France 6503 548 171 212 AVANTEL, S.A. 22047 546 310 15 VTR PUNTO NET S.A. 18881 537 268 11 Global Village Telecom 7738 477 922 30 Telecomunicacoes da Bahia S.A 3816 461 195 70 Empresa Nacional de Telecomun 14117 454 30 13 Telefonica del Sur S.A. 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 1007 189 9 TEDATA 24863 721 145 41 LINKdotNET AS number 36992 629 273 172 Etisalat MISR 3741 273 852 232 The Internet Solution 2018 214 230 111 Tertiary Education Network 33776 205 11 15 Starcomms Nigeria Limited 6713 176 167 12 Itissalat Al-MAGHRIB 29571 172 19 9 Ci Telecom Autonomous system 29975 133 506 14 Vodacom 5536 114 8 3 Internet Egypt Network 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 3977 3837 293 bellsouth.net, inc. 4323 3831 1116 404 Time Warner Telecom 4766 1847 8406 480 Korea Telecom (KIX) 1785 1785 699 131 PaeTec Communications, Inc. 7018 1555 5758 987 AT&T WorldNet Services 8151 1546 2965 242 UniNet S.A. de C.V. 20115 1514 1501 660 Charter Communications 17488 1313 138 122 Hathway IP Over Cable Interne 2386 1311 585 928 AT&T Data Communications Serv 4755 1292 291 148 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3831 3427 Time Warner Telecom 1785 1785 1654 PaeTec Communications, Inc. 4766 1847 1367 Korea Telecom (KIX) 8151 1546 1304 UniNet S.A. de C.V. 17488 1313 1191 Hathway IP Over Cable Interne 4755 1292 1144 TATA Communications formerly 11492 1124 1110 Cable One 22773 1148 1077 Cox Communications, Inc. 6478 1212 1066 AT&T Worldnet Services 7545 1167 1065 TPG Internet Pty Ltd 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 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 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.80.0.0/14 3243 Telepac - Comunicacoes Intera 14.0.0.0/8 237 Merit Network 41.190.66.0/24 37039 Alink Telecom Benin 41.202.96.0/19 29571 Ci Telecom Autonomous system 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 26452 Local Communications Networks 41.223.196.0/24 36990 Alkan Telecom Ltd 41.223.197.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:66 /12:192 /13:397 /14:689 /15:1261 /16:11067 /17:5261 /18:8949 /19:18260 /20:22474 /21:22623 /22:29366 /23:28946 /24:167404 /25:971 /26:1234 /27:629 /28:142 /29:8 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2550 3977 bellsouth.net, inc. 4323 2335 3831 Time Warner Telecom 4766 1481 1847 Korea Telecom (KIX) 1785 1246 1785 PaeTec Communications, Inc. 17488 1063 1313 Hathway IP Over Cable Interne 18566 1040 1059 Covad Communications 11492 1033 1124 Cable One 7018 935 1555 AT&T WorldNet Services 10620 930 1014 TVCABLE BOGOTA 8452 907 1007 TEDATA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:261 12:2001 13:10 15:23 16:3 17:8 20:25 24:1411 27:54 32:48 33:12 38:661 40:97 41:2115 44:3 46:1 47:25 52:6 55:6 56:2 57:24 58:715 59:527 60:431 61:1101 62:1034 63:1992 64:3855 65:2369 66:4162 67:1817 68:1059 69:2807 70:709 71:238 72:1832 73:2 74:2269 75:247 76:307 77:844 78:621 79:411 80:980 81:786 82:460 83:444 84:703 85:1044 86:452 87:697 88:325 89:1553 90:87 91:2732 92:474 93:1110 94:1400 95:587 96:245 97:307 98:549 99:26 109:461 110:330 111:508 112:257 113:281 114:392 115:598 116:1028 117:636 118:428 119:922 120:150 121:788 122:1438 123:881 124:1107 125:1298 128:211 129:207 130:196 131:563 132:246 133:17 134:196 135:44 136:227 137:172 138:253 139:92 140:487 141:136 142:361 143:380 144:468 145:52 146:428 147:168 148:586 149:321 150:151 151:169 152:263 153:168 154:2 155:325 156:184 157:324 158:107 159:368 160:313 161:204 162:269 163:165 164:409 165:531 166:504 167:399 168:802 169:160 170:700 171:50 172:1 173:673 174:657 175:76 178:69 180:444 182:43 183:251 184:36 186:363 187:308 188:1280 189:756 190:3657 192:5737 193:4675 194:3353 195:2758 196:1138 197:1 198:3573 199:3423 200:5331 201:1510 202:7984 203:8280 204:4055 205:2350 206:2545 207:3031 208:3929 209:3475 210:2511 211:1239 212:1725 213:1654 214:657 215:65 216:4556 217:1540 218:503 219:384 220:1100 221:396 222:312 End of report From joelja at bogus.com Fri Apr 30 13:23:28 2010 From: joelja at bogus.com (joel jaeggli) Date: Fri, 30 Apr 2010 11:23:28 -0700 Subject: Connectivity to an IPv6-only site In-Reply-To: References: <4BD1432F.4070406@ibctech.ca> <4BD14DDA.4010505@cox.net> <4BD159C1.2090307@ibctech.ca> <538D27E2-4771-4420-821D-BA8879B6822A@delong.com> <5598.1272031635@localhost> <201004231645.o3NGj5e5066388@drugs.dv.isc.org> <14793.1272042510@localhost> <4BD35F5B.8060904@brightok.net> <4BD5A473.9050309@sprunk.org> Message-ID: <4BDB2020.9040508@bogus.com> On 4/26/2010 8:07 AM, Christopher Morrow wrote: > On Mon, Apr 26, 2010 at 10:34 AM, Stephen Sprunk wrote: > >> Don't forget the hotspot vendor that returns an address of 0.0.0.1 for >> every A query if you have previously done an AAAA query for the same >> name (and timed out). That's a fun one. > > so... aside from the every 3 months bitching on this list (and some on > v6ops maybe) about these sorts of things, what's happening to > tell/educate/warn/notice the hotspot-vendors that this sort of > practice (along with 'everything is at 1.1.1.1!') is just a bad plan? > How can users, even more advanced users, tell a hotspot vendor in a > meaningful way that their 'solution' is broken? Years ago I talked to a startup's funders about the fact that they had made a design decision to build hardcoded unassigned /8s into a captive portal and mobility gateway. We didn't buy their product, they changed it, company folded. The most meaningful thing one can do is vote with your wallet. > -chris > From cidr-report at potaroo.net Fri Apr 30 17:00:04 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 Apr 2010 22:00:04 GMT Subject: BGP Update Report Message-ID: <201004302200.o3UM04Vb022369@wattle.apnic.net> BGP Update Report Interval: 22-Apr-10 -to- 29-Apr-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS35805 29526 2.2% 47.9 -- UTG-AS United Telecom AS 2 - AS17672 21731 1.6% 835.8 -- CHINATELECOM-HE-AS-AP asn for Hebei Provincial Net of CT 3 - AS9829 19342 1.5% 21.6 -- BSNL-NIB National Internet Backbone 4 - AS2018 19175 1.5% 88.4 -- TENET-1 5 - AS30890 15316 1.2% 36.0 -- EVOLVA Evolva Telecom s.r.l. 6 - AS38494 14916 1.1% 3729.0 -- BBGISA-AS-ID-AP PT. Bakrie & Brothers, Tbk 7 - AS22300 14653 1.1% 4884.3 -- WIKIA - Wikia, Inc. 8 - AS23700 13773 1.1% 31.4 -- BM-AS-ID PT. Broadband Multimedia, Tbk 9 - AS24560 13328 1.0% 15.0 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 10 - AS8452 12561 1.0% 12.0 -- TEDATA TEDATA 11 - AS28477 11673 0.9% 1297.0 -- Universidad Autonoma del Esstado de Morelos 12 - AS4795 9791 0.8% 40.1 -- INDOSATM2-ID INDOSATM2 ASN 13 - AS9498 9475 0.7% 13.9 -- BBIL-AP BHARTI Airtel Ltd. 14 - AS22047 8711 0.7% 40.5 -- VTR BANDA ANCHA S.A. 15 - AS7018 8662 0.7% 13.4 -- ATT-INTERNET4 - AT&T WorldNet Services 16 - AS12479 8631 0.7% 454.3 -- UNI2-AS Uni2 - Lince telecomunicaciones 17 - AS26025 8454 0.6% 8454.0 -- COC - City of Calgary 18 - AS16569 8355 0.6% 8355.0 -- ASN-CITY-OF-CALGARY - City of Calgary 19 - AS25620 7362 0.6% 43.6 -- COTAS LTDA. 20 - AS36992 7033 0.5% 11.3 -- ETISALAT-MISR TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS26025 8454 0.6% 8454.0 -- COC - City of Calgary 2 - AS16569 8355 0.6% 8355.0 -- ASN-CITY-OF-CALGARY - City of Calgary 3 - AS50531 5707 0.4% 5707.0 -- FAST-L-AS1 Limited Liabilily Company "FastLine" 4 - AS8588 5638 0.4% 5638.0 -- JD_ABRA_EU-AS Abra S.A. 5 - AS49121 5530 0.4% 5530.0 -- ACADEMY-AS PE Pavlovskaya Natalia Leonidovna 6 - AS22300 14653 1.1% 4884.3 -- WIKIA - Wikia, Inc. 7 - AS38494 14916 1.1% 3729.0 -- BBGISA-AS-ID-AP PT. Bakrie & Brothers, Tbk 8 - AS48754 2223 0.2% 2223.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 9 - AS19171 1657 0.1% 1657.0 -- STARGATE-VAN - Stargate Connections Inc. 10 - AS28477 11673 0.9% 1297.0 -- Universidad Autonoma del Esstado de Morelos 11 - AS8100 3814 0.3% 1271.3 -- IPTELLIGENT - IPTelligent LLC 12 - AS9814 3223 0.2% 1074.3 -- FIBRLINK Beijing FibrLINK Networks Co.,Ltd. 13 - AS30341 2064 0.2% 1032.0 -- SCTA-ASN - South Central Telephone Association 14 - AS45670 900 0.1% 900.0 -- SOFTCRYLICNET1-IN #160,North Usman Road, Third Floor 15 - AS17672 21731 1.6% 835.8 -- CHINATELECOM-HE-AS-AP asn for Hebei Provincial Net of CT 16 - AS28671 760 0.1% 760.0 -- Konecta Telecomunica??es Ltda 17 - AS28052 756 0.1% 756.0 -- Arte Radiotelevisivo Argentino 18 - AS26598 4079 0.3% 582.7 -- Its Brasil Tecnologia 19 - AS50139 576 0.0% 576.0 -- E-ARENA National association of research scientific and educational electronic infrastructures "E-ARENA" 20 - AS5429 559 0.0% 559.0 -- IIP-NET-AS5429 South Moscow Backbone Network TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 200.13.36.0/24 11633 0.8% AS28477 -- Universidad Autonoma del Esstado de Morelos 2 - 208.98.231.0/24 8454 0.6% AS26025 -- COC - City of Calgary 3 - 208.98.230.0/24 8355 0.6% AS16569 -- ASN-CITY-OF-CALGARY - City of Calgary 4 - 216.83.57.0/24 7327 0.5% AS22300 -- WIKIA - Wikia, Inc. 5 - 216.83.58.0/24 7325 0.5% AS22300 -- WIKIA - Wikia, Inc. 6 - 193.232.102.0/23 5707 0.4% AS50531 -- FAST-L-AS1 Limited Liabilily Company "FastLine" 7 - 91.208.133.0/24 5638 0.4% AS8588 -- JD_ABRA_EU-AS Abra S.A. 8 - 91.212.142.0/24 5530 0.4% AS49121 -- ACADEMY-AS PE Pavlovskaya Natalia Leonidovna 9 - 219.148.144.0/20 5410 0.4% AS17672 -- CHINATELECOM-HE-AS-AP asn for Hebei Provincial Net of CT 10 - 222.223.0.0/16 5410 0.4% AS17672 -- CHINATELECOM-HE-AS-AP asn for Hebei Provincial Net of CT 11 - 222.222.0.0/16 5408 0.4% AS17672 -- CHINATELECOM-HE-AS-AP asn for Hebei Provincial Net of CT 12 - 219.148.128.0/20 5406 0.4% AS17672 -- CHINATELECOM-HE-AS-AP asn for Hebei Provincial Net of CT 13 - 96.47.228.0/23 3806 0.3% AS8100 -- IPTELLIGENT - IPTelligent LLC 14 - 123.176.127.0/24 3745 0.3% AS38494 -- BBGISA-AS-ID-AP PT. Bakrie & Brothers, Tbk 15 - 123.176.120.0/24 3745 0.3% AS38494 -- BBGISA-AS-ID-AP PT. Bakrie & Brothers, Tbk 16 - 123.176.121.0/24 3714 0.3% AS38494 -- BBGISA-AS-ID-AP PT. Bakrie & Brothers, Tbk 17 - 123.176.122.0/24 3712 0.3% AS38494 -- BBGISA-AS-ID-AP PT. Bakrie & Brothers, Tbk 18 - 211.160.176.0/22 3202 0.2% AS9814 -- FIBRLINK Beijing FibrLINK Networks Co.,Ltd. 19 - 206.184.16.0/24 2839 0.2% AS174 -- COGENT Cogent/PSI 20 - 85.60.194.0/23 2757 0.2% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 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 Apr 30 17:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 Apr 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201004302200.o3UM007Y022359@wattle.apnic.net> This report has been generated at Fri Apr 30 21:11:43 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 23-04-10 321746 198312 24-04-10 321566 198048 25-04-10 321224 198152 26-04-10 321310 198243 27-04-10 321604 199156 28-04-10 321906 199541 29-04-10 322244 198768 30-04-10 322501 198956 AS Summary 34286 Number of ASes in routing system 14600 Number of ASes announcing only one prefix 4427 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 97310816 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'). --- 30Apr10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 322774 198900 123874 38.4% All ASes AS6389 3976 298 3678 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4427 1383 3044 68.8% TWTC - tw telecom holdings, inc. AS4766 1847 494 1353 73.3% KIXS-AS-KR Korea Telecom AS4755 1292 203 1089 84.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1148 76 1072 93.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS17488 1313 279 1034 78.8% HATHWAY-NET-AP Hathway IP Over Cable Internet AS7545 1176 235 941 80.0% TPG-INTERNET-AP TPG Internet Pty Ltd AS18566 1059 159 900 85.0% COVAD - Covad Communications Co. AS6478 1212 334 878 72.4% ATT-INTERNET3 - AT&T WorldNet Services AS10620 1014 159 855 84.3% Telmex Colombia S.A. AS8151 1547 694 853 55.1% Uninet S.A. de C.V. AS19262 1091 248 843 77.3% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 1020 386 634 62.2% TEDATA TEDATA AS7303 719 112 607 84.4% Telecom Argentina S.A. AS1785 1785 1181 604 33.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS24560 888 288 600 67.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS28573 931 334 597 64.1% NET Servicos de Comunicao S.A. AS4804 678 84 594 87.6% MPX-AS Microplex PTY LTD AS4808 843 255 588 69.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS17908 636 52 584 91.8% TCISL Tata Communications AS7018 1556 989 567 36.4% ATT-INTERNET4 - AT&T WorldNet Services AS18101 659 113 546 82.9% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS5668 833 306 527 63.3% AS-5668 - CenturyTel Internet Holdings, Inc. AS3356 1214 703 511 42.1% LEVEL3 Level 3 Communications AS4780 670 172 498 74.3% SEEDNET Digital United Inc. AS17676 569 78 491 86.3% GIGAINFRA Softbank BB Corp. AS9443 555 74 481 86.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS35805 617 146 471 76.3% UTG-AS United Telecom AS AS7011 1120 673 447 39.9% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS7738 477 30 447 93.7% Telecomunicacoes da Bahia S.A. Total 36872 10538 26334 71.4% Top 30 total Possible Bogus Routes 14.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 41.190.66.0/24 AS37039 41.202.96.0/19 AS29571 CITelecom-AS 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 AS26452 BRING-AS - BringCom, Inc. 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.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales Telesat S.A. 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 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 78.41.80.0/24 AS29158 DE-IP69 Tux-Service 78.41.81.0/24 AS29158 DE-IP69 Tux-Service 78.41.82.0/24 AS29158 DE-IP69 Tux-Service 78.41.83.0/24 AS29158 DE-IP69 Tux-Service 78.41.84.0/24 AS29158 DE-IP69 Tux-Service 78.41.86.0/24 AS29158 DE-IP69 Tux-Service 78.41.87.0/24 AS29158 DE-IP69 Tux-Service 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 110.34.40.0/22 AS24399 ABN-PEERING-AS-AP Asia Broadcast Networks Peering 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. 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 119.42.144.0/21 AS45753 NETSEC-HK Unit 1205-1207 119.42.144.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.145.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.146.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.147.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.148.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.149.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.150.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.42.151.0/24 AS45753 NETSEC-HK Unit 1205-1207 119.160.200.0/23 AS45122 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 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 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.45.0/24 AS2905 TICSA-ASN 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.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS 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.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 AS33052 VZUNET - Verizon Data Services 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.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 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 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.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - 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.52.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company 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.128.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 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.89.8.0/22 AS6648 BAYAN-TELECOMMUNICATIONS Bayan Telecommunications, Inc. 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.166.166.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 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.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 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.66.152.0/24 AS18499 208.66.153.0/24 AS18499 208.66.154.0/24 AS18499 208.66.155.0/24 AS18499 208.66.156.0/24 AS18499 208.66.157.0/24 AS18499 208.66.158.0/24 AS18499 208.66.159.0/24 AS18499 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.177.160.0/24 AS18499 209.177.161.0/24 AS18499 209.177.162.0/24 AS18499 209.177.163.0/24 AS18499 209.177.164.0/24 AS18499 209.177.165.0/24 AS18499 209.177.166.0/24 AS18499 209.177.167.0/24 AS18499 209.177.168.0/24 AS18499 209.177.169.0/24 AS18499 209.177.170.0/24 AS18499 209.177.171.0/24 AS18499 209.177.172.0/24 AS18499 209.177.173.0/24 AS18499 209.177.174.0/24 AS18499 209.177.175.0/24 AS18499 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.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, 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 223.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 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 nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Apr 30 19:45:14 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 1 May 2010 10:15:14 +0930 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100420145332.58995.qmail@joyce.lan> <20100427173622.GA24745@chilli.nosignal.org> <4BD72386.6010303@matthew.at> <19110.1272392139@localhost> <20861.1272394046@localhost> <26157.1272400265@localhost> <6109E1B3-E845-4111-966A-0613338D6719@delong.com> Message-ID: <20100501101514.02440cbc@opy.nosense.org> On Thu, 29 Apr 2010 08:22:47 -0700 Bill Stewart wrote: > On Tue, Apr 27, 2010 at 3:24 PM, Owen DeLong wrote: > >> Here's an exercise. ?Wipe a PC. ?Put it on that cable modem with no firewall. ?Install XP on it. ?See if you can get any service packs installed before the box is infected. > > 1. ? ? ?Yes, I can. ?I simply didn't put an IPv4 address on it. ;-) > > 2. ? ? ?I wouldn't hold XP up as the gold standard of hosts here. > > One of my coworkers was IPv6ing his home network. He had to turn off > the Windows firewall on the machine with the IPv6 tunnel for a couple > of minutes to install some stubborn software. Then he had to reimage > the box because it was pwned, and he's pretty sure that the infection > came in over the IPv6 tunnel, not the hardware-firewalled IPv4. > Your friend should learn about causation verses correlation http://en.wikipedia.org/wiki/Correlation_does_not_imply_causation Every noticed how people who have car accidents got out of bed that morning? > -- > ---- > Thanks; Bill > > Note that this isn't my regular email account - It's still experimental so far. > And Google probably logs and indexes everything you send it. > From drc at virtualized.org Fri Apr 30 20:26:01 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 30 Apr 2010 18:26:01 -0700 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <4BD9A5E7.1090904@telcodata.us> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72D1E.60506@otd.com> <20100428230704.4119ebd3@opy.nosense.org> <4BD857E9.2010407@matthew.at> <20100429065912.2f478885@opy.nosense.org> <01F57362-8092-48CB-8336-15B9CC1713C2@virtualized.org> <4BD9A5E7.1090904@telcodata.us> Message-ID: <6C8CF96D-4CEC-400F-A5C7-8671AFA1272E@virtualized.org> Paul, On Apr 29, 2010, at 8:29 AM, Paul Timmins wrote: > If you change ISPs, send out an RA with the new addresses, wait a bit, then send out an RA with lifetime 0 on the old address. Even if this works (and I know a lot of applications that use the socket() API that effectively cache the address returned by DNS for the lifetime of the application), how does this help situations where IPv6 address literals are specified in configuration files, e.g., resolv.conf, glue for authoritative DNS servers, firewalls/filters, network management systems, etc.? See sections 5 and 7 of http://www.rfc-editor.org/internet-drafts/draft-carpenter-renum-needs-work-05.txt The point here is that if there is a non-zero cost associated with renumbering, there will be non-zero incentive to deploy technologies such as NATv6 to reduce that cost. Some folks have made the argument that for sites large enough for the cost of renumbering to be significant, they should be able to justify provider independent space and be willing to accept the administrative and financial cost. While this may be the case (I have some doubts that many of the folks using PA space now will be all that interested in dealing with the RIR system, but I may be biased), it does raise concerns about routing system growth and forces ISPs to be willing to accept long IPv6 prefixes from end users (which some ISPs have already said they won't do). Regards, -drc From owen at delong.com Fri Apr 30 21:04:10 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 30 Apr 2010 19:04:10 -0700 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <6C8CF96D-4CEC-400F-A5C7-8671AFA1272E@virtualized.org> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72D1E.60506@otd.com> <20100428230704.4119ebd3@opy.nosense.org> <4BD857E9.2010407@matthew.at> <20100429065912.2f478885@opy.nosense.org> <01F57362-8092-48CB-8336-15B9CC1713C2@virtualized.org> <4BD9A5E7.1090904@telcodata.us> <6C8CF96D-4CEC-400F-A5C7-8671AFA1272E@virtualized.org> Message-ID: On Apr 30, 2010, at 6:26 PM, David Conrad wrote: > Paul, > > On Apr 29, 2010, at 8:29 AM, Paul Timmins wrote: >> If you change ISPs, send out an RA with the new addresses, wait a bit, then send out an RA with lifetime 0 on the old address. > > Even if this works (and I know a lot of applications that use the socket() API that effectively cache the address returned by DNS for the lifetime of the application), how does this help situations where IPv6 address literals are specified in configuration files, e.g., resolv.conf, glue for authoritative DNS servers, firewalls/filters, network management systems, etc.? See sections 5 and 7 of http://www.rfc-editor.org/internet-drafts/draft-carpenter-renum-needs-work-05.txt > Ideally, in the vast majority of cases, resolv.conf is populated by dhcpv6 or it's successor. It is actually possible (although I agree questionable practice) to have your NS glue records updated dynamically. Firewalls and NMS can usually be done by copying the existing rulesets and doing a global S&R on the affected prefix. It's not like a v4 renumbering. You'll still be dealing with a 1:1 replacement of the prefix and the suffixes don't need to change. IPv6 also has the convenient concept of preferred and valid lifetimes on addresses facilitating a convenient overlap period while both prefixes still work, but, new flows should be universally originated from the specified prefix. This makes it easier to identify hosts in need of manual intervention by monitoring for traffic sourced from the incorrect prefix. > The point here is that if there is a non-zero cost associated with renumbering, there will be non-zero incentive to deploy technologies such as NATv6 to reduce that cost. Some folks have made the argument that for sites large enough for the cost of renumbering to be significant, they should be able to justify provider independent space and be willing to accept the administrative and financial cost. While this may be the case (I have some doubts that many of the folks using PA space now will be all that interested in dealing with the RIR system, but I may be biased), it does raise concerns about routing system growth and forces ISPs to be willing to accept long IPv6 prefixes from end users (which some ISPs have already said they won't do). > There is a non-zero cost associated with renumbering. However, it is much closer to zero than in IPv4. There is also a non-zero cost to NAT. Unfortunately, the costs of NAT are more on the toxic polluter basis, where you must pay your own tab for renumbering. As such, NAT in IPv6 will probably be as popular as SPAM is in IPv4, to about the same level of detriment. Owen From paul at telcodata.us Fri Apr 30 21:55:26 2010 From: paul at telcodata.us (Paul Timmins) Date: Fri, 30 Apr 2010 22:55:26 -0400 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: <6C8CF96D-4CEC-400F-A5C7-8671AFA1272E@virtualized.org> References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72D1E.60506@otd.com> <20100428230704.4119ebd3@opy.nosense.org> <4BD857E9.2010407@matthew.at> <20100429065912.2f478885@opy.nosense.org> <01F57362-8092-48CB-8336-15B9CC1713C2@virtualized.org> <4BD9A5E7.1090904@telcodata.us> <6C8CF96D-4CEC-400F-A5C7-8671AFA1272E@virtualized.org> Message-ID: <4BDB981E.2060700@telcodata.us> David Conrad wrote: > Paul, > > On Apr 29, 2010, at 8:29 AM, Paul Timmins wrote: > >> If you change ISPs, send out an RA with the new addresses, wait a bit, then send out an RA with lifetime 0 on the old address. >> > > Even if this works (and I know a lot of applications that use the socket() API that effectively cache the address returned by DNS for the lifetime of the application), how does this help situations where IPv6 address literals are specified in configuration files, e.g., resolv.conf, glue for authoritative DNS servers, firewalls/filters, network management systems, etc.? See sections 5 and 7 of http://www.rfc-editor.org/internet-drafts/draft-carpenter-renum-needs-work-05.txt > > The point here is that if there is a non-zero cost associated with renumbering, there will be non-zero incentive to deploy technologies such as NATv6 to reduce that cost. Some folks have made the argument that for sites large enough for the cost of renumbering to be significant, they should be able to justify provider independent space and be willing to accept the administrative and financial cost. While this may be the case (I have some doubts that many of the folks using PA space now will be all that interested in dealing with the RIR system, but I may be biased), it does raise concerns about routing system growth and forces ISPs to be willing to accept long IPv6 prefixes from end users (which some ISPs have already said they won't do). > Put your recursors, network management systems, fileservers, etc on ULA addresses like I was talking about earlier. Then you don't have to renumber those. So the only change you should have to make is a firewall change. Imagine a world with RFC-1918 and public ip space safely overlayed. For anything you hardcode somewhere, unless it has to be publically reachable, use ULA addresses and don't ever change them. You could even choose to not have public IP space on your servers by removing autoconf, though you could have public space on them so they can apply updates, and simply block any inbound access to those statefully with a firewall to prevent any outside risk. -Paul From drc at virtualized.org Fri Apr 30 23:05:36 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 30 Apr 2010 21:05:36 -0700 Subject: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough? In-Reply-To: References: <20100420145332.58995.qmail@joyce.lan> <07459A5F-F87C-4D18-9E01-B6C990772327@delong.com> <20100427173622.GA24745@chilli.nosignal.org> <4BD72D1E.60506@otd.com> <20100428230704.4119ebd3@opy.nosense.org> <4BD857E9.2010407@matthew.at> <20100429065912.2f478885@opy.nosense.org> <01F57362-8092-48CB-8336-15B9CC1713C2@virtualized.org> <4BD9A5E7.1090904@telcodata.us> <6C8CF96D-4CEC-400F-A5C7-8671AFA1272E@virtualized.org> Message-ID: Owen, On Apr 30, 2010, at 7:04 PM, Owen DeLong wrote: > Ideally, in the vast majority of cases, resolv.conf is populated by dhcpv6 or it's successor. :-). I haven't been following the religious war against DHCPv6 -- is it now acceptable to get DNS information via DHCPv6? I note that MacOSX still doesn't appear to support DHCPv6. Does Win7? > IPv6 also has the convenient concept of preferred and valid lifetimes on addresses facilitating a convenient overlap period while both prefixes still work, but, new flows should be universally originated from the specified prefix. I'm aware of this. It would be interesting to see how many applications actually take advantage of this (rant about the socket API model deleted). > There is a non-zero cost associated with renumbering. However, it is much closer to zero than in IPv4. I agree that it can or at least has the promise to be. > There is also a non-zero cost to NAT. Yes. > Unfortunately, the costs of NAT are more on the toxic polluter basis, where you must pay your own tab for renumbering. End users must pay the cost of renumbering in both cases. With NAT, renumbering is done on the NAT box. Without NAT, renumbering must be done within the entire network. NAT can have an additional initial capital cost (although most CPE support NATv4 at no additional cost) and can have a potentially non-obvious additional opex cost associated with debugging network problems, application support, etc. In the end, it would be nice if it was a simple business decision. In reality, I suspect most folks getting IPv6 prefixes from their ISP will follow the same model they use with IPv4 because that's what they know and it works for them. Hopefully, we'll see. Regards, -drc From robert at grid.chu.edu.tw Sat Apr 24 13:32:08 2010 From: robert at grid.chu.edu.tw (Robert C. Hsu) Date: Sun, 25 Apr 2010 02:32:08 +0800 Subject: Call for Papers - IEEE GLOBECOM 2010 Workshop on Web and Pervasive Security (WPS 2010, 6 - 10 December 2010, Miami, USA) Message-ID: <201004241832.o3OIW87t019832@grid.chu.edu.tw> ============================================================ ** Apologies if you receive multiple copies of this CFP. ** ============================================================ Dear Colleagues: Please disseminate this message in your networks / subscribed lists. We also invite you to contribute a paper to this conference. ************************************************************* IEEE GLOBECOM 2010 Workshop on Web and Pervasive Security WPS'10 (Miami, USA, 6-10 December 2010) http://grid.chu.edu.tw/wps2010/ ************************************************************* ------------------------------- 1. Introduction 2. Topics 3. Important dates 4. Paper format & submission 5. Organizing Committee 6. History of WPS ------------------------------- ================= 1. Introduction ================= Web and Pervasive Environments (WPE) are emerging rapidly as an exciting new paradigm including ubiquitous, web, grid, ubiquitous and peer-to-peer computing to provide computing and communication services any time and anywhere. In order to realize their advantages, it requires the security services and Applications to be suitable for WPE. If they are realized, a user will be able to remotely access and control all information and web appliances in the workplace as well as at home and office, easily and conveniently use various services to enable working at home, remote education, remote diagnosis, virtual shopping, network gaming, and high quality VOD with no limitations on space and time. WPS2010 is a successor of the 1st International Workshop on Application and Security service in Web and pervAsive eNvirionments (ASWAN-07, HuangShan, China, June, 2007), the 2nd International Workshop on Web and Pervasive Security (WPS-08, Hong Kong, March, 2008) and the 3rd International Workshop on Web and Pervasive Security (WPS-09, Galveston, Texas, March, 2009) WPS2010 workshop is intended to foster the dissemination of state-of-the-art research in the area of secure WPE including security models, security systems, application services and novel security applications associated with its utilization. Also, it offers the possibility to discuss protocols and protocol characteristics with those people that are using them for solving their scientific problems. We plan to publish high quality papers, which cover the various web and security issues and practical applications in WPE. =========== 2. Topics =========== Topics of interest include, but are not limited to: * Security web-based collaboration applications and services * Model for secure web services * Wireless sensor networks / RFID application and security for WPE * Intelligent multimedia security services for WPE * Key management and authentication in WPE * Network security issues and protocols in WPE * Access control in WPE * Privacy Protection in WPE * Cryptographic algorithms for WPE * Data privacy and trustiness for WPE * Forensics Issue for WPE * Privacy and anonymity for WPE * Security in P2P networks and Grid computing in WPE * Trust management in WPE * Commercial and industrial applications for WPE =================== 3. Important Dates =================== Paper Submission: July 2, 2010 Decision notification: August 13, 2010 Camera-ready and registration due: August 31, 2010 ============================== 4. Paper format & submission ============================== Papers must be submitted electronically in Adobe PDF format to the submission system. http://edas.info/N8718 Papers must have authors' affiliation and contact information on the first page. Papers must be unpublished and not being considered elsewhere for publication. In particular, papers submitted to WPS2010 must not be concurrently submitted to GLOBECOM in identical or modified form. Prospective authors are encouraged to submit an IEEE conference style paper up to 5 pages (including all text, figures, and references) through EDAS submission system http://edas.info/N8718 One additional page will be allowed with additional publication fee. An accepted paper must be registered before the registration deadline. An accepted paper must be presented at the workshop. Failure to register before the deadline will result in automatic withdrawal of the paper from the workshop proceedings and the program. All accepted and presented papers will be included in the IEEE GLOBECOM proceedings and IEEE digital library. GLOBECOM has the right to remove an accepted and registered but not presented paper from the IEEE digital library. ======================= 5. Organizing Committee ======================= Workshop Co-Chairs: Jong Hyuk Park, Seoul National University of Technology, Korea Robert C. H. Hsu, Chung Hua University, Taiwan Mieso Denko, University of GUELPH, Canada, denko at cis.uoguelph.ca International Advisory Committee Mohammad S. Obaidat (Monmouth University, USA) Laurence T. Yang (St. Francis Xavier University, Canada) Jianhua Ma (Hosei University, Japan) Jiannong Cao (Hong Kong Polytechnic University, Hong Kong) Weijia Jia (City University of Hong Kong, Hong Kong SAR, China) Program committee ?? Alexander Lazovik (INRIA, France) ?? Andrew Kusiak (The University of Iowa, USA) ?? Anna Cinzia Squicciarini (Purdue University, USA) ?? Antonio Coronato (ICAR-CNR, Italy) ?? Apostolos N. Papadopoulos (Aristotle University, Greece) ?? Avinash Srinivasan (Florida Atlantic University, USA) ?? Cho-Li Wang (The University of Hong Kong, China) ?? Claudio Sartori (Universita' di Bologna, Italy) ?? Do van Thanh (NTNU, Norway) ?? Fangguo Zhang (Sun Yat-sen University, China) ?? Gianluca Moro (University of Bologna, Italy) ?? Hiroshi yoshiura (University of Electro-Communications, Japan) ?? Huafei Zhu (Institute for Infocomm Research, A-star, Singapore) ?? Javier Garcia Villalba (Complutense University of Madrid, Spain) ?? Jongsung Kim, Kyungnam University, Korea ?? Jean-Henry Morin (Korea University, KOREA) ?? Jean-Marc Seigneur (University of Geneva, Switzerland) ?? Jian Yang (Macquarie University, Australia) ?? Katsaros Dimitrios (Aristotle University, Greece) ?? Ligang He (University of Warwick, UK) ?? Marco Aiello (University of Groningen, the Netherlands) ?? Massimo Esposito (ICARCNR, Italy) ?? Paolo Bellavista (University of Bologna, Italy) ?? Qi Shi (Liverpool John Moores University, UK) ?? Raymond Li (CISCO, USA) ?? Rodrigo Fernandes de Mello (University of Sao Paulo, Brazil) ?? Tetsu Iwata (Nagoya University, Japan) ?? Tore Jonvik (Oslo Unversity College, Norway) ?? TRAORE Jacques RD-MAPS-CAE (France Telecom R&D, France) ?? Trevor Jim (AT&T Labs Research, USA) ?? Xiaofeng Meng (Renmin University of China, China) ?? Yufeng Wang (Nanjing University of Posts and Telecommuni-cations, China) =================== 6. History of WPS =================== The 1st International Workshop on Application and Security service in Web and Pervasive Environments (ASWAN-07, HuangShan, China, June, 2007) http://www.chu.edu.tw/~aswan07/ The 2nd International Workshop on Web and Pervasive Security (WPS-08, Hong Kong, March, 2008) http://www.sersc.org/WPS2008/ The 3rd International Workshop on Web and Pervasive Security (WPS-09, Galveston, Texas, USA, March, 2009) http://grid.chu.edu.tw/wps2009/ ================================================== For additional information, please send e-mail to Prof. Robert C. H. Hsu (chh at chu.edu.tw) or Prof. Jong Hyuk Park (parkjonghyuk1 at hotmail.com) ==================================================