Re: Choice of network space when numbering interfaces with IPv6 (IPv6 STANDARDS)
On Sat, Oct 16, 2010 at 6:26 PM, Kevin Oberman wrote: >> Date: Sun, 17 Oct 2010 00:40:41 +1030 >> From: Mark Smith >> >> On Sat, 16 Oct 2010 12:31:22 +0100 >> Randy Bush wrote: >> >> > http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt >> > >> >> Drafts are drafts, and nothing more, aren't they? > > Drafts are drafts. Even most RFCs are RFCs and nothing more. Only a > handful have ever been designated as "Standards". I hope this becomes > one of those in the hope it will be taken seriously. (It already is by > anyone with a large network running IPv6.) And none of the listed IETF "full standards" are IPv6 related. That seems a little bit odd to me given that everyone is supposed to have implemented them by now. Bill Bogstad
Re: Choice of network space when numbering interfaces with IPv6 (IPv6 STANDARDS)
On Sat, Oct 16, 2010 at 7:57 PM, Mark Smith wrote: > On Sat, 16 Oct 2010 19:52:31 -0400 > Bill Bogstad wrote: > >> On Sat, Oct 16, 2010 at 6:26 PM, Kevin Oberman wrote: >> >> Date: Sun, 17 Oct 2010 00:40:41 +1030 >> >> From: Mark Smith >> >> >> >> >> >> On Sat, 16 Oct 2010 12:31:22 +0100 >> >> Randy Bush wrote: >> >> >> >> > http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt >> >> > >> >> >> >> Drafts are drafts, and nothing more, aren't they? >> > >> > Drafts are drafts. Even most RFCs are RFCs and nothing more. Only a >> > handful have ever been designated as "Standards". I hope this becomes >> > one of those in the hope it will be taken seriously. (It already is by >> > anyone with a large network running IPv6.) >> >> And none of the listed IETF "full standards" are IPv6 related. That >> seems a little bit odd to me given that everyone is supposed to have >> implemented them by now. >> > > The IETF standards process is different to other standards > organisations - publication of an RFC doesn't make it a standard. It is > much more pragmatic, as operational history is also used as an input > into the decision. I read my first RFC sometime in 1984. I still find it odd that after something like a decade of development/operational history NONE of the IPv6 related RFCs have made it all the way to full standard status. This might be a minor point but I think that not making at least some of the base IPv6 RFCs full standards probably slowed down deployment. OTOH, now that people are convinced that they won't be able to get more IPv4 addresses in the near future; a possible perception that IPv6 was "experimental" may no longer matter... Bill Bogstad
Re: Over a decade of DDOS--any progress yet?
FYI, A single data point on current DDOS traffic levels. An Akamai press release says they handled DDOS attacks peaking at 14Gbps in the Nov. 30 to Dec 2nd time frame. http://finance.yahoo.com/news/Akamai-Shields-Leading-prnews-2768453391.html "The majority of attack traffic against the five retailers initiated from distributed IP addresses out of Thailand, Mexico, Philippines, and Brazil and reached peeks of up to 14 Gbps, with some websites experiencing up to 10,000 times above normal daily traffic. " Bill Bogstad
Re: NIST IPv6 document
On Thu, Jan 6, 2011 at 5:54 AM, Jeff Wheeler wrote: > On Thu, Jan 6, 2011 at 5:20 AM, Owen DeLong wrote: >>> You must also realize that the stateful firewall has the same problems >> Uh, not exactly... > > Of course it does. The stateful firewall must either 1) be vulnerable > to the same form of NDP attack; or 2) have a list of allocated v6 > addresses on the LAN. The reason is simple; a "stateful firewall" is > no more able to store a 2**64 table than is a "router." Calling it > something different doesn't change the math. If you choose to solve > the problem by disabling NDP or allowing NS only for a list of "valid" > addresses on the subnet, this can be done by a stateless router just > like on a stateful firewall. > >> Uh, no it doesn't. It just needs a list of the hosts which are permitted >> to receive inbound connections from the outside. That's the whole > > This solution falls apart as soon as there is a compromised host on > the LAN, in which case the firewall (or router) NDP table can again be > filled completely by that compromised/malicious host. In addition, > the "stateful firewall," by virtue of having connection state, does > not solve the inbound NDP attack issue. The list of hosts which can > result in an NDP NS is whats causes this, and such a list may be > present in a stateless router; but in both cases, it needs to be > configured. Err, almost everything falls apart once you allow a compromised/malicious host on the local LAN. If you have circumstances where this may happen on anything like a regular basis, you really need all kinds of control/monitoring of traffic that go far beyond any local NDP overflow issues. Bill Bogstad
Fw: new message
Hey! New message, please read <http://battersandco.com/moved.php?vw3> Bill Bogstad
Re: Rate of growth on IPv6 not fast enough?
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.
Re: Rate of growth on IPv6 not fast enough?
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
Re: Rate of growth on IPv6 not fast enough?
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
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
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
any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants?
Like many people, I can't justify the expense of "commercial" IP connectivity for my residence. As a result, I deal with dynamic IP addresses; dns issues; and limitations on the services that I can host at my residence. It just struck me that in the same way that IPv6 connectivity can be done via tunneling over IPv4 (Hurricane Electric, etc.), that static IPv4 addressability could be offered in a similar fashion. Some my question is: Does anyone offer (probably bandwidth restricted) IPv4 over IPv4 tunneling (with static IPs) commercially? I realize that making use of such a service MIGHT violate Terms of Service agreements, but that is going to vary from provider to provider and doesn't make offering such a service inherently wrong. Other possible reasons such services might be desired include wanting access to Internet services which are regionally restricted. (Again TOS violation possibilities MAY or MAY NOT apply.) In the (very?) long term, IPv4 over IPv6 tunneling could end up being one way that organizations can get IPv4 connectivity when the default changes from only-IPv4 to only-IPv6. (Yeah, I know that day may never come...) Thanks, Bill Bogstad
Re: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants?
On Mon, May 3, 2010 at 2:27 PM, Gregory Edigarov wrote: > On Mon, 3 May 2010 14:12:45 -0400 > 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. North America. Specifically the Boston metro area of the USA. It's fairly common here to put all kinds of type of service restrictions on residential Internet connectivity. From what I've read on NANOG over the years, I thought this was common practice worldwide, but it sounds like that might not be the case in the Ukraine. Thanks, Bill Bogstad
Re: Vyatta as a BRAS
On Thu, Jul 15, 2010 at 11:35 AM, Dobbins, Roland wrote: > > On Jul 15, 2010, at 10:23 PM, Joe Greco wrote: > >> For example, for a provider whose entire upstream capacity is 1Gbps, I have >> a hard time seeing how a Linux- or FreeBSD-based box could credibly be >> claimed not to be a suitable edge router. > > Because it can and will be whacked quite easily by anyone who packets it, > either deliberately or inadvertently. I've seen too many software-based > routers fall over with far, far less traffic than 1gb/sec to think otherwise. Since you've seen "many software-based routers fall over", can you provide details on specific hardware/software/traffic patterns/rates where you've seen these failures? From what I can tell, software based routers are almost universally used in SOHO environments; so it would be nice to know when such solutions are no longer viable in your experience. Thanks, Bill Bogstad
Re: just seen my first IPv6 network abuse scan, is this the start for more?
On Fri, Sep 3, 2010 at 9:49 AM, Dobbins, Roland wrote: > > On Sep 3, 2010, at 7:58 PM, Owen DeLong wrote: > >> However, scanning in IPv6 is not at all like the convenience of >> comprehensive scanning of the IPv4 address space. > > > Concur, but I still maintain that lots of illicit automation plus refined > scanning via DNS, et. al. is a viable practice. These are very big numbers, so I don't see how. If you use easy to guess/remember host/service names and put them in public DNS then those IP addresses are in some sense already public (whether IPv4 or IPv6). The definition of "easy to guess" is pretty much everything which has ever been used in a wordlist for password cracking programs (plus the code which generates variants of same). Real attackers are going to flood your DNS servers, not do brute force IPv6 ICMP scans. Even a pure brute force DNS scan of all 10 character long hostnames (asuming a-z0-9) is going to take around 5000 times fewer queries then a full ICMP v6 scan of a /64. (Which at an attack speed of 1000pps is still going to take around 100,000 years.) For machines which you want to make it REALLY hard to find, but need publicly accessible addresses, you shouldn't put them in publicly queryable DNS servers at all and use a random number generator to generate their static IPv6 addresses. Even if you put a thousand of these machines in a single subnet, it is going to take half a million years at reasonable packet rates before even one of them is discovered. Hmm, thinking about it in terms of passwords might help. Many people consider a totally random 10 character monocase+numbers password to be reasonably secure against brute force attacks. ICMP scanning a /64 is thousands of times more difficult and all it gives you is the existence of the machine. Even if you find that needle in a hay stack , you don't get access to its resources. I took a quick look at the paper that SMB linked to and I would argue that for wide area attacks, packet sniffing is going to be how people find your "hidden" addresses.Compromising SMB wi-fi hotspot hardware and logging every address accessed is one possibility. Or just compromise people's laptops and have them run network sniffers which generate "seen" address lists which are forwarded to dummy gmail accounts. Bill Bogstad
Re: Capture problems with Intel quad cards?
On Mon, Feb 16, 2009 at 12:35 AM, John A. Kilpatrick wrote: > > Has anyone had problems with using current Intel quad ethernet cards for > packet capture? As a proof-of-concept test we bought an Intel PWLA8494GT > and hooked it up to some Network Critical taps. There was a very strange > issue with corruption of the captured packets. The *only* issue (but it's a > big one) is that the source IP on some captured packets is munged. As far > as I can tell that's the *only* issue with the packet captures - no other > data is corrupted. Dumb question... It sounds like you've only used the card in packet capture mode (i.e. promiscuous mode). Have you tried testing the card just for normal host-to-host network flows? Maybe you have a bad card? If you still see problems on host-host flows, it's more likely to be a bad card rather then a bad driver. (Given that a driver that can't handle host-host flows is going to be obvious pretty quickly.) Good Luck, Bill Bogstad
Re: Dynamic IP log retention = 0?
On Sat, Mar 14, 2009 at 4:12 AM, Neil wrote: > On Wed, Mar 11, 2009 at 6:34 AM, Brett Charbeneau wrote: > >. >As William pointed out, it's the things that follow that determine whether >someone's being bad. To flag port-scans might be responsible, but I think >pursuing legal action over it would be the exact opposite. Wait until >someone demonstrates true maliciousness before trying to punish them, rather >than bringing the heat merely because they've demonstrated the potential for >maliciousness. In the physical world, this is the equivalent of 'casing the joint'. In most parts of the world, you can now get stopped/interrogated for simply taking pictures of the wrong buildings. (Even ones that in the past might have been considered tourist attractions.) Whether you think this is a good/bad thing, you shouldn't be surprised that people are similarly concerned about such behavior in the virtual world. > > This is almost akin to attacking someone because they're carrying a gun: > sure, the gun gives them the potential to do bad things, but it often enough > is innocent. (Political agendas aside...) No, this is more like some unknown guy in a high-rise a mile a way pointing his laser sniper scope at people walking in the park. They don't KNOW that he has a rifle attached to that scope. Even if he does, they don't KNOW that he plans to use it. Most people will never notice that little red dot in the middle of their chest. If they do notice and report it, however, I can guarantee that a significant investigation will take place. Bill Bogstad
US government mandates? use of DNSSEC by federal agencies
Not sure what this will actually mean in the long run, but it's at least worth noting. http://www.gcn.com/online/vol1_no1/46987-1.html http://www.whitehouse.gov/omb/memoranda/fy2008/m08-23.pdf Bill Bogstad
Re: IP4 Space
On Wed, Mar 10, 2010 at 10:00 PM, Daniel Senie wrote: > Well, it's like this... there's still no native IPv6 connectivity in most > data centers, residences, >businesses or wireless, most vendors of networking > equipment have not had a lot of mileage on >their IPv6 code if they even have > it fully working, and, frankly, the IPv6 community has been >predicting a > falling sky for so long that people just gave up listening. Add in a whole > lot of other bits >of argument that just exasperate those dealing with > today's problems, and it's pretty easy to >understand, if you've not been one > of the ones pushing IPV6 for all these years, that there's a lot of >listener > fatigue. I fall into this category, but I'm trying to get better. This may be OT for this forum, but as someone whose network admin hat has mostly been at the LAN/MAN level, I'm less concerned about IPv6 peering, etc. then I am with what applications/servers don't play well with IPv6 and how do I work around those issues. Where does one go to find out how organizations have switched their internal IT infrastructure to IPv6? Does it make sense/work to do this for internal operations even if our outside connections are IPv4 only (forget about tunneling). Even more mundane questions like how to deal with IPv4 only networked printers when everything else is IPv6? If anyone in the Boston metro area wants to present to the local system administrators group (www.bblisa.org) on why we should care (and more importantly what to do) please contact me off list. We're mostly a bunch of senior Unix system administrator who are comfortable in our IPv4 world and (I think) see IPv6 as a whole bunch of work to mostly get back to where we already are. We've all heard about the coming address apocalypse, but it always seems somewhere in the distant future. Thanks, Bill Bogstad
Re: legacy /8
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 > lng 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
Re: what about 48 bits?
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->1 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
characterizing BGP updates (research topic?)
Under a different subject Bill Woodcock wrote: > > On Mar 25, 2011, at 10:51 AM, Patrick W. Gilmore wrote: >> The question is whether "some data" is better than "no data". Honestly, I'm >> not sure. > > Yes, Patrick, I was just trying to be diplomatic about saying "not such a > good idea" so he'd keep reading through to the end, where I suggested some > other, possibly better, research topics. I am, however, certain that other > people could suggest even better research topics. Good research topics are > in demonstrably short supply among networking grad-students, so if y'all want > to be helpful... I'm currently looking for data characterizing BGP updates. This page calls out 'bad' guys: http://bgpupdates.potaroo.net/instability/bgpupd.html but I haven't found anything yet which defines the terms or methodologies used. Is there a key for this page somewhere? Are there similar data sources for BGP update stats that go into more detail? I'm personally interested in being able to tell the difference between new announcements/withdrawals of a prefix to the Internet as a whole (insufficient redundancy?) vs. changes in best path (next hop). If I can get my hands on raw BGP update traffic info, I would even consider taking a stab at doing the analysis myself. Pointers to data/previous results (as well as comments on why this is a stupid question) are welcome. Thanks, Bill Bogstad
Re: 23,000 IP addresses
On Tue, May 10, 2011 at 4:31 PM, Steven Bellovin wrote: >> >> > If I've found the right case, it was 05-1404, and published as 451 F.3d 226 > (2006); > see http://law.justia.com/cases/federal/appellate-courts/F3/451/226/627290/ > I have no idea if it's still good law. According to EDUCAUSE the appellate decision was complex: http://www.educause.edu/Policy+Analysis+%26+Advocacy/PressReleases/CALEACourtDecisionMixedforHigh/17136 This status page indicates that 'most' campus networks would be exempt: http://www.educause.edu/Resources/Browse/CALEA/30781 Definitely a case of 'talk to your lawyers' to be sure. Bill Bogstad bogs...@pobox.com
