Protocols for Testing Intrusion Detection?
I'm looking for recommended protocols to use for testing intrusion detection and maybe also firewall logging. Basically I need some kind of protocol that it's ok to discard traffic for in a production network, so I can be sure that the various systems that should be detecting it and generating alarms are up and running. Is there already a standard I should be using? (This doesn't seem to quite match RFC2544.) I'm thinking about things like - TCP and UDP echo protocol - is this sufficiently deprecated that it won't be missed, or are there applications still using it? - Higher-numbered TCP protocol, such as 31337, which appears to have no official current use, and unofficially is for Back Orifice. - http:80 from a well-known test address, such as evil.example.com (probably need both RFC1918 and public IP addresses, so it's somewhat site-dependent. Should I be using 192.0.2.0/24 or 198.18.0.0/15 as long as I'm careful not to leak them out to the real internet?) - Is there any application that can actually set the RFC3514 Evil Bit? -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
On Tue, Nov 29, 2011 at 3:46 AM, Dmitry Cherkasov doctor...@gmail.com wrote: Currently I research on IPv6 provisioning systems and I need to decide whether the ability to use longer then /64 prefixes should be supported in them or not. If we restrict user to using /64 per network we need to have convincing reasons for this. Best practice and common sense stand for using /64 but this may be not sufficient for some people. There's a very strong case to be made for Be conservative in what you generate and liberal in what you accept here. One of the primary reasons for using /64 everywhere is the fear that somebody somewhere in your network built some piece of equipment or software that you're using that doesn't let you use prefixes longer than /64, and you don't want to have to find them all the hard way. Please don't be that piece of software! My organization uses longer addresses for equipment we control because we have different ops folks handling routers, firewalls, load balancers, miscellaneous control boxes, etc. and it lets them keep track of who's in charge of what address space without requiring a /47 out of the customer's /48 network just for the management subnets for the equipment we manage for them. We've also found that in production networks, /126 usually is too long a prefix, because often we'll be doing high availability configurations with HSRP/VRRP, so it's cleaner to be /124 or shorter (plus nibble-aligned or byte-aligned address blocks make report generation less ugly.) -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
On Wed, Nov 30, 2011 at 1:18 PM, Mark Blackman m...@exonetric.com wrote: ... and I'm not sure why SLAAC wanted more than 48 bits. One reason IPv6 addresses are 128 bits long instead of 40, 48, 64 or 80 is because converting from IPv4 to IPv6 is really painful and we don't want to ever have to do it again in the future. Eventually we will run out of 48-bit MAC addresses, because we'll run out of 24-bit manufacturer ID parts, and we'll transition to EUI-64 or something like it. It will be ugly and painful, and it will break many things, and if we used 48-bit MAC addresses for SLAAC, it would break IPv6 as well. Using EUI-64 instead of MAC means that all the breakage will live at Layer 2. It does break some things in IPv6 - we've spent a couple of years arguing about whether ISPs should give customers /48, /56, /60, or /64, instead of having the nice clean 64 bits for the network provider, 16 bits for subnet, 48 for MAC that the earlier proposals adapted from Netware IPX, but that would probably have gotten us in trouble also. I can't explain why EUI-64 picked its particular ugly way to convert 48-bit MACs to 64-bit, but I won't rant about that here. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Looking for a Tier 1 ISP Mentor for career advice.
Another really useful skill is knowing what it looks like to be a customer / end user of one of those networks. Sure, it's fun to crank obscure BGP load-balancing techniques, but you also need to know where the industry as a whole is going technically and business-wise. Tier 1s sell to Tier 2s, big enterprises, content providers, and consumers, and they all need different things. How much is computing staying under the control of the companies that use it vs. migrating out to cloud providers and Something-As-A-Service? What happens to networks as broadcast TV gets replaced by consumers downloading content? What do you know about end-users from hanging out with other college students that the old folks running the ISPs don't understand yet? Some parts of the Tier 1 business depend on providing access to large end user locations, which is more of an issue of zoning, real estate, and geography; other parts want to scale to hundreds of thousands of smaller connections. When I had a job that was more in the field than my current position, something I saw happening all the time was that people who worked for a customer would get a job at one of their vendors, or people who worked for a vendor would get a job at one of their customers. In bigger companies, that may also be internal end users and service organizations in addition to external customers. It's a big way that you build the relationships that lead to getting jobs and to finding people to hire. And yeah, sometimes it means that you need to go learn technologies like Active Directory, either because you might end up working for an enterprise instead of a service provider, or just because your customers will be using it and you need to know how it'll affect their network needs. In addition to learning scripting languages, you really need to learn some basic VMware, because operationally just about everything that doesn't need custom silicon is migrating onto virtual machines. You don't need to have a whole VMsphere N+1 system at home, but at least install the free versions on a PC, build some VMs and some virtual switches and let them talk to each other, do some firewalls, etc. The certification business is useful for a couple of things - giving you some direction in your learning process, telling people who are trying to hire new coworkers something about your skills, and getting your resume past the HR department so the people who actually understand what the jobs are can see it (or at least keeping them from getting in the way if you've made the connections through people you know instead of through HR.)
Re: Outgoing SMTP Servers
On Mon, Oct 31, 2011 at 6:23 AM, Brian Johnson bjohn...@drtel.com wrote: For clarity it's really bad for ISPs to block ports other than 25 for the purposes of mail flow control... correct? Yes, correct. If you're using another mail submission port, you're connecting to a mail service that has the responsibility not to let spam escape, and your ISP has done its job of stopping point-source pollution. BillI've got a strong preference for ISPs to run a BillBlock-25-by-default/Enable-when-asked. [...] This is, of course, exactly why this blocking is done. It looks like you're missing half my point, which is the Enable-when-asked part. There are users who are perfectly legitimately running MTAs at home, whether for reliability or privacy (e.g. so they can run SMTP-over-TLS end-to-end) or just simplicity, and ISPs shouldn't be blocking them (unless they're spammers, of course.) My take on this is that it IS best practice to have users use the submission port (587) for mail submission from the MUA to an MTA. If you're running an MTA service, then yes. If you're running a transport service, then not necessarily. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: NANOGers home data centers - What's in your closet?
Friends of mine recently bought a large traditionally-designed house. The former servant's quarters are now the server room.
Re: So... is it time to do IPv6 day monthy yet?
So should monthly IPv6 day be the same week as Microsoft Patch Tuesday? :-)
Re: 365x24x7
On Sun, Apr 17, 2011 at 8:00 AM, Jay Ashworth j...@baylink.com wrote: The TV master control facility in which I'm working presently does it by doing overlapping 10 hour shifts; it takes 10 people to have 2 on-shift at all times. You work 6 hours with one person, and 4 with the other. My brother-in-law once had a job tending a TV relay station; the shift was drive up the mountain, work 48 hours, drive back, but unless something was broken he only had to read meters every three hours and could nap in between. Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: 365x24x7
Variable scheduling of staff is often deemed more fair, but I think it makes things less stable. People are constantly having to change their life. Rotating shifts between daytime and nighttime is a horrible thing to do to your workers, both for their health and their attention span. Full-time night work isn't great, but rotating work is even worse. Apes are generally diurnal, not nocturnal or crepuscular. Shuffling who has to work which days is annoying enough. Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Using IPv6 with prefixes shorter than a /64 on a LAN
On 2/1/11, Chuck Anderson c...@wpi.edu wrote: What would your recommended solution be then for disconnected networks? Every home user and enterprise user requests GUA directly from their RIR/NIR/LIR at a cost of hunderds of dollars per year or more? A typical home user will have a /56 of GUA, or maybe a /48 with some ISPs. Anybody who knows enough to figure out how to set a ULA can figure out a /64 from their GUA space that's not being auto-assigned by one of their various home routers. So if that's the way you want to do things, it won't cost you or your ISP anything. If your ISP is only assigning you a /64 of GUA, that's another story. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Connectivity status for Egypt
On 1/28/11, andrew.wallace andrew.wall...@rocketmail.com wrote: We should be asking the Egyptians to stagger the return of services so that infrastructure isn't affected, when connectivity is deemed to be allowed to come back online. Well, yeah, it has to be done carefully, otherwise the first guy to turn on an E1 line that announces routes for the entire country is going to have his router overheat and the blue smoke get out If we're lucky, the Army won't damage too much as they either win or lose. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Ipv6 for the content provider
On 1/26/11, Owen DeLong o...@delong.com wrote: And if your servers behind the LB aren't prepared for it, you lose a LOT of logging data, geolocation capabilities, and some other things if you go that route. Of course, anybody expecting a current IPv4 geolocation service to provide accurate information over IPv6 over the next couple of years is wildly optimistic (with all due respect to people in that business, but just sayin' good luck with that...) Maybe you'll get some consistency about which continent they're on based on the RIR the addresses came from, but even that's probably dodgy if the address belongs to Hurricane Electric or Sixxs or some other popular tunnel broker, and maybe you'll get some consistency on is it the same /56 as last time?, and maybe some of them will start doing tricks like putting web bugs for ipv4tracker.geolocator-example.com and ipv6tracker.geolocator-example.com on the same web pages to try to start building correlation information, and if course you need your application that uses the information to speak IPv6 and handle 128-bit records and not just 32-bit. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: DSL options in NYC for OOB access
On 1/24/11, Andy Ashley li...@nexus6.co.za wrote: Im looking for a little advice about DSL circuits in New York, specifically at 111 8th Ave. Going to locate a console server there for out-of-band serial management. The router will need connectivity for remote telnet/ssh access from the NOC. How much bandwidth do you need? Is a dialup modem fast enough? Traditional phone lines often give you a much different set of reliability issues and common-mode failures than Internet connectivity, which is good. I've been very happy with Pushkablue's dialup out-of-band boxes, which give you a serial console and power supply relays. Similarly, if wireless works in the part of the building you're in, and if the building allows you to have equipment that transmits radio signals (some colos don't), that's another option, again, because it's going to have different failures than the equipment you're controlling. I searched some obvious providers but dont really want to deal with a huge company (Verizon, Qwest, ?) if it can be avoided. Are there smaller/independent companies out there offering this sort of thing? I dont know much about the US DSL market, so any hints are welcome. If you don't know the market, then there's a whole lot of value in dealing with the two or three dominant players for that city, or the two dozen huge companies for the country, as opposed to the hundreds or thousands of small players. (Admittedly, having dealt with ZA's dominant player in a previous job, I'd rather use anybody else also...) -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: The scale of streaming video on the Internet.
On Fri, Dec 3, 2010 at 9:35 AM, Leo Bicknell bickn...@ufp.org wrote: - Ratio needs to be dropped from all peering policies. It made sense back when the traffic was two people e-mailing each other. It was a measure of equal value. However the net has evolved. In the face of streaming audio and video, or rich multimedia web sites Content-User will always be wildly out of ratio. It has moved from a useful measure, to an excuse to make Content pay in all circumstances. I think that's the key point here - ratios make sense when similar types of carriers are peering with each other, whether that's traditional Tier 1s or small carriers or whatever; they don't make sense when an eyeball network is connecting to a content-provider network. The eyeball network can argue that it's doing all the work, because the content provider is handing it 99% of the bits, but the content provider can argue that the eyeball network makes its money delivering bits asymmetrically to its end users, and they'll be really annoyed if they can't get the content they want. There are still balance-of-power issues - Comcast won't get much complaint if it drops traffic from Podunk Obscure Hosting Services, so they can bully Podunk into paying them, while Podunk Rural Wireless Services will get lots of complaint from its users if it drops traffic from YouTube. Level 3 is functioning not only as a transport provider for smaller content providers, but also as an aggregated negotiation service, though in this case the content provider, Netflix, is big enough to matter. (Some years ago, when they were DVDs by mail only, it was estimated that they had a bandwidth about 1/3 that of the total (US?) internet, just with slightly higher latency) (or significantly lower latency, if you were still on modems.) -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Online games stealing your bandwidth
On Sat, Sep 25, 2010 at 5:17 PM, Matthew Walster matt...@walster.org wrote: Plenty of people sell p2p caches but they all work using magic, smoke and mirrors. Somehow that seems appropriate for gaming networks; maybe add some swords or old Gandalf boxes. In general distributing gaming software isn't going to have a big impact on your traffic levels - the average user will upload at most about as many megabytes as he downloaded (though obviously some will upload much more and some much less), and if the P2P is implemented well the uploads will mostly go to other customers of the same ISP, reducing the amount that comes through their peering point. And it'll all be a lot less than somebody pirating movies, because the game doesn't get DVD-sized updates multiple times a day or even a month. If you're running a satellite ISP, you probably care a lot more about upstream bandwidth, but it'll be much faster for one satellite user to get bits from Anchorage or even Seattle than to get it from another user two satellite hops away, especially if your uplinks are smaller than your downlinks, so if the P2P is implemented well (no idea if it is), you'll get very little uploading. (Does it save you money to get a WoW subscription for a box that sits in a server rack at your hub site with nobody actually playing it, to further reduce your bandwidth needs? Maybe.) -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
On Sat, Sep 18, 2010 at 2:34 AM, JC Dill jcdill.li...@gmail.com wrote: Jack Bates wrote: And yet, I'm pretty sure there are providers that have different pipes for business than they do for consumer, and probably riding some of the same physical medium. This creates saturated and unsaturated pipes, which is just as bad or worse than using QOS. The reason I'm pretty sure about it, is business circuits generally are guaranteed, while consumer are not. I'm pretty sure you are mistaken. The reason is, it's adding an additional layer of complexity inside the network for no good reason. Real ISPs have all sorts of different layers of complexity, for lots of reasons ranging from equipment performance to Layer 8 differences to mergersacquisitions to willingness-to-pay to marketing objectives to historical accident. An ISP that's also a telco-ish carrier will typically offer multiple services at Layer 1, Layer 2, MPLS, Layer 3, and other variants on transport. Copper's different economically from fiber pairs, SONET, Ethernet, CWDM, DWDM, some services get multiplexed by using bundles of copper or fiber, some get multiplexed by using different kinds of wavelength or time division, some get shared by packet-switching, some packet switches are smarter on some transport media than on others, some services will use edge equipment from Brand C or J or A because they were the first or cheapest to get Feature X when it was needed, some services are designed for Layer 9 problems like different taxes on different kinds of access services. An ISP that isn't an end-to-end vertically integrated provider will be buying stuff from other carriers that influences what services they offer, but the integrated providers often do that too. There are some kinds of service where the difference between business-grade and consumer-grade is mainly about options for types of billing, or for guarantees around how fast they'll get a truck to your place to fix things - that's especially common in access networks. Most consumer home internet service is running on DSL or cable modems, and that's going to behave differently than T1 access or 10 Gbps WAN-PHY or LAN-PHY gear. Different priced services may get connected to circuits or boxes that have different amounts of oversubscription. Different protocols give you different feedback mechanisms that affect performance. Or higher-priced services may have measuring mechanisms built in to them or bolted alongside, so that performance problems can generate a trouble ticket faster or get a refund on the bill, and come with a sales person who doesn't really understand how they work but is being pressured to provide 110% uptime. A common design these days is to have an MPLS backbone supporting multiple services including private networks and public internet, and the private networks may get dedicated chunks of the trunking, or may get higher MPLS prioritization. But separately from that, the IP edges may support Diffserv, and maybe the backbones do or maybe they don't, or maybe some parts of the trunking are only accessible to the higher-priority services. And maybe the diffserv gets implemented differently on the equipment that's used for different transmission media, or maybe the box that has the better port density doesn't have as many queues as the lower-density box, or maybe it's different between different port cards with the same vendor. A very common design is that businesses can get diffserv (or the MPLS equivalents) on end-to-end services provided by ISP X, but the peering arrangements with ISP Y don't pass diffserv bits, or pass it but ignore it, or use different sets of bits. It's very frustrating to me as a consumer, because what I'd really like would be for the main bottleneck point (my downstream connection at home) to either respect the diffserv bits set by the senders, or else to give UDP higher priority and TCP lower priority, and put Bittorrent and its ilk in a scavenger class, so VOIP and real-time video work regardless of my web activity and the web gets more priority than BitTorrent. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
On Tue, Sep 14, 2010 at 6:51 PM, Steven Bellovin s...@cs.columbia.edu wrote: No, they bought ATT, which [...] But yes, SBC is the controlling piece of the new ATT. As for the two /8s -- not quite. Back in the 1980s, ATT got 12/8. We soon learned that we couldn't make good use of it, since multiple levels of subnetting didn't exist. We offered it back to Postel in exchange for 135/8 -- i.e., the equivalent in class B space -- but Postel said to keep 12/8 since no one else could use it, either. This was all long before addresses were tight. When ATT decided to go into the ISP business, circa 1995, 12/8 was still lying around, unused except for a security experiment I was running.* However, a good chunk of 135/8 went to Lucent (now Alcatel-Lucent) in 1996, though I don't know how much. Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
Sorry, fat-fingered something when I was trying to edit. On Fri, Sep 17, 2010 at 2:12 PM, Bill Stewart nonobvi...@gmail.com wrote: On Tue, Sep 14, 2010 at 6:51 PM, Steven Bellovin s...@cs.columbia.edu wrote: No, they bought ATT, which [...] But yes, SBC is the controlling piece of the new ATT. Most of the wide-area ISP network is the old ATT, while much of the consumer broadband grew out of the SBC DSL side. As for the two /8s -- not quite. Back in the 1980s, ATT got 12/8. We soon learned that we couldn't make good use of it, since multiple levels of subnetting didn't exist. We offered it back to Postel in exchange for 135/8 -- i.e., the equivalent in class B space -- but Postel said to keep 12/8 since no one else could use it, either. This was all long before addresses were tight. When ATT decided to go into the ISP business, circa 1995, 12/8 was still lying around, unused except for a security experiment I was running.* However, a good chunk of 135/8 went to Lucent (now Alcatel-Lucent) in 1996, though I don't know how much. The ATT bits kept some fraction of 135; I don't know how much without dredging through ARIN Whois, but at least 135.63/16 is on my desktop. If I remember correctly, which is unlikely at this point, 12/8 was the Murray Hill Cray's Hyperchannel network, which I'd heard didn't know how to do subnetting except on classful boundaries, so it could happily handle 16M hosts on its Class A, and in fact only had two or three. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Advice regarding Cisco/Juniper/HP
On Thu, Jun 17, 2010 at 6:52 AM, James Smith ja...@jamesstewartsmith.com wrote: we're in the process of building a DR site. Assume for purposes of discussion that all the vendors have equivalent quality equipment with approximately equivalent features. I can think of four occasions you'd need a DR center 1 - Practicing your disaster-recovery drills 2 - Testing out new configurations or equipment that you'll roll out to the main system 3 - When you're having a really bad day and need to switch over quickly 4 - When you're having a really really bad day due to common-mode failures of your main-system's vendor's equipment. Case 1 is fine. Case 2 may let you do proofs of concept, but if the DR isn't a close enough model of your real equipment, it's often not good enough Case 3 is the canonical time that you want your DR center to look as much like the real thing as possible, especially if you're trying to handle partial failures of the main system and not just smoking-hole-in-the-ground disasters. Case 4 is the canonical time you wish you'd ignored my advice for Cases 2 and 3, because your HP box has different bugs than your Cisco box. Depending on quite what you do and what your failure models are, you may be able to build parts of your DR center using other vendors' equipment, without too much risk of mismatched configurations, but in general you're going to need to buy a lot of parts for your DR center that are identical to the primary systems they're backing up. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Internationalized domain names in the root
I'm getting three different behaviours from Firefox - I have the page open in a tab. The tab header is in Arabic script. (And the page itself renders fine in Arabic.) - When I go to that tab, the main Firefox window title shows boxes (i.e. don't have the font for this.) - When I go to that tab, the Address Bar shows ugly punycode xn-format junk. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: any bring your own bandwidth IPv4 over IPv4 tunnel merchants?
On Mon, 3 May 2010 14:12:45 -0400 Bill Bogstad bogs...@pobox.com wrote: Like many people, I can't justify the expense of commercial IP connectivity for my residence. As a result, I deal with dynamic IP .. On Mon, May 3, 2010 at 11:27 AM, Gregory Edigarov g...@bestnet.kharkov.ua wrote: Holly shit... Where do you live? In Ukraine we have almost no difference (well it is different from one company to another) between commercial and residental setups. At least it is so with smaller providers like one I have at home and one I work for (they are two different companies). So it seems very very strange to me you need to justify anything with your network operator. In most of the US, the standard residential ISP service gives you - some amount of bandwidth, usually asynchronous - dynamic IP address (with static available for a higher price) - some service quality and repair speed guarantees - many ISPs, especially cable modem, have annoying policies that say you can't run a server at home. But many don't. - some ISPs are starting to get the idea tha Most of the ISPs that provide that kind of service offer business service using the residential technology - higher price - better service quality and repair speed guarantees - static IP addresses, and you can run a server -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Surcharge for providing Internet routes?
Back when I was on that side of the house, if you bought transit from 7018 and were managing your own routers, you got your choice of BGP or static, and BGP could have full routes, our-customer routes, default routes, and maybe some other variants. No charge for any of those options, but if you wanted full routes you'd need a hefty enough router, and if you thought you wanted full routes on your T1 line we'd offer you some hints about that not being a good idea. Other than that, full routes burned a bit of extra bandwidth, so if you had usage-based pricing that might have some minor effects. (If we were managing your routers, you usually weren't in the dual-homing business, or at least we'd be charging you more for a fatter router and managing the extra complexity of whatever you needed done locally, but all of that was just router management pricing, not network pricing.) -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
On Tue, Apr 27, 2010 at 3:24 PM, Owen DeLong o...@delong.com 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.
Re: DSL aggregation.... NO
On Thu, Apr 15, 2010 at 2:05 PM, Bill Lewis ble...@hottopic.com 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.
Re: Router for Metro Ethernet
On Tue, Apr 13, 2010 at 9:12 PM, Tony Varriale tvarri...@comcast.net wrote: From: Bill Stewart nonobvi...@gmail.com 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.
Re: Router for Metro Ethernet
On Mon, Apr 12, 2010 at 10:55 AM, Dylan Ebner dylan.eb...@crlmed.com 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.
Re: ARIN IP6 policy for those with legacy IP4 Space
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.
Re: ARIN IP6 policy for those with legacy IP4 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? 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.
Re: what about 48 bits?
On Mon, Apr 5, 2010 at 10:51 AM, Steven Bellovin s...@cs.columbia.edu wrote: On Apr 5, 2010, at 1:43 52PM, valdis.kletni...@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.
Re: Books for the NOC guys...
On Fri, Apr 2, 2010 at 8:36 AM, Eliot Lear l...@cisco.com 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.
Re: 100% want IPv6 - Was: New Linksys CPE, IPv6 ?
On Thu, Apr 1, 2010 at 5:00 AM, Joe Greco jgr...@ns.sol.net 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.
Re: IP4 Space
it seems to me that we'll have widespread ipv4 for +10 years at least, How many 10 year old pieces of kit do you have on your network? Ten years ago we were routing appletalk and IPX. Still doing that now? Ten years ago I was still telling a few customers that Novell Netware had supported TCP/IP since the early 90s and it was really time to shut off IPX, and the Appletalk users were at least running over IP, not LocalTalk, so I didn't have to care much, and the Windows people were probably already arguing about Active Directory and LDAP and whether to do DNS, DLSW was Not Dead Yet, and 1/3 of my X.25 customers acknowledged that it was way obsolete and time to join the 1990s (the other two were state governments who viewed it as Somebody Else's Emulation Problem.) The last time I was dealing with high-end Layer 1 access problems was a couple of years ago, but in addition to normal IPv4 and MPLS, I had customers running Fiber Channel and other SAN protocols on the WAN. There'll be enough IPv4 to keep antiques dealers in business for a while yet. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: IPv6 in Education Question
You're either going to have to sell them on future-proofing or We're sailing off the edge of the world in two years, there be dragons there, train your folks now. Remember that there are two IPv6 transitions - introducing IPv6 and forcing some people onto it - getting rid of IPv4 after IPv6 support is universal. Death of NAT NAT's not going away for a long time - IPv6 doesn't need it for address space conservation, and pretends not to need it very much for renumbering IPv6 to IPv6, but it's widely used as a firewall substitute and administrative convenience. The first IPv6 transition will eliminate some NAT in pure-v6 environments, so there will be applications that are no longer broken and can Just Work, but it'll also introduce several different flavors of IPv4-to-IPv6 NATs/tunnels/etc., so there are other applications that will get broken in new and creative ways. The second IPv6 transition may really finish eliminating NAT, but that won't be for *years*, and you'll need to get all your users deeply involved in IPv6 long before that. Other than networking research and networking-related training, there really aren't education-specific applications of IPv6; there are just sites that you can or can't reach with IPv4 or IPv6. Any big commercial sites will stay reachable with IPv4 for a long time, certainly until IPv6 has been well established for a couple of years, and while there may be new content that's IPv6 only after a while, commercial content sites are more likely to buy IPv4 space if they need it. And most educational sites big enough to be Really Cool already have enough IPv4 space to last a few years, though they may very well start adding IPv6 connectivity just like commercial sites will. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Network Naming Conventions
- Beers (the main server got to be anchor, which made our ex-Navy boss happy and seemed more professional than some others - Mountains, mostly volcanic - Psychoactive chemicals (the database is on speed, the development project's on prozac...) - Friends at Princeton used quarks (Up is down today.) and random names like 3bvax. - Classical composers - Tolkien characters (one of the reasons for DNS was that too many people wanted to name their machine frodo or mozart.)
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
Maybe I'm dense, but I don't see the problem. One of the great things about IPv6's address space being mindbogglingly large is that there's plenty of it to experiment with. If the ITU wants an RIR-sized block to do RIR-like work, so what? If they wanted a /2 or /4 I'd be concerned, or if there were many organizations out there that wanted RIR-sized chunks, but ITU's close enough to unique that they're not going to cause the space to run out. And sure, maybe they're sufficiently outdated and irrelevant that they could get by with a /16, but it might be interesting to have somebody assigning IPv6 addresses as :prefix:e164:host or whatever. (Admittedly, that made more sense back when e.164 addresses were 12 digits as opposed to the current 15.) -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Security Guideance
On Tue, Feb 23, 2010 at 11:46 AM, Paul Stewart pstew...@nexicomgroup.net wrote: The problem is that a user on this box appears to be launching high traffic DOS attacks from it towards other sites. These are UDP based floods that move around from time to time - most of these attacks only last a few minutes. Do the UDP floods have source-addresses that belong to your machine, or are they spoofed? Make sure you block that noise; depending on the applications the users think they've implemented, do you need to allow any outbound UDP other than 53? Can you move the users onto virtual machines instead of real ones? That can make it easier to isolate the problem users, or at least to cram an IDS in front of it. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: austin eats
On Tue, Feb 16, 2010 at 8:02 PM, Kevin Oberman ober...@es.net wrote: It's mostly the obvious places. Oddly, Fogo de Chao, a churrascaria that opened a year ago is missing from the list as is my personal By the way, Fogo de Chao is a very strange place to eat if you're a vegetarian. I once went to their Dallas instance with a group from my company and a customer, and the Indian guy on the customer's team and I sat across from each other while the waiters waved huge sticks of meat at the carnivores. Salad bar was exceptionally good, though. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Fiber Cut in CA?
On Tue, Feb 2, 2010 at 12:04 AM, char...@knownelement.com wrote: That is one long protect path. Yikes. There be mountains in the way, with deserts in between, and not a lot of people to justify diversity or railroads and highways to run it along. Not many carriers have more than one fiber route across Arizona and New Mexico, especially for the newer high-capacity fibers (i.e. built this millennium, after the financial excesses of the 90s.) I'm no longer current on what routes are being used by what carriers, but if you don't have two routes across northern Arizona ( I-10/I-40, with restoration routes like Barstow-LasVegas-Flagstaff-Phoenix), then the next alternative is Barstow-LasVegas-SaltLakeCity-Denver, at which point some carriers have routes down to Phoenix via Tucumcari or Amarillo, and the rest are going to go through Dallas, and anybody who doesn't have the LasVegas-SLC route is going to use Sacramento-SLC-Denver, possibly also including San Jose, depending on what routes they've got across California. So, yeah, instead of the nice short 2200-mile restoration routes you can use if SF-Seattle fails, cable cuts in the Southwest can be really long... -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Using /126 for IPv6 router links
On Wed, Jan 27, 2010 at 1:19 PM, Igor Gashinsky i...@gashinsky.net wrote: 1) ping-ponging of packets on Sonet/SDH links 2) ping sweep of death ... For most people, using /127's will be a lot operationaly easier then maintain those crazy ACLs, but, like I said before, YMMV.. I'm in the /112 camp - it's not going to be much worse for attack 2, and I've been dealing with a lot of IPv4 operational issues where you need subnets with enough addresses for VRRP/HSRP/NSRP/etc, equipment management addresses for devices that aren't the main address, byte-aligned database entries, monitoring boxes of various sorts, extra NATs for applications nobody told you about when you set things up, splitting subnets into smaller contiguous subnets because of equipment limitations or vendor compatibility problems with IPSEC tunnels, etc. And the other interesting address length proposal was 80 bits, typically imagined as 20 BCD digits, proposed by phone company types. 128 is better... -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: I don't need no stinking firewall!
On Wed, Jan 13, 2010 at 9:37 PM, Warren Kumari war...@kumari.net wrote: I can now place a checkbox in the Is there a firewall? column of the insert random acronym here audit. In most cases, you can check the same box if you use an appropriately designed stateless firewall instead of an inappropriate stateful firewall.(Not always, of course.) And it will keep out some fraction of noise and anklebiters, and optionally give you a place to hang limited intrusion detection, without providing an easy path for attackers to crash your connection. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Default Passwords for World Wide Packets/Lightning Edge Equipment
A password recovery method I've found very frustrating is to use the serial number or similar value that's on a label on the bottom of the equipment. It's just fine for desktop hardware - but for rack-mounted gear, it's not uncommon to find out that you need this information *after* somebody's racked and stacked the hardware, and therefore you either need to unscrew it (if it was screwed into the rack) or drag it out (if it wasn't screwed in for some reason like missing wing-brackets or 23-inch telco racks or random junk piled on top of it, etc.), and possibly uncable it as well, depending on how much slack is in the cabling, and you almost certainly want to power it down first, and you need to have enough flashlights and reading glasses to deal with reading the bottom of the equipment lying down on the floor of the data center. Yes, you *should* be able to find the serial number by looking in the accurate complete up-to-date spreadsheet of equipment inventory records, or at least the previous-user-printed Dymo-label on the front of the box. But if you had that quality of records, you probably wouldn't need to be running password recovery anyway. (Disclaimer: I'm currently working in a development lab, not operations, so ideally this doesn't reflect the state of our production data centers :-) Most of the time it doesn't reflect our lab either, but occasionally it does, and of course loaner equipment often arrives in random condition.
Re: DNS question, null MX records
On Tue, Dec 15, 2009 at 7:46 AM, Eric J Esslinger eesslin...@fpu-tn.com wrote: So in any case, due to customer privacy concerns we feel we can't do that. If you don't want to handle email for the long-obsolete customer accounts, but just don't want to send that mail to anybody else, it's pretty easy to run a teergrube or other tarpit system to trap any mail addressed to the A-record. These systems basically accept mail v.e..ysl.o...w...l..y so that spammers can waste their time talking to your tarpit instead of to somebody who cares, and so you can trap their IP addresses and potentially block them or use them to support your other spam-blockers if you want. You don't need a high-performance machine because all the users are spammers and you're *trying* to give them bad service. (Some variants, like LaBrea, are used for connection attempts to non-existent machines - they'll send a syn-ack so the attacker thinks he has a successful 3-way handshake, which slows down scanning attacks.) If you do want to accept mail for the long-obsolete customer accounts, so you can give them a proper human-readable rejection message, you may need to customize. It looks like Exim supports that, though I haven't tried it. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: SPF Configurations
On Sun, Dec 6, 2009 at 2:56 PM, Sean Donelan s...@donelan.com wrote: In particular, what anti-forgery/security controls should network operators implement and check; and what anti-forgery/security controls should network operators not implement or check? Depends a bit on whether you're counting inbound-mail-service operators as network operators. As an end user who doesn't have an account at Bank of America, I'd be happy if bankofamerica.com used SPF records so my mail system could discard forged spam from them; that's much different than the kind of forgery prevention I want for my actual bank. (And obviously SPF isn't going to stop mail from bank0vamer1ca.cm etc., but it can cut down some of the noise and leave the rest for Spamassassin.) -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: What DNS Is Not
Hi, Paul - I share your dislike of DNS services that break the DNS model for profit in ways that break applications. For instance, returning the IP address of your company's port-80 web server instead of NXDOMAIN not only breaks non-port-80-http applications, it also breaks the behaviour that browsers such as IE and Firefox expect, which is that if a domain isn't found, they'll do something that the user chooses, such as sending another query to the user's favorite search engine. There is one special case for which I don't mind having DNS servers lie about query results, which is the phishing/malware protection service. In that case, the DNS response is redirecting you to the IP address of a server that'll tell you You really didn't want to visit PayPa11.com - it's a fake or You really didn't want to visit dgfdsgsdfgdfgsdfgsfd.example.ru - it's malware. It's technically broken, but you really _didn't_ want to go there anyway. It's a bit friendlier to administrators and security people if the response page gives you the IP address that the query would have otherwise returned, though obviously you don't want it to be a clickable hyperlink. However, I disagree with your objections to CDN, and load balancers in general - returning the address of the server that example.com thinks will give you the best performance is reasonable. (I'll leave the question of whether DNS queries are any good at determining that to the vendors.) Maintaining a cachable ns.example.com record in the process is friendly to everybody; maintaining cachable A records is less important. If reality is changing rapidly, then the directory that points to the reality can reasonably change also. On Mon, Nov 9, 2009 at 12:00 PM, Paul Vixie vi...@isc.org wrote: i loved the henry ford analogy -- but i think henry ford would have said that the automatic transmission was a huge step forward since he wanted everybody to have a car. i can't think of anything that's happened in the automobile market that henry ford wouldn't've wished he'd thought of. Well, there's the built-in GPS navigation system that tells you to go drive off the dock into the water, because it wasn't smart enough to know that the route the map database showed in dotted lines was a ferryboat... -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Congress may require ISPs to block fraud sites H.R.3817
If you're a consumer broadband provider, and you use a DNS blackhole list so that any of your subscribers who tries to reach bigbank1.fakebanks.example.com gets redirected to fakebankwebsitelist.sipc.gov, you might be able to claim that you complied with the law, though the law's aggressive enough that it could be argued otherwise. If you're a transit ISP providing upstream bandwidth the the broadband provider, and some packets are addressed to 1.1.1.257, which is the IP address of a hosting site in Elbonia that carries bigbank1.fakebanks.example.com and innocent.bystander.example.com, the fact that the broadband ISP was using a DNS blackhole list doesn't protect you, because you're still routing packets to 1.1.0.0/16. You could set up a /32 route to send that traffic to null0, censoring innocent.bystander.example.com, or you could get fancy and route it to some squid proxy that cleans up the traffic. But of course the phisher could be using fast-flux, so 5 minutes later that trick no longer works, and by tomorrow the 100,000 phishing websites on the list have added 1,000,000 routes to your peering routers... Not pleasant, but you don't really have much alternative. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: ISP customer assignments
On Mon, Oct 19, 2009 at 7:07 PM, Nathan Ward na...@daork.net wrote: On 20/10/2009, at 3:02 PM, Bill Stewart wrote: plus want the ability to take their address space with them when they change ISPs (because there are too many devices and applications that insist on having hard-coded IP addresses instead of using DNS, and because DNS tends to get cached more often than you'd sometimes like. That's why we have Unique Local Addresses. This is the opposite problem - ULAs are for internal devices, and what businesses often want is globally routable non-provider-owned public addresses. If you've got a VPN tunnel device, too often the remote end will want to contact you at some numerical IPv4 address and isn't smart enough to query DNS to get it. And even though most enterprises these days only use registered addresses outside the firewall and not inside the firewall, it's still a pain to have to renumber everything and wait for everybody's DNS caches to expire, so if you're using Provider-independent IP addresses, it's much easier to tell your ISP Sorry, ISP A, I've got a better price from ISP B and I'll move all my stuff if you don't beat their price. (Of course, customers like that are often telling ISP B You'll have to be X% cheaper/faster/somethinger than ISP A or I'll just stay where I am and telling ISP C My main choices are ISP A and ISP B but I'd take a lowball quote very seriously...) -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: ISP customer assignments
If you've got an addressing system with enough bits that you don't have to start stealing them, it makes sense to pick some boundary length between our-problem : their-problem 128 bits is long enough, and changing protocols is nasty enough, that it should let you Never Have To Do It Again. Originally with IPv6, the boundary was a nice round 64 bits, with the ISP on the network side and MAC48-based autoaddressing on the user side, with the user side looking suspiciously similar to Novell Netware and giving ~64K subnets, and this was back before DHCP had taken over the world and it was expected that all kinds of weird little toasters would be using IPv6. But some relatively sensible people proposed using the (ugly) EUI-64 64-bit MAC, because they Never Wanted To Have To Do This Again Either. And unfortunately, because it's a good enough idea to be worth accepting, it pushes the network boundary somewhat to the left, because it's pretty obvious that an average household may have multiple devices that want to autoconfigure themselves, so you probably will end up needing multiple subnets. And unfortunately, there's no obviously correct boundary, and no particular reason for all ISPs to use the same boundary, so there are endless arguments about it on NANOG and elsewhere. In general, /48's big enough for most large complex businesses (except ISPs), and /60's more than big enough for a household and for many small businesses, but we've got enough bits that it's worth using octet-aligned addresses, so /56 is the magic number for them, except at ISPs that simply don't want to bother giving out anything except /48s. There may be special cases for assigning /64s to end users, such as IPv6-equipped cell phones, but that's a matter for specialized carriers to provide, or for internal network managers at enterprises. And if you're big enough to get Provider Independent Address Space and an AS#, you're big enough to have a /48 of your own. Now, IPv6 was supposed to allow the development of other indistinguishable-from-magically advanced technology, such as getting rid of the growth of routing tables by convincing everybody to be happy with hierarchically assigned provider-aligned address space, and unfortunately that hasn't matched the needs of businesses, which need multihoming for reliability (so they'll be non-provider-aligned for at least n-1 of their ISPs), plus want the ability to take their address space with them when they change ISPs (because there are too many devices and applications that insist on having hard-coded IP addresses instead of using DNS, and because DNS tends to get cached more often than you'd sometimes like. So that problem shows no sign of going away (in spite of shim6..)
Re: FCCs RFC for the Definition of Broadband
It's not a technical question, it's a political one, so feel free to squelch this for off-topicness if you want. Technically, broadband is faster than narrowband, and beyond that it's fast enough for what you're trying to sell; tell me what you're trying to sell and I'll tell you how fast a connection you need. ulliIf you're trying to sell email, VOIP, and lightly-graphical web browsing, 64kbps is enough, and 128 is better. liIf you're trying to sell wireless data excluding laptop tethering, that's also fast enough for anything except maybe uploading hi-res camera video. liIf you're trying to sell talking-heads video conferencing, 128's enough but 384's better. liIf you're trying to sell internet radio, somewhere around 300 is probably enough. liIf you're trying to sell online gaming, you'll need to find a WoW addict; I gather latency's a bit more of an issue than bandwidth for most people. liIf you're trying to sell home web servers - oh wait, they're not! - 100-300k's usually enough, unless you get slashdotted, in which case you need 50-100Mbps for a couple of hours. liIf you're trying to sell Youtube-quality video, 1 Mbps is enough, 3 Mbps is better. liIf you're trying to sell television replacement, 10M's about enough for one HD channel, 20's better, but the real question is what kind of multicast upstream infrastructure you're using to manage the number of channels you're selling, and whether you're price-competitive with cable, satellite, or radio broadcast, and how well you get along with your city and state regulators who'd like a piece of the action. li If what you're trying to sell is the relevance of the FCC to the Democratic political machines, the answer is measured in TV-hours, newspaper-inches, and letters to Congresscritters, which isn't my problem. /ul
Re: Packet loss statistics
On Thu, May 28, 2009 at 9:55 AM, Ric Messier kil...@washere.com wrote: Here is the Qwest link mentioned, by the way, in case anyone else is interested. http://stat.qwest.net/statqwest/perfRptIndex.jsp The equivalent ATT network performance portal page is http://www.att.com/ipnetwork and various pages linked to it. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Where to buy Internet IP addresses
You have RFC3041 and similar techniques, stateless autoconfig, and a variety of other general things that make it really awful for the default ethernet network size to be something besides a /64. ... I would definitely prefer to see a /56, or maybe a /48, handed out today. When I first started looking at IPv6, the bottom 64 bits were divided into the bottom 48 bits for a MAC address and 16 more bits that could either be zeros or could be used as a subnet number in roughly Novell Netware style (modulo a local/global bit if you needed one). If you wanted to assign addresses instead of autoconfiguring, that was ok too, but it was obvious how autoconfig would work. It was simple, clean, and flexible, and obviously intended that an ISP would hand most customers a /64, which could easily handle an entire building or medium-complexity campus. Then I ignored those bits for a decade or more, because nobody's IPv6 was much more than experimental. When I came back, I found this ugly EUI-64 thing instead, so not only was autoconfiguration much uglier, but you needed a /56 instead of a /64 if you were going to subnet. Does anybody know why anybody thought it was a good idea to put the extra bits in the middle, or for IPv6 to adopt 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.
Re: Broadband Subscriber Management
On Fri, Apr 24, 2009 at 7:27 AM, Frank Bulk frnk...@iname.com wrote: So what were you doing than, RFC 1483? Back when I worked with ATT's business-market DSL folks, used RFC 1483 rather than annoy customers with PPPoE, and we provided ATM to lots of CLECs that did the same. (I don't know what the current ILEC consumer offers use.) I currently use sonic.net DSL at home, which is using ATT (SBC/PacBell) LEC DSL underneath, and their installation instructions were to discard the PPPoE driver disk that came with the LEC install kit; I'm about 95% sure it's RFC1483 also. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Dynamic IP log retention = 0?
On Fri, Mar 13, 2009 at 2:15 PM, valdis.kletni...@vt.edu wrote: After all, you didn't *really* care that the IP was assigned to a computer belonging to Herman Munster, 1313 Mockingbird Lane. What you actually *wanted* was for somebody (preferably Covad) to hand Herman a clue. Yeah. I miss the days that you could fix Covad problems by calling Brent, or by sending the attacker a Ping of Death :-) In practice, of course, the chances are extremely high that the attacker is a zombie pc whose owner is not aware that it's infected, and they really need their ISP to quarantine them somewhere until they can get it fixed. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Private use of non-RFC1918 IP space
On Sun, Feb 8, 2009 at 11:42 PM, Joel Jaeggli joe...@bogus.com wrote: FD00::/8 ula-l rfc 4139 s/4139/4193/ -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: [Update] Re: New ISP to market, BCP 38, and new tactics
On Tue, Feb 3, 2009 at 5:43 PM, Steve Bertrand st...@ibctech.ca wrote: What I was hoping for (even though I'm testing something that I know won't work) is that I can break something so I could push v4 traffic over a v6-only core. Is there _any_ way to do this (other than NAT/tunnel etc)? If you can push v4 over it (other than through a NAT/tunnel/etc.), then it's not a v6-only core :-) The real question is whether you're going to route natively in v4, or do a v4-in-v6 tunnel of some sort, or a v4-in-Layer2-in-v6 tunnel of some sort, or do NAT, or use MPLS as a Layer 2ish core. If you're doing MPLS, you'll need to figure out if you can run _it_ with purely v6 gear supporting it, or whether you'll need to run v4 to make all of your MPLS vendors happy, but that doesn't need to be publicly routable v4 carrying the entire Internet's routing tables on it; you can leave the Internet inside a large MPLS VPN if you want. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: can I ask mtu question
Which standard are you referring to? AFAIK, nothing above 1500 is standardised I've had two different kinds of customer requests for jumbo frames - customers that want very large frames for performance reasons; Many ethernet switches support 9000 or more, some don't, and some technologies like ATM support ~4470. Sometimes the ability to provide them depends on tunnel modes. - customers that want frames that are at least ~1700-1800 bytes so that a few layers of IPSEC or VLAN headers or whatever won't break the 1500-byte packets inside 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.
Re: Which is more efficient?
On Wed, Jan 14, 2009 at 12:56 PM, Murphy, Jay, DOH jay.mur...@state.nm.us wrote: In your humble opinion, which transmission method is more efficient, packet or cell? ... Trying to make a decision on the transport mode for cost, delay, jitter, ROI, etcetera. It really depends on what your applications are. I've spent the last decade as the regional ATM specialist (among other things) for an international carrier, and since we can sell you koolaid in ATM, Frame, MPLS, VPLS, IPv4, and IPSEC flavors, I can be fairly neutral about technology recommendations for my customers. The most efficient transmission method is the one for which you know how to set up your router to match the way the carrier's network works, so you'll need to train your people. If that's ATM, you may need to do some ATM-specific things, and they're different for different carriers; if it's Ethernet, you'll need to decide how to handle access line failure detection. And the work you need to do is much different if the ATM/Frame/Ethernet is a Layer 2 end-to-end service or if it's an access line for a routed service such as MPLS. ATM can give you really good control over jitter, but only if you set it up correctly. Dedicated Ethernet access typically has lower jitter than shared switched Ethernet access, but it only comes in a couple of sizes and may cost more if that's bigger than what you need. As far as cost-effectiveness goes, ATM cells have about 10% overhead, but some carriers price their services to charge you for it and some don't, and they have different policies about bursting; what you really care about is what price they're going to charge you for the data circuits you need. Ethernet also has a lot of overhead, if you're carrying lots of small packets; it's very significant if you're carrying VOIP, and trivial on big file transfers. These days circuit costs have decreased enough that router costs can be a significant part of your total cost. ATM cards are traditionally expensive, but if you're buying a VLAN-based switched ethernet access service, ask your router vendor what size router you'll need to handle traffic shaping - even if the Ethernet is built-in, a large teal-colored box costs more than a medium box. My main concerns about ATM, other than whether it matches your applications, are whether it'll scale to the size you need, and how long you'll be able to get good router vendor support. I don't see Frame/ATM interworking going away as a method for handling lots of small endpoints like cash machines reliably, at least until there are good ways to manage thousands of IPSEC sessions, but it's not the technology you're going to want for OC48s. DSL is usually ATM underneath, but that may or may not be how you connect to your DSL carrier. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Ethical DDoS drone network
On Mon, Jan 5, 2009 at 4:11 PM, Roland Dobbins rdobb...@cisco.com wrote: In my experience, once one has an understanding of the performance envelopes and has built a lab which contains examples of the functional elements of the system (network infrastructure, servers, apps, databases, clients, et. al.), one can extrapolate pretty accurately well out to orders of magnitude. It's one of those things where the difference between theory and practice is smaller in theory than it is in practice, though... But yeah, sometimes things like load balancers fail, or routers run out of table space, or whatever. I've had enough enterprise customers worry about what will happen to their VPN sites if some neighborhood kid annoys his gamer buddies and gets a few Gbps of traffic to knock down their DSLAM and its upstream feeds or whatever. The problem is that many organizations don't do the above prior to freezing the design and initiating deployment. Back in the mid-90s I had one networking software development customer that had a room with 500 PCs on racks, and some switches that would let them dump groups of 50s of them together with whatever server they were testing. That was a lot more impressive back then when PCs were full-sized devices that needed keyboards and monitors (grouped on KVMs, at least), as opposed to being 1Us or blades or virtual machines. Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Estimate of satellite vs. Land-based traffic
At least in the US, satellite use is fairly limited compared to fiber and copper, mainly in the following areas - TV broadcast - Data and voice to remote areas (a few hundred Alaska villages, some connectivity up to oil drilling areas in Alaska, though there's also fiber, plus some Internet in non-wired parts of the US. I'm not aware of regular telco use of satellites for service in the middle 48 states. Is Alohanet or something like it still running in Hawaii?) - Some emergency backup applications such as restoration for carriers (redundant cables are nice, but you need access in multiple failure scenarios such as floods and earthquakes.) - Specialized enterprise applications (some years ago, VSAT was fairly common for credit-card support at gas stations, malls, etc. I know one grocery store chain that finally moved to terrestrial in the late 90s, forced by Microsoft application protocols that couldn't handle the VSAT latency.) -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: What to do when your ISP off-shores tech support
Assuming that what you're getting from Verizon is copper and not FIOS, there should be a number of small to medium-sized ISPs that will provide you with Layer 3 Internet Service using that copper. It will cost you a few dollars a month more, but not a lot more, and you'll not only have more chance of getting somebody with a clue to answer questions, but you'll be able to do things like running servers from home if you want. It looks like Sonic.net doesn't cover Long Beach, but Speakeasy does, and you should be able to find a range of other small clueful ISPs. The off-shore call-center business has changed a lot in the last decade; in addition to Bangalore undercutting the Nebraska and Utah call centers, there are cheaper places like the Phillipines undercutting Bangalore, and Canada's been trying to address unemployment in former fishing villages by promoting call centers (which has the advantage of good English), and VOIP has simplified work-at-home distributed call centers in the rural US. But still, if your company is outsourcing first-line support to script-readers, then they need to be good at recognizing when to get past the initial script and escalate to somebody with more training. On Thu, Dec 25, 2008 at 2:37 PM, Jay Hennigan j...@west.net wrote: The person wasn't capable of getting the hint when I asked after several minutes of frustration what the A in ATT stood for, and in fact claimed to have no idea. Actually, for the last N years, the A in ATT is just a letter; the company name stopped being an acronym for American Telephone Telegraph even before they were bought by the Company Formerly Known As SBC. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: an over-the-top data center
Data centers in used nuclear bunkers aren't new - www.thebunker.net has done that for a decade in the UK. They found that having a cool-looking site made it easy to sell to bankers who wanted reassurance about physical security, and at least with the computer technology of the time it was easy to do HVAC, since the place was naturally cold, and they had good redundant power grid connectivity to work with. As far as the risks of publishing the location of your data centers go, I've generally been on the pro-publishing side; real attackers would *never* think of looking for the large building downtown with no windows, or looking for a data center business named One Wilshire near Wilshire Blvd (:-) More seriously, though, many customers need physical diversity for their circuits, and while it's more reliable to get that from a single fiber carrier than try to get predictable diversity from multiple carriers, there's still a need to do some auditing. Of course, if you've got a bunker already, it's pretty cheap to get your CEO a monocle and a white cat, whereas if you're starting with the monocle and the cat, getting a bunker can be fairly expensive.
Re: ingress SMTP
Hi, Hobbit - we met back in the late 80s / early 90s at various New Jersey things such as Trenton Computer Fair, but you probably don't remember me; Tigger says hi as well... Be Liberal in what you accept, be conservative in what you send, and be really really clear in your error messages, except occasionally if you're lying to spammers. IMHO, selling somebody connectivity that blocks various ports isn't selling them Internet Service, it's selling them Walled Garden Couch-Potato Service. For many people that's ok, and if they're sending traffic on Port 25 it's only because some zombieware has taken over their PC, as opposed to because they're actually trying to send it. But the old PC on my desk upstairs has about 2500 times as much CPU and 500 times as much disk space as the Vaxen that I used to run email for a department of 30 people, and the network connection is about 300 times as fast, and there's no particular reason that it shouldn't have full end-to-end Internet presence like anybody's commercial mail server. That's different from 15 years ago when I only had dialup at home, because dialup wasn't really a full-time process, and sending mail was sufficiently unreliable that it made sense to run a dumb client at home that talked to a full-time smart host that knew how to queue messages and retry on failure. Blocking port 25 has become popular, not only with walled-garden connectivity services that are really scared of their customers running their own servers (e.g. most cable modem companies), but also with other ISPs that don't want to deal with the problems of having customers who are spamming (whether deliberate or zombified.) So anybody buying something lower-priced than a T1 typically needs to have a mail client or mail transfer agent that can use other ports, unless they want to trust their ISP's mail service or use webmail. And also obviously if you're running an outbound mail relay smarthost for your clients you need to accept mail from known people on the various authenticated ports in case they're stuck behind a randomly misbehaving ISP, and you should also support encrypted SMTP in general. In some sense, anything positive you an accomplish by blocking Port 25 you can also accomplish by leaving the port open and advertising the IP address on one of the dynamic / home broadband / etc. block lists, which leaves recipients free to whitelist or blacklist your users. And you can certainly provide better service to your customers by redirecting Port 25 connections to an SMTP server that returns 550 We block Port 25 - see www.example.net/faq/port25blocking or some similarly useful message as opposed to just dropping the packets. I've toned down my vehemence about the blocking issue a bit - there's enough zombieware out there that I don't object strongly to an ISP that has it blocked by default but makes it easy for humans to enable. -- Thanks; Bill Stewart Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: 240/4
On 10/16/07, Justin M. Streiner [EMAIL PROTECTED] wrote: The effort someone would spend figuring out if 204/4 is reachable and not-pain-inducing in their infrastructure is better spent figuring out how to make IPv6 work within their sphere of responsibilities. I agree. The current rate at which blocks of IPv4 space are being allocated to the RIRs suggests that releasing a chunk from, say, 240/5 or 248/5 for consumption gets you about 1 year, tops. A year is good. My recommendation would be to adamantly refuse to let the RIRs assign it for public space and insist that it's for experimental use only, even though these days the place for research is IPv6 or its interaction with IPv4, and maybe even put out some interesting but not actually useful piece of researchware such as RFC1149bis (homeland security emergency warning notification via location-agile mobile distribution of audio recordings using peer-to-peer avian carriers.) Then when we actually do run out of IPv4 space and major players start complaining that they're Just Not Ready for IPv6, because you know that's going to happen, have the RFC author grudgingly agree to release the space and retarget the research, giving the carriers and other players one more year to get serious. -- 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.
