Re: IPv6 RA vs DHCPv6 - The chosen one?
On Thu, Dec 22, 2011 at 3:04 PM, Tomas Podermanski wrote: > Well, then how many devices do you have in the network that uses IPv6? Good question, and I applaud you for wanting to verify that people talking about IPv6 have legitimate experience deploying it. I dug into the database I log all IPv6 traffic into. We have 8,509 active hosts using IPv6, that's in comparison to 35,229 on the IPv4 side, so about 24% (mind you, this is only the LAN networks we manage, we provide IPv6 transit to other entities as the regional R&E network). At this point over 95% of IPv4 LAN networks have IPv6 available, wireless is still a challenge (which is a big part of the difference between the host numbers you see above). We participate in Google's trusted IPv6 program, so Google announces 's to us for nearly all their services, so a significant amount of bandwidth is actually over IPv6. I would say that Google does make up the majority of IPv6 traffic though; there isn't much else out there announcing 's yet. We have always taken the approach that IPv6 isn't ready to be deployed if you can't do so while maintaining the same standards you have for IPv4 in the areas of manageability, security, availability, and stability. And we literally spent a few years modifying internal systems (and implementing new ones) to support IPv6 before we started making it available. See http://reports.informationweek.com/abstract/19/2233/Network-Infrastructure/strategy-session-ipv6.html for the case I've been making the last few years, or listen to me (and others) talking a little about it on Cisco's Higher Education webcast series http://www.cisco.com/web/strategy/education/us_education/webcasts.html > Do you have implemented first hop security? What will you do when some > user runs RA flood attack You can hear me talk a little about that in the Cisco webcast. Right now we maintain a PACL on our switches that filter RA or DHCPv6 server traffic originating from access ports. As you mentioned it doesn't protect against malicious attempts to disrupt services on the network (fragmented packets) but it does add a reasonable level of stability (e.g. prevent Windows ICS) to levels that are similar to IPv4. In addition, we have a process that monitors our routers for new RAs on the network, and alerts us to that (which would let us respond to a malicious RA that got past the PACL). For neighbor table exhaustion, I've written a set of scripts that I can use in a lab environment to perform the attacks against the platforms we use, and test how they fair. There is a pretty wide range of results. Most of the larger platforms that are the ones we would be concerned about actually hit CPU limitations before neighbor table exhaustion is accomplished, mainly because the neighbor discovery process doesn't appear to be implemented in hardware. It doesn't take much to pull off the attack either; a handful of residential connections would do the trick. This isn't an IPv6 problem so much as a vendor implementation problem, though. Like most DoS and DDoS attack vectors, vendors will need to take extra steps to harden equipment against these attack vectors as they become aware of them. Until vendors catch up (and that includes us having the funds to upgrade to new platforms that do a better job with it), we have opt'd to make use of longer prefixes than 64-bit (in fact we mirror the capacity of the IPv4 prefix; so a /24 in IPv4 would be a /120 in IPv6). A good description of this is available in some slides by Jeff Wheeler at http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf While your mileage may vary with longer prefixes, with the same attacks we saw the impact on CPU usage to be less than half when longer prefixes were used, and that's pretty good. You can also keep external attacks from reaching internal routers if you don't do route summarization internally, which sees considerable gains, as more of that logic appears to be in hardware. On the deployment side, we make use of DHCPv6 and RA with M and O set, and A unset. Our DHCPv6 servers only hand out IPv6 addresses to registered systems that are in the database and have been flagged as OK for IPv6. This has allowed us to roll out IPv6 on a host-by-host basis, rather than a network-wide basis (as you would need to do with SLAAC). This does have the consequence of excluding hosts from IPv6, piticurally Windows XP systems, and pre-Lion OS X systems. But since IPv6 isn't "required" yet (there is really no IPv6-only content yet), we take the position that we only provide IPv6 to systems that support DHCPv6 and have an adequate IPv6 host-level firewall as part of their IPv6 implementation. This makes it easy to exclude hosts that might be problematic to deliver IPv6 to, due to lack of security, or even bugs (RHEL 3 can kernel panic when connected to over IPv6, for example). It also keeps the pressure on to upgrade legacy systems. Wireless is an area we would really like t
Re: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again...
On Wed, Dec 21, 2011 at 11:54 AM, Jay Ashworth wrote: Leveraging a superior bargaining position to achieve more revenue from a kind of high-risk customer doesn't sound "dishonest" it sounds rational. Why would an agreement be denominated as "1 year maintenance" if it could simply be reinstated at will? What is meant by high-risk, is a customer inclined to renew maintenance, only at the moment that a lot of services are to be required all at once -- for example, just before a major software upgrade, likely followed by a slew of support incidents, possibly at a cost to the software vendor above the fee. I guess the networking equivalent is --- you stop paying for your OC3 with $BIG_TELCO for a few months, and you get it turned off, but for some reason the physical cabling isn't physically removed. A few months later, you decide you need an OC3 again and exclaim the unfairness of $BIG_TELCO informing you that a fee is required to re-install the OC3 they haven't removed yet. How unfair right... many thousands of $$ just to flip a switch? One chose to go without service for a few months, therefore should get a lower total cost, based on the new renewal date, right? In fact, it's not. If you miss your renewal payment for, frex, Safari > books, > they actually slip your cycle date to when you renew -- since you don't > *get* > It's a standard practice for _Software_ _Maintenance_ agreements; where a product is purchased, with an annual charge for updates, support, sometimes warranty, and other services for that product. If you let the agreement lapse, usually no warranty. Most extended warranties can't be renewed 6 months after they lapsed, because you found the product just broke and you would like to renew a warranty, so you can RMA it for a repair/replacement. Safari books is not a software maintenance agreement; it's a subscription service, and they allow members of the public to start a subscription any time, the cost to renew's basically equivalent to the cost to sign up; it's not as if there is a higher price for new subs. But, effectively, he's a new client, and should probably be treated that > way. > Yes. Software maintenance / subscription update services are not usually sold to just anyone on the street; they are normally sold with software. If you allowed your maintenance agreement to lapse, then You may now be in a position to negotiate a new agreement, but this most likely consists of asking what costs/terms are available for re-upping the maintenance, and having to accept in order to re-up. This likely means one of these scenarios... 1 o One time upgrade fee 2 o Pay delinquent maintenance bills, and then renew from anniversary date. 3 o Have to re-purchase product at brand new product cost, no 'upgrade' discount, since maintenance lapsed. (1) and (2) are most popular ways vendors offer to redeem expired maintenance. (3) Is not dishonest.It is the simplest thing to do, and justifiable if the product's price is low. One-time upgrade fee is very common with consumer software. When you buy "Windows 95" retail, you don't even pay an annual maintenance for free lifetime upgrades. Chances are you buy each upgrade, or get forced into (3), since Windows' cost is basically built into each new computer nowadays. But imagine if no computers came with windows.. and Microsoft offered you $25 a year for annual maintenance, for your Windows '95, and issued a new release every 2 years. If you allowed your maintenance to lapse in 1995, and then decided to renew in 2011... do you really think a reasonable software vendor would give you the 1 year windows '95 maintenance re-activation for $25 and the free upgrade to Windows 7? Nope... chances are you'd to pay $150+ before the vendor would consider re-upping that. -- -JH
Re: IPv6 RA vs DHCPv6 - The chosen one?
On Thu, 22 Dec 2011, Tomas Podermanski wrote: Hi, On 12/21/11 9:40 PM, Ray Soucy wrote: I'm afraid you're about 10 years too late for this opinion to make much difference. ;-) My opinion is that there is never too late to make thinks easier to implement and operate, specially in situation when things are unnecessary complicated. I do not hide that my opinion about SLAAC might look extreme but I have wrote my reasons for that. I do not expect that anything will be changed but the fact that I can see discussion about that topic approximately 2 or 3 times per month (v6ops, dhcwg, ipv6, ...) and that shows that this problem is pain for many people/ISP. Have you ever seen similar discussion related to DHCP(v4). I have not, because there nothing to discuss about. It just works. It works in simple and logical way. We have been running IPv6 in production for several years (2008) as well (answering this email over IPv6 now, actually) yet I have completely different conclusions about the role of RA and DHCPv6. Weird. Well, then how many devices do you have in the network that uses IPv6? Do you have implemented first hop security? What will you do when some user runs RA flood attack (http://samsclass.info/ipv6/proj/flood-router6a.htm). What will you do when some user runs NDP Table Exhaustion Attack (http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf) ? It is quite easy to bring IPv6 into a server subnet or a small office network. Providing stable and secure connectivity into the network with thousands of access port for the paying customers/users is really a serious issue today. This is implementation issue. Has to be fixed. Or your have to think about port-security I am very interested how the sites with similar number of access ports (users/customers) solve that problems. If users are not seperated by interfaces you can see similar issues in IPv4 (spoofing attacks) I can see that many ISPs prefer to solve that by blocking whole IPv6 traffic instead. But it does not look as a good strategy for deploying IPv6 :-(. Tomas On Wed, Dec 21, 2011 at 2:16 PM, Tomas Podermanski wrote: Hi, from my perspective the short answer for this never-ending story is: - SLAAC/RA is totally useless, does not bring any benefit at all and should be removed from IPv6 specs - DHCPv6 should be extended by route options as proposed in http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 - DHCPv6 should be extended by layer 2 address to identify client's L2 address (something that we can see in RFC 6221) - DHCPv6 should be the common way to autoconfigure an address in a IPv6 environment The long answer is: I completely disagree with opinion that both DHCPv6 and RA (SLAAC) should be supported. It is easy to say that both have place but it has some consequences. I and my colleagues have been working on deploying IPv6 for a few years and from the operation perspective we conclude into a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a opposite principles although the goal is just one. DHCPv6 is based on a central DHCPv6 server that assigns addresses. SLAAC does opposite - leaves the decision about the address on a client side. However we have to run both of them in a network to provide all necessary pieces of information to the clients (default route and DNS). This brings many implementation and operational complications. - Clients have to support both SLAAC and DHCPv6 to be able to work in both environments - There must be solved a situation what to do when SLAAC and DHCPv6 provides some conflict information (quite long thread with various opinions can be found at http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) - The first hop security have to be solved twice - for SLAAC and for DHCPv6. Both of then uses a differed communication way. SLAAC is part of ICMPv6, but DHCPv6 uses "own" UDP communication what does not make things easier. - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a process in the user space. Diagnostic and troubleshooting is more complicated. - DHCPv6 is currently tied with SLAAC (M,O flags), what means that a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 discovery. That unnecessary prolongs whole autoconfiguration process. Some other issues are also described in [1]. I personally prefer to bury SLAAC once forever for several reasons: - In fact SLAAC does nothing more what DHCPv6 can do. - SLAAC is quite difficult to secure. One (really only ONE) RA packet can destroy the IPv6 connection for all clients in a local network just in a few milliseconds. It also happens accidentally by "connection sharing" in Vista, Win7 (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf) - The full protection against that behavior it's impossible today. RA-Guard or PACL can be bypassed using extension headers or fragmentation (http://www.mh-sec.de/downloads/mh-ipv6_vu
Re: IPv6 RA vs DHCPv6 - The chosen one?
On Thu, 22 Dec 2011, Tomas Podermanski wrote: Hi, On 12/22/11 12:04 AM, Michael Sinatra wrote: On 12/21/11 12:40, Ray Soucy wrote: I'm afraid you're about 10 years too late for this opinion to make much difference. ;-) We have been running IPv6 in production for several years (2008) as well (answering this email over IPv6 now, actually) yet I have completely different conclusions about the role of RA and DHCPv6. Weird. And that's a very good reason not to deprecate SLAAC. Tomas may prefer DHCPv6, and he may provide reasons others may prefer DHCPv6. But he hasn't provided justification for deprecating SLAAC. I am not against SLAAC. I am against the way how DHCPv6 & SLAAC works today. Today, SLAAC can not live without DHCPv6 and DHCPv6 can not live without SLAAC (RA). Second reason is that we have two protocols/techniques to do just the same thing. I prefer to have just ONE common autoconfiguration method as we have it in IPv4. Because DHCPv6 is more complex and SLAAC can provide only subset of DHCP functionality I personaly prefer DHCPv6. This is your personal preference. Some has other personal preference. Many of us have been working with IPv6 for years and have found SLAAC to be quite useful. The biggest benefit it provides, which Tomas did not acknowledge, is the ability to autoconfigure hosts without running a central server. That said, I have also found DHCPv6 to be quite useful. We have to use SLAAC as well because we do not have other choice. Not all operating systems supports DHCPv6 today. But we are not happy about it (problems with privacy extensions, security as I mentioned before). DHCPv6 do not have to be run on a central server. DHCPv6 can be implemented as a part of a router as well. It is common for DHCP(v4) an implementations for DHCPv6 are available today (eg. cisco http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-dhcp.html). Similar configuration o routers: - enabling ipv6 relay agent -> DHCPv6 configuration - enabling router advertisment on interace -> SLAAC (some routers has to oppposite) I also agree with Owen: Provide two complete solutions, and let operators choose based on their needs. That implies fixing DHCPv6 so I don't have to go in and disable the autonomous flag on my routers and run RAs just to get a default route. But it also implies not deprecating either SLAAC or DHCPv6. Although we have differed opinion whether we need one or two autoconfiguration protocols, I totally agree that "fixing" DHCPv6 is a really necessary step and It should have been done many years ago. Btw. not all people agree that DHCPv6 should be fixed in that way. There was a discussion in 2009 in dhcwg (thread available on: http://www.ietf.org/mail-archive/web/dhcwg/current/msg09715.html). The current draft (draft-ietf-mif-dhcpv6-route-option-03) is the 3rd attempt to do it. In past, there were another two drafts trying to introduce route information into DHCPv6: draft-droms-dhc-dhcpv6-default-router-00, expired September 2009 draft-dec-dhcpv6-route-option-05, expired April 2011 So I hope that this time we will have more luck :-) I am also supporting this Tomas
Re: IPv6 RA vs DHCPv6 - The chosen one?
On Wed, 21 Dec 2011, Tomas Podermanski wrote: Hi, from my perspective the short answer for this never-ending story is: - SLAAC/RA is totally useless, does not bring any benefit at all and should be removed from IPv6 specs - DHCPv6 should be extended by route options as proposed in http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 - DHCPv6 should be extended by layer 2 address to identify client's L2 address (something that we can see in RFC 6221) - DHCPv6 should be the common way to autoconfigure an address in a IPv6 environment Your opinion is very extreme. Another extremity would be to add some extension into SLAAC/RA and remove DHCPv6 completely. BUT both mechanisms have their merits. They have to interporate! Every environment should develop their policy according to their needs! The long answer is: I completely disagree with opinion that both DHCPv6 and RA (SLAAC) should be supported. It is easy to say that both have place but it has some consequences. I and my colleagues have been working on deploying IPv6 for a few years and from the operation perspective we conclude into a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a opposite principles although the goal is just one. DHCPv6 is based on a central DHCPv6 server that assigns addresses. SLAAC does opposite - leaves the decision about the address on a client side. However we have to run both of them in a network to provide all necessary pieces of information to the clients (default route and DNS). This brings many implementation and operational complications. - Clients have to support both SLAAC and DHCPv6 to be able to work in both environments They already do. If not they have to be fixed. - There must be solved a situation what to do when SLAAC and DHCPv6 provides some conflict information (quite long thread with various opinions can be found at http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) Administrators are deliberately providing conflicting information? - The first hop security have to be solved twice - for SLAAC and for DHCPv6. Both of then uses a differed communication way. SLAAC is part of ICMPv6, but DHCPv6 uses "own" UDP communication what does not make things easier. This can be an argument for remove DHCPv6 completely - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a process in the user space. Diagnostic and troubleshooting is more complicated. Some operating system do the SLAAC processing in user space. What is the problem. - DHCPv6 is currently tied with SLAAC (M,O flags), what means that a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 discovery. That unnecessary prolongs whole autoconfiguration process. I think it is matter of implementation. Some other issues are also described in [1]. I personally prefer to bury SLAAC once forever for several reasons: - In fact SLAAC does nothing more what DHCPv6 can do. But suitable in certain environments. - SLAAC is quite difficult to secure. One (really only ONE) RA packet can destroy the IPv6 connection for all clients in a local network just in a few milliseconds. It also happens accidentally by "connection sharing" in Vista, Win7 (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf) Their is an RAguard RFC to prevent this. - The full protection against that behavior it's impossible today. RA-Guard or PACL can be bypassed using extension headers or fragmentation (http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf) For solution See propoosal of Fernando Gont about atomic ICMPv6 messages. - With SLAAC is difficult to implement security features like ARP/ND protection/inspection, IP source guard/Dynamic lock down, because all this techniques are based on a MAC-IP database created during a communication with a DHCP server. There are some attempts (ND protection, SAVI) but it does not provide the same level of security. What is missing? - Just the same technique was introduced in IPv4 as Router Discovery (RFC 1256). Nobody uses it today. Do we really need go through same death way again? (Oh right, we are already going :-( ) Nobody? Every modern Windows OS. Comparing to SLAAC, DHCPv6 have several advantages: - DHCPv6 is very similar to DHCP(v4) and many people are used to using it. - DHCPv6 can potentially do much more - for example handle an information for PXE, options for IP phones, prefix delegation. - DHCPv6 allows handle an information only for some hosts or group of hosts (differed lease time, search list, DNS atc.). With SLAAC it is impossible and all host on a subnet have to share the same set of the configuration information. RA is just matter of swtiching on first hop router. You don't have to configure anything. - Frankly said, I have not found any significant benefit that SLAAC brings. Configuration of thousands of device without much overhead on server si
Re: IPv6 RA vs DHCPv6 - The chosen one?
Sent from my iPad On Dec 23, 2011, at 3:46 AM, Tomas Podermanski wrote: > Hi, > > On 12/22/11 12:18 AM, Owen DeLong wrote: >>> The long answer is: >>> >>> I completely disagree with opinion that both DHCPv6 and RA (SLAAC) >>> should be supported. It is easy to say that both have place but it has >>> some consequences. I and my colleagues have been working on deploying >>> IPv6 for a few years and from the operation perspective we conclude into >>> a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a >>> opposite principles although the goal is just one. DHCPv6 is based on a >>> central DHCPv6 server that assigns addresses. SLAAC does opposite - >>> leaves the decision about the address on a client side. However we have >>> to run both of them in a network to provide all necessary pieces of >>> information to the clients (default route and DNS). This brings many >>> implementation and operational complications. >>> >> I agree that the requirement to run both is broken. I don't agree that this >> means we should remove the option of using SLAAC in environments >> where it makes sense. >> >>> - Clients have to support both SLAAC and DHCPv6 to be able to work in >>> both environments >> So? > > It makes the client side more difficult to implement (=more expensive). > What worse SLAAC and DHCPv6 are differed protocols, so there is bigger > probability for attacks (overflow, flood etc.). For example in UNIX-like > systems autoconfiguration have to be solved by 3 parts of the system: > > 1. some SLAAC options are usually processed by a kernel (address > selection, MTU) and behavior of that process can be changed via sysctl > 2. some SLAAC options are processed by rdnssd daemon (processing DNS > options) > 3. DHCPv6 options are processed byt dhcpv6-client > > All those parts have to cooperate together. At the first sight it is > obvious that there is pretty good probability that something can go > wrong. Troubleshooting then is really piece of cake. For example in IPv4 > environment we have following scenario: > > 1. DHCP options are processed by dhcp-client Except when they are processed by BIOS, Kernel, or something else. Yeah, the situation there in terms of the number of moving pieces is actually about the same. Even when DHCP options are parsed by dhcp-client, it has to use them to modify the kernel data structures and affect the behavior of other parts of the system, so, there's roughly similar amount of interaction either way. > >> >>> - There must be solved a situation what to do when SLAAC and DHCPv6 >>> provides some conflict information (quite long thread with various >>> opinions >>> can be found at >>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) >> SLAAC and DHCPv6 can't really provide conflicting information unless >> the router is misconfigured. Even if a host gets different answers for the >> same prefixes from SLAAC and DHCP, it should be able to use both >> host addresses. There's the question of source address selection, but, >> the answer to that question at the IETF level should only be a matter >> of what the default answer is. There are configuration options for setting >> host source address selection priorities. > > I am not thinking about address. It is the easier part - we can use all > provided. There are other options like DNS servers, search list, NTP > servers, ... > If you get DNS servers from RA and from DHCP, throw them all in the candidate DNS server list. Unless something is broken, any one of them should work and provide the same answers as the others. You can't get NTP from SLAAC/RA, so, no conflict there. If the router and dhcp server administrators can't agree on the DNS search list, then, you're going to have some problems no matter what protocol you use, so, I really think this is a tempest in a teacup. >> >>> - The first hop security have to be solved twice - for SLAAC and for >>> DHCPv6. Both >>> of then uses a differed communication way. SLAAC is part of ICMPv6, >>> but DHCPv6 >>> uses "own" UDP communication what does not make things easier. >> Solved for SLAAC -- SEND. >> Allegedly, there is Secure DHCPv6 for DHCP, but, I haven't seen any >> actual implementations yet. > > Right, very easy to write but pretty difficult (impossible) to use > today. None of operating systems supports SEND and some will probably > never be: If there is actual real world demand for it, it will get implemented. Reality is that today, DHCPv4 has been running just as insecure for many years and nobody cares. I don't know why the bar for IPv6 should be so much higher than IPv4. > > as we can find http://technet.microsoft.com/en-us/library/bb726956.aspx > However, Microsoft does not support SEND in any version of Windows. > > I have found only one implementation for Linux > (http://amnesiak.org/NDprotector/) that is not ready for production. So > we can not think seriously about SEND today. SEND also brings another >
Re: what if...?
On Dec 22, 2011, at 7:04 PM, Jeroen van Aart wrote: > Marshall Eubanks wrote: >> Does your Mom call you up every time she gets a dialog box complaining >> about an invalid certificate ? >> If she has been conditioned just to click "OK" when that happens, then >> she probably can't. > > Everyone I have observed clicks "ok" or "confirm exception" (if I remember > the phrase correctly) as soon as possible. Sadly I think only a few security > conscious (IT) people will actually think twice and reject it if they don't > trust it. > > That to me proves this aspect ssl is somewhat flawed in that regard. But then > I am preaching to the choir. :-) See the definition of "dialog box" at http://www.w3.org/2006/WSC/wiki/Glossary --Steve Bellovin, https://www.cs.columbia.edu/~smb
Re: IPv6 RA vs DHCPv6 - The chosen one?
Glen Kent wrote: > While in some environments, typically with small number of devices, > its indispensable. Small businesses may not want the complexity of > setting up a central server (for DHCP) - SLAAC works very well in such > environments. IPv6 routers are the central servers for SLAAC with the complexity of setting up. Moreover, SLAAC is stateful in the worst way, because states of address assignments are held unnecessarily distributed way, which is why time and power consuming DAD is considered to be necessary. Just as most, if not all, NAT boxes have preconfigured DHCPv4 service to offer part of preconfigured private address space, home IPv6 routers may have preconfigured DHCPv6 service to offer part of configured public address space. Masataka Ohta
Re: what if...?
Marshall Eubanks wrote: Does your Mom call you up every time she gets a dialog box complaining about an invalid certificate ? If she has been conditioned just to click "OK" when that happens, then she probably can't. Everyone I have observed clicks "ok" or "confirm exception" (if I remember the phrase correctly) as soon as possible. Sadly I think only a few security conscious (IT) people will actually think twice and reject it if they don't trust it. That to me proves this aspect ssl is somewhat flawed in that regard. But then I am preaching to the choir. :-) Regards, Jeroen -- Earthquake Magnitude: 4.9 Date: Thursday, December 22, 2011 16:41:15 UTC Location: Tarapaca, Chile Latitude: -19.5358; Longitude: -69.1219 Depth: 95.20 km
Re: Windows UDP packet generator software?
If anyone needs a per-compiled iPerf.exe, no need for cygwin libraries, lemme know. It's a great tool! Ryan Pavely Director Research And Development Net Access Corporation http://www.nac.net/ On 12/22/2011 3:20 PM, Larry Blunk wrote: On 12/22/2011 02:36 PM, Sean Harlow wrote: iperf might be able to do what you need and there are Windows builds available, but I'm not sure if it has a mode where it's not flooding the network trying to test maximum speed. Is there a reason that standard ICMP pings aren't appropriate if you just want packet loss info? Obviously every platform worth using has ping built in. -- Sean Harlow s...@seanharlow.info In UDP mode, iperf sends at 1 Mbps by default. You change the rate with the -b flag. There's an iperf-2.0.5-cygwin build floating around for Windows.
RE: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again...
The vmware image is more expensive than the midrange hardware. (and you pay for how many processors it will use, ram, features like multi domain support, etc...) __ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 > -Original Message- > From: Jeremy Parr [mailto:jeremyp...@gmail.com] > Sent: Thursday, December 22, 2011 3:54 PM > To: Jon Lewis; nanog@nanog.org > Subject: Re: Well Lookie Here, Barracuda Networks tries to > get me to fall into their trap again... > > > On 22 December 2011 14:07, Jon Lewis wrote: > > > Presumably, Barracuda's hardware is i386/i686 compatible commodity > > parts. It's probably not at all "useless". Just attach a USB DVD > > drive or USB flash drive, wipe the disk(s) and install your > favorite > > Linux distro. It may take some doing to get all/most of the > features > > Barracuda provides setup on your own...but if you don't have the > > time/expertise to do it, that's why companies like Barracuda exist. > > > The hardware Barracuda charges you a very pretty penny for is > very low end. $3000 or so that they charge for a mid-level > spam filters gets you a single power supply, single hard > disk, and a low end processor. > > According to their site it does appear they offer the product > as VM image. This would eliminate the stupid hardware markup > and their attempt at backdating updates. > This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. <>
Re: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again...
On 22 December 2011 14:07, Jon Lewis wrote: > Presumably, Barracuda's hardware is i386/i686 compatible commodity parts. > It's probably not at all "useless". Just attach a USB DVD drive or USB > flash drive, wipe the disk(s) and install your favorite Linux distro. > It may take some doing to get all/most of the features Barracuda provides > setup on your own...but if you don't have the time/expertise to do it, > that's why companies like Barracuda exist. > The hardware Barracuda charges you a very pretty penny for is very low end. $3000 or so that they charge for a mid-level spam filters gets you a single power supply, single hard disk, and a low end processor. According to their site it does appear they offer the product as VM image. This would eliminate the stupid hardware markup and their attempt at backdating updates.
Re: IPv6 RA vs DHCPv6 - The chosen one?
On 12/22/2011 04:48, Glen Kent wrote: >> In many environments RA is a catastrophic disaster. Some operators need >> to be able to do everything with RA turned off on routers, disabled on >> hosts and filtered on switches. > > While in some environments, typically with small number of devices, > its indispensable. Small businesses may not want the complexity of > setting up a central server (for DHCP) - SLAAC works very well in such > environments. Please show me the small businesses that don't already have a DHCP server. Or (equally unlikely) show me the small business whose DHCP server isn't baked into their SOHO router/toaster and works with nearly zero human intervention. > Today, we can get NTP server information only with DHCP (DNS info is > supported by both DHCP and RAs). DHCP only works after RAs have been > processed. In some environments (mobile IPv6) delays in acquiring NTP > and other servers information is critical and waiting for DHCP to come > up may not be acceptable. So clearly the right answer is to make DHCPv6 a superset of RA functionality so that the people who need more than what RA provides only have to run DHCP. Over strenuous objection DNS resolver data was added to RA and the folks over in MIF are just now getting around to sorting out the damage caused by having the same category of information arrive over 2 different configuration protocols with subtly different data. (A 100% foreseen problem that was part of the core of the previously mentioned strenuous objections.) RA was an interesting idea that came to light in an era when DHCP was new, clunky, unreliable, and not widely deployed. None of those things are true anymore, so it would be very helpful if IPv6 deployment planning moved into the 21st Century. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Re: IPv6 RA vs DHCPv6 - The chosen one?
Hi, On 12/22/11 12:18 AM, Owen DeLong wrote: >> The long answer is: >> >> I completely disagree with opinion that both DHCPv6 and RA (SLAAC) >> should be supported. It is easy to say that both have place but it has >> some consequences. I and my colleagues have been working on deploying >> IPv6 for a few years and from the operation perspective we conclude into >> a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a >> opposite principles although the goal is just one. DHCPv6 is based on a >> central DHCPv6 server that assigns addresses. SLAAC does opposite - >> leaves the decision about the address on a client side. However we have >> to run both of them in a network to provide all necessary pieces of >> information to the clients (default route and DNS). This brings many >> implementation and operational complications. >> > I agree that the requirement to run both is broken. I don't agree that this > means we should remove the option of using SLAAC in environments > where it makes sense. > >> - Clients have to support both SLAAC and DHCPv6 to be able to work in >> both environments > So? It makes the client side more difficult to implement (=more expensive). What worse SLAAC and DHCPv6 are differed protocols, so there is bigger probability for attacks (overflow, flood etc.). For example in UNIX-like systems autoconfiguration have to be solved by 3 parts of the system: 1. some SLAAC options are usually processed by a kernel (address selection, MTU) and behavior of that process can be changed via sysctl 2. some SLAAC options are processed by rdnssd daemon (processing DNS options) 3. DHCPv6 options are processed byt dhcpv6-client All those parts have to cooperate together. At the first sight it is obvious that there is pretty good probability that something can go wrong. Troubleshooting then is really piece of cake. For example in IPv4 environment we have following scenario: 1. DHCP options are processed by dhcp-client > >> - There must be solved a situation what to do when SLAAC and DHCPv6 >> provides some conflict information (quite long thread with various >> opinions >> can be found at >> http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) > SLAAC and DHCPv6 can't really provide conflicting information unless > the router is misconfigured. Even if a host gets different answers for the > same prefixes from SLAAC and DHCP, it should be able to use both > host addresses. There's the question of source address selection, but, > the answer to that question at the IETF level should only be a matter > of what the default answer is. There are configuration options for setting > host source address selection priorities. I am not thinking about address. It is the easier part - we can use all provided. There are other options like DNS servers, search list, NTP servers, ... > >> - The first hop security have to be solved twice - for SLAAC and for >> DHCPv6. Both >> of then uses a differed communication way. SLAAC is part of ICMPv6, >> but DHCPv6 >> uses "own" UDP communication what does not make things easier. > Solved for SLAAC -- SEND. > Allegedly, there is Secure DHCPv6 for DHCP, but, I haven't seen any > actual implementations yet. Right, very easy to write but pretty difficult (impossible) to use today. None of operating systems supports SEND and some will probably never be: as we can find http://technet.microsoft.com/en-us/library/bb726956.aspx However, Microsoft does not support SEND in any version of Windows. I have found only one implementation for Linux (http://amnesiak.org/NDprotector/) that is not ready for production. So we can not think seriously about SEND today. SEND also brings another set of problems like certificate management, etc., but is a little differed story. > >> - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a >> process in the user space. Diagnostic and troubleshooting is more >> complicated. > That seems like an argument for SLAAC, if anything. > >> - DHCPv6 is currently tied with SLAAC (M,O flags), what means that >> a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 >> discovery. That unnecessary prolongs whole autoconfiguration process. > While I agree with you that the standard is broken in this regard, there is at > least one OS vendor that already violates that rule anyway. >> Some other issues are also described in [1]. >> >> I personally prefer to bury SLAAC once forever for several reasons: >> - In fact SLAAC does nothing more what DHCPv6 can do. > Yes, but, it does it in a much simpler way with a lot less overhead which > can be a benefit in some environments. I have to admit that less overhead is one of benefit of SLAAC. But having experience with DHCP(v4) all devices that we have today (phones, cameras, etc.) do not have a problem to process DHCPv4 packets, so there is no reason why same devices could not do it for DHCPv6. The sensor networks mentioned in one mail before is a very sp
Re: IPv6 RA vs DHCPv6 - The chosen one?
On Thu, 22 Dec 2011 21:04:42 +0100, Tomas Podermanski said: > Well, then how many devices do you have in the network that uses IPv6? 1,300+ wireless access points, 1,100+ switches, 30k+ users, around 55% doing at least some IPv6 traffic (mostly when they hit Google). > Do you have implemented first hop security? What will you do when some > user runs RA flood attack > (http://samsclass.info/ipv6/proj/flood-router6a.htm). "First actual case of a bug being found" -- Lt Cmdr Grace Hopper I've asked around, and although everybody understands it's an issue, the number of people actually *seeing* one of these attacks is... Bueller? Bueller? pgphtaZDc2qjo.pgp Description: PGP signature
Re: Windows UDP packet generator software?
On 12/22/2011 02:36 PM, Sean Harlow wrote: iperf might be able to do what you need and there are Windows builds available, but I'm not sure if it has a mode where it's not flooding the network trying to test maximum speed. Is there a reason that standard ICMP pings aren't appropriate if you just want packet loss info? Obviously every platform worth using has ping built in. -- Sean Harlow s...@seanharlow.info In UDP mode, iperf sends at 1 Mbps by default. You change the rate with the -b flag. There's an iperf-2.0.5-cygwin build floating around for Windows.
Re: Windows UDP packet generator software?
I can imagine plenty of circumstances where someone might want by-protocol indications of service, rather than the relatively basic link-test that ICMP provides. Another vote for iperf Mark. On 23/12/11 08:36, Sean Harlow wrote: > iperf might be able to do what you need and there are Windows builds > available, but I'm not sure if it has a mode where it's not flooding the > network trying to test maximum speed. Is there a reason that standard ICMP > pings aren't appropriate if you just want packet loss info? Obviously every > platform worth using has ping built in. > -- > Sean Harlow > s...@seanharlow.info > > On Dec 22, 2011, at 2:28 PM, Jay Nakamura wrote: > >> The goal of what I am doing is to test some network convergence impact >> in a lab with two PCs with windows (Can't run Linux, it would be >> easier if I could) and switches and/or routers in between. >> >> So, I thought there must be some simple utility out there that can >> just start spewing out UDP packets to the other side at a certain time >> interval and I can look at packet loss via what arrives on the other >> side with wireshark on the PC. >> >> I found hping but it seems to be outdated and I can't get it to work >> on my windows boxes. >> >> Anyone have any suggestions? >> >
Re: Help with quagga BGP config for ipv6 route-server
My IPv4 and IPv6 BGP connections now get prefixes. My thanks to those who answered on and off the list. My revised config is like: --- router bgp MYAS no bgp enforce-first-as no bgp default ipv4-unicast network MYIPv4NET route-map SetAttr neighbor PEERIPv6 remote-as RSAS neighbor PEERIPv4 remote-as RSAS neighbor PEERIPv4 activate neighbor PEERIPv4 next-hop-self neighbor PEERIPv4 send-community !neighbor PEERIPv4 soft-reconfiguration inbound address-family ipv6 network MYIPv6NET route-map SetAttr neighbor PEERIPv6 activate neighbor PEERIPv6 send-community neighbor PEERIPv6 soft-reconfiguration inbound exit-address-family route-map SetAttr permit 10 set community RSAS:RSAS end - I had to move the V6 remote-as line up before the address-family ipv6 block. I appear to have needed the "exit-address-family". Having "bgp router-id MYIP4INTERFACE" causes problems. I am not sure yet if not having it is going to cause other problems. -- David Waitzman
Re: IPv6 RA vs DHCPv6 - The chosen one?
Hi, On 12/22/11 12:04 AM, Michael Sinatra wrote: > On 12/21/11 12:40, Ray Soucy wrote: >> I'm afraid you're about 10 years too late for this opinion to make >> much difference. ;-) >> >> We have been running IPv6 in production for several years (2008) as >> well (answering this email over IPv6 now, actually) yet I have >> completely different conclusions about the role of RA and DHCPv6. >> Weird. > > And that's a very good reason not to deprecate SLAAC. Tomas may > prefer DHCPv6, and he may provide reasons others may prefer DHCPv6. > But he hasn't provided justification for deprecating SLAAC. I am not against SLAAC. I am against the way how DHCPv6 & SLAAC works today. Today, SLAAC can not live without DHCPv6 and DHCPv6 can not live without SLAAC (RA). Second reason is that we have two protocols/techniques to do just the same thing. I prefer to have just ONE common autoconfiguration method as we have it in IPv4. Because DHCPv6 is more complex and SLAAC can provide only subset of DHCP functionality I personaly prefer DHCPv6. > > Many of us have been working with IPv6 for years and have found SLAAC > to be quite useful. The biggest benefit it provides, which Tomas did > not acknowledge, is the ability to autoconfigure hosts without running > a central server. That said, I have also found DHCPv6 to be quite > useful. We have to use SLAAC as well because we do not have other choice. Not all operating systems supports DHCPv6 today. But we are not happy about it (problems with privacy extensions, security as I mentioned before). DHCPv6 do not have to be run on a central server. DHCPv6 can be implemented as a part of a router as well. It is common for DHCP(v4) an implementations for DHCPv6 are available today (eg. cisco http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-dhcp.html). > > I also agree with Owen: Provide two complete solutions, and let > operators choose based on their needs. That implies fixing DHCPv6 so > I don't have to go in and disable the autonomous flag on my routers > and run RAs just to get a default route. But it also implies not > deprecating either SLAAC or DHCPv6. Although we have differed opinion whether we need one or two autoconfiguration protocols, I totally agree that "fixing" DHCPv6 is a really necessary step and It should have been done many years ago. Btw. not all people agree that DHCPv6 should be fixed in that way. There was a discussion in 2009 in dhcwg (thread available on: http://www.ietf.org/mail-archive/web/dhcwg/current/msg09715.html). The current draft (draft-ietf-mif-dhcpv6-route-option-03) is the 3rd attempt to do it. In past, there were another two drafts trying to introduce route information into DHCPv6: draft-droms-dhc-dhcpv6-default-router-00, expired September 2009 draft-dec-dhcpv6-route-option-05, expired April 2011 So I hope that this time we will have more luck :-) Tomas
Re: IPv6 RA vs DHCPv6 - The chosen one?
Hi, On 12/21/11 9:40 PM, Ray Soucy wrote: > I'm afraid you're about 10 years too late for this opinion to make > much difference. ;-) My opinion is that there is never too late to make thinks easier to implement and operate, specially in situation when things are unnecessary complicated. I do not hide that my opinion about SLAAC might look extreme but I have wrote my reasons for that. I do not expect that anything will be changed but the fact that I can see discussion about that topic approximately 2 or 3 times per month (v6ops, dhcwg, ipv6, ...) and that shows that this problem is pain for many people/ISP. Have you ever seen similar discussion related to DHCP(v4). I have not, because there nothing to discuss about. It just works. It works in simple and logical way. > > We have been running IPv6 in production for several years (2008) as > well (answering this email over IPv6 now, actually) yet I have > completely different conclusions about the role of RA and DHCPv6. > Weird. Well, then how many devices do you have in the network that uses IPv6? Do you have implemented first hop security? What will you do when some user runs RA flood attack (http://samsclass.info/ipv6/proj/flood-router6a.htm). What will you do when some user runs NDP Table Exhaustion Attack (http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf) ? It is quite easy to bring IPv6 into a server subnet or a small office network. Providing stable and secure connectivity into the network with thousands of access port for the paying customers/users is really a serious issue today. I am very interested how the sites with similar number of access ports (users/customers) solve that problems. I can see that many ISPs prefer to solve that by blocking whole IPv6 traffic instead. But it does not look as a good strategy for deploying IPv6 :-(. Tomas > > On Wed, Dec 21, 2011 at 2:16 PM, Tomas Podermanski > wrote: >> Hi, >> >> from my perspective the short answer for this never-ending story is: >> >> - SLAAC/RA is totally useless, does not bring any benefit at all >> and should be removed from IPv6 specs >> - DHCPv6 should be extended by route options as proposed in >> http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 >> - DHCPv6 should be extended by layer 2 address to identify >> client's L2 address (something that we can see in RFC 6221) >> - DHCPv6 should be the common way to autoconfigure an address >> in a IPv6 environment >> >> The long answer is: >> >> I completely disagree with opinion that both DHCPv6 and RA (SLAAC) >> should be supported. It is easy to say that both have place but it has >> some consequences. I and my colleagues have been working on deploying >> IPv6 for a few years and from the operation perspective we conclude into >> a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a >> opposite principles although the goal is just one. DHCPv6 is based on a >> central DHCPv6 server that assigns addresses. SLAAC does opposite - >> leaves the decision about the address on a client side. However we have >> to run both of them in a network to provide all necessary pieces of >> information to the clients (default route and DNS). This brings many >> implementation and operational complications. >> >> - Clients have to support both SLAAC and DHCPv6 to be able to work in >> both environments >> - There must be solved a situation what to do when SLAAC and DHCPv6 >> provides some conflict information (quite long thread with various >> opinions >> can be found at >> http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) >> - The first hop security have to be solved twice - for SLAAC and for >> DHCPv6. Both >> of then uses a differed communication way. SLAAC is part of ICMPv6, >> but DHCPv6 >> uses "own" UDP communication what does not make things easier. >> - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a >> process in the user space. Diagnostic and troubleshooting is more >> complicated. >> - DHCPv6 is currently tied with SLAAC (M,O flags), what means that >> a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 >> discovery. That unnecessary prolongs whole autoconfiguration process. >> >> Some other issues are also described in [1]. >> >> I personally prefer to bury SLAAC once forever for several reasons: >> - In fact SLAAC does nothing more what DHCPv6 can do. >> - SLAAC is quite difficult to secure. One (really only ONE) RA packet >> can destroy >> the IPv6 connection for all clients in a local network just in a few >> milliseconds. >> It also happens accidentally by "connection sharing" in Vista, Win7 >> >> (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf) >> - The full protection against that behavior it's impossible today. >> RA-Guard or >> PACL can be bypassed using extension headers or fragmentation >> (http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf) >> - With SLAAC is difficult to implement securit
Re: Windows UDP packet generator software?
iperf might be able to do what you need and there are Windows builds available, but I'm not sure if it has a mode where it's not flooding the network trying to test maximum speed. Is there a reason that standard ICMP pings aren't appropriate if you just want packet loss info? Obviously every platform worth using has ping built in. -- Sean Harlow s...@seanharlow.info On Dec 22, 2011, at 2:28 PM, Jay Nakamura wrote: > The goal of what I am doing is to test some network convergence impact > in a lab with two PCs with windows (Can't run Linux, it would be > easier if I could) and switches and/or routers in between. > > So, I thought there must be some simple utility out there that can > just start spewing out UDP packets to the other side at a certain time > interval and I can look at packet loss via what arrives on the other > side with wireshark on the PC. > > I found hping but it seems to be outdated and I can't get it to work > on my windows boxes. > > Anyone have any suggestions? >
Re: Windows UDP packet generator software?
On Thu, Dec 22, 2011 at 10:28 PM, Jay Nakamura wrote: > The goal of what I am doing is to test some network convergence impact > in a lab with two PCs with windows (Can't run Linux, it would be > easier if I could) and switches and/or routers in between. > > So, I thought there must be some simple utility out there that can > just start spewing out UDP packets to the other side at a certain time > interval and I can look at packet loss via what arrives on the other > side with wireshark on the PC. > > I found hping but it seems to be outdated and I can't get it to work > on my windows boxes. > > Anyone have any suggestions? > > Two suggestions: 1) http://robert.rsa3.com/traffic.html (I haven't actually run this myself, but it's description seems to fit the bill) 2) http://sourceforge.net/projects/iperf/ (iPerf in client mode can spew UDP packets in configurable bursts)
Re: Windows UDP packet generator software?
d-itg works very well. http://www.grid.unina.it/software/ITG/index.php you can create reports of loss/jitter etc. windows and qos don't work so don't try setting qos values as they will just be reset to 0 by the windows tcp/ip stack. james
Windows UDP packet generator software?
The goal of what I am doing is to test some network convergence impact in a lab with two PCs with windows (Can't run Linux, it would be easier if I could) and switches and/or routers in between. So, I thought there must be some simple utility out there that can just start spewing out UDP packets to the other side at a certain time interval and I can look at packet loss via what arrives on the other side with wireshark on the PC. I found hping but it seems to be outdated and I can't get it to work on my windows boxes. Anyone have any suggestions?
Re: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again...
On 12/22/2011 11:07 AM, Jon Lewis wrote: On Thu, 22 Dec 2011, Michael Thomas wrote: At that point why should they sell iron at all? Seems like you get all of the downside of owning the iron, and all of the downside of paying for a cloud based service. Either you own what you own, or you pay for service that somebody else provides. This "you bought useless hardware unless you pay up" is really what's infuriating. Presumably, Barracuda's hardware is i386/i686 compatible commodity parts. It's probably not at all "useless". Just attach a USB DVD drive or USB flash drive, wipe the disk(s) and install your favorite Linux distro. It may take some doing to get all/most of the features Barracuda provides setup on your own...but if you don't have the time/expertise to do it, that's why companies like Barracuda exist. If the spam filter stop working, it's presumably a pretty useless thing as a... spam filtering device which is presumably why most people are buying barracuda boxen. I suppose my larger point is that this is why companies like postini exist. At least there you know that if you don't pay the bill, mail stops flowing altogether much like any other service. It's this "I paid for the hardware, but I don't really own what I paid for" state that seems to stick in people's craw. Or maybe if they just leased the box it would be more clear what their business model was. Mike
Re: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again...
On Thu, 22 Dec 2011, Michael Thomas wrote: At that point why should they sell iron at all? Seems like you get all of the downside of owning the iron, and all of the downside of paying for a cloud based service. Either you own what you own, or you pay for service that somebody else provides. This "you bought useless hardware unless you pay up" is really what's infuriating. Presumably, Barracuda's hardware is i386/i686 compatible commodity parts. It's probably not at all "useless". Just attach a USB DVD drive or USB flash drive, wipe the disk(s) and install your favorite Linux distro. It may take some doing to get all/most of the features Barracuda provides setup on your own...but if you don't have the time/expertise to do it, that's why companies like Barracuda exist. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again...
In a message written on Thu, Dec 22, 2011 at 10:54:55AM -0800, Michael Thomas wrote: > At that point why should they sell iron at all? Seems like you get > all of the downside of owning the iron, and all of the downside of > paying for a cloud based service. Either you own what you own, > or you pay for service that somebody else provides. This "you > bought useless hardware unless you pay up" is really what's > infuriating. I didn't say the box should stop working, but that it should stop processing the subscription data. For instance Barracuda boxes do local bayesian filtering, which does not require a subscription, and should continue to work. But I'm also not sure why this is any more or less infuriating than other things in the real world. When my home was built I had to buy an electric meter, at my cost, so I could get electric _service_. If I don't pay the bill they turn me off, that hardware is now useless and I don't get to recoup that cost. Barracuda has bundled a hardware product with a service. Some people want it priced like a hardware product, some people want it priced like a service. That is fundamentally why they are in a no-win position from a customer relations perspective. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpDa6UiTi0gv.pgp Description: PGP signature
Re: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again...
On 12/22/2011 10:47 AM, Leo Bicknell wrote: In a message written on Thu, Dec 22, 2011 at 12:26:56PM -0600, PC wrote: This particular product is often used by the SMB types. This changes things a bit. While I disagree with paying for signature updates you didn't use (It's a service, and I don't care about their fixed costs, I went into it knowing I'd have a license for the signatures as they were expired), I do understand where they are coming from for software/firmware development. Unfortunately, they don't decouple the two. Maybe I'm just a grinch, but I think they could fix this problem. If they set the software in the box so that on the day your subscription expires it no longer processes the subscription data there would be a lot less issue. At that point why should they sell iron at all? Seems like you get all of the downside of owning the iron, and all of the downside of paying for a cloud based service. Either you own what you own, or you pay for service that somebody else provides. This "you bought useless hardware unless you pay up" is really what's infuriating. Mike
Re: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again...
In a message written on Thu, Dec 22, 2011 at 12:26:56PM -0600, PC wrote: > This particular product is often used by the SMB types. This changes > things a bit. While I disagree with paying for signature updates you > didn't use (It's a service, and I don't care about their fixed costs, I > went into it knowing I'd have a license for the signatures as they were > expired), I do understand where they are coming from for software/firmware > development. Unfortunately, they don't decouple the two. Maybe I'm just a grinch, but I think they could fix this problem. If they set the software in the box so that on the day your subscription expires it no longer processes the subscription data there would be a lot less issue. The problem here is they let the system use the old signature data, and that data is useful for a while. The day after a contract expires, you're still getting 99.9% of th benefit, a week later 95%, and so on. They've essentially been too nice in letting the software be leniant with the signature data, and they they pay for it in terms of customer relations when they try to do renew. Do they let customers renew every 13 months, effectively getting one month free each year while they run on old subscription data, or do they play hardball and make them "true up" with a backdated contract. It's really a no-win choice for them. I suspect if someone came in here saying "my Baracuda stopped filtering out spam the day my contract expired" there would be no love for that person, they would be told "yeah, so renew your contract if you want the service to work". While making it stop working may seem less customer friendly, I think it actually ends up more. Everyone knows where they stand, and the poor engineer trying to get his management to renew it now has a nice club to use internally rather than the current "nothing happens if we ignore it, at least in the short term." -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpL3MwQCfWlY.pgp Description: PGP signature
RE: bgp update destroying transit on redback routers ?
Olivier, Thanks! We've done our best to provide the fix ASAP. Regards, Jeff -Original Message- From: Olivier Benghozi [mailto:olivier.bengh...@wifirst.fr] Sent: Thursday, December 22, 2011 5:20 AM To: nanog@nanog.org Cc: Alexandre Snarskii; Jeff Tantsura Subject: Re: bgp update destroying transit on redback routers ? Aha, it looks that our Quebecer friends from Hostlogistic (AS46609) have again been advertising their now famous funny aggregate with their mad Brocade router, since yesterday 10pm UTC (that is 5pm in Quebec)... Same route to 206.125.164.0/22, same AGGREGATOR attribute full of 0. At least I can say that the patched Ericsson's bgpd stopped reseting the sessions. regards, Olivier Le 2 déc. 2011 à 23:14, Jeff Tantsura a écrit : > Hi Alexandre, > > You are right, the behavior is exactly as per RFC4271 section 6: > "When any of the conditions described here are detected, a > NOTIFICATION message, with the indicated Error Code, Error Subcode, and Data > fields, is sent, and the BGP connection is closed. > So because ASN 0 in AGGREGATOR is seen as a malformed UPDATE we send 3/9 and > close the connection. > > Ideally it should be treated as "treat-as-withdraw" as per > draft-chen-ebgp-error-handling, however please note - this is still a draft, > not a normative document and with all my support it takes time to implement. > > Once again, we understand the implications for our customers and hence going > to disable ASN 0 check. > > P.S. We have strong evidence that the update in question was caused by > a bug on a freshly updated router (I'm not going to disclose the > vendor) > > Regards, > Jeff > > > -Original Message- > From: Alexandre Snarskii [mailto:s...@snar.spb.ru] > Sent: Friday, December 02, 2011 6:36 AM > To: Jeff Tantsura > Cc: nanog@nanog.org > Subject: Re: bgp update destroying transit on redback routers ? > > On Thu, Dec 01, 2011 at 04:56:43PM -0500, Jeff Tantsura wrote: >> Hi, >> >> Let me take it over from now on, I'm the IP Routing/MPLS Product >> Manager at Ericsson responsible for all routing protocols. >> There's nothing wrong in checking ASN in AGGREGATOR, we don't really >> want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 >> (draft-ietf-idr-as0-00) came into the worlds. > > This draft says that > > If a BGP speaker receives a route which has an AS number of zero in the > AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a > WITHDRAW. This same behavior applies to routes containing zero as the > Aggregator or AS4 Aggregator. > > but observed behaviour was more like following: > > If a BGP speaker receives [bad route] it MUST close session immediately with > NOTIFICATION Error Code 'Update Message Error' and subcode 'Error with > optional attribute'.
Re: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again...
This particular product is often used by the SMB types. This changes things a bit. While I disagree with paying for signature updates you didn't use (It's a service, and I don't care about their fixed costs, I went into it knowing I'd have a license for the signatures as they were expired), I do understand where they are coming from for software/firmware development. Unfortunately, they don't decouple the two. However, this particular vendor is bad in a market where gear often passes hands or goes lapsed for years. After a certain point (IE: 1 yr), you shouldn't have to true-up. This particular company makes your 3-year lapsed appliance pay for 3 years of missed updates, at which point you might as well just throw it in the garbage. Same thing with my license plates -- if they go for 11 months or less, I have to "true up". If I put a car in storage for over a year, I can purchase a new registration. On Thu, Dec 22, 2011 at 11:04 AM, James M Keller wrote: > On 12/21/2011 3:22 PM, David Swafford wrote: > > In my position within the enterprise vertical, backdating to the > > expiration (not the payment date) seems to be the norm. Cisco does > > this on SmartNet, as does SolarWinds and a number of other vendors > > I've worked with. We don't typically slip on the dates intentionally, > > but our procurement and legal groups have a habit of fighting over > > wording on the contracts. > > > > David. > > > > > > Having worked in the past at a shop that sold managed support agreements > for software we sold - the overhead for staffing and code and > blacklisting type data sets are spread out in the yearly support > agreement.A lapsed customer has not funded the delta changes in code > and data set from lapsed data to renewal date, but will get to take > advantage of the work. > While a new customer also will not fund these on a new starting > contract, that is normally considered some cost of acquiring new > business. > > Now in some cases on the other end of the transaction I've found it > cheaper to buy 'new' then it was to 'true up' the support.I haven't > found a vendor that wouldn't go that route, even if it involved getting > some escalation on the sales side first.At that point it's the cost > of customer retention vs new business that the vendor needs to worry > about.However if you are happy with the product, and the renewal > isn't more then 'new' purchases - we all shouldn't be baulking having to > 'true up' contracts. > > -- > --- > James M Keller > > >
Re: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again...
On 12/21/2011 3:22 PM, David Swafford wrote: > In my position within the enterprise vertical, backdating to the > expiration (not the payment date) seems to be the norm. Cisco does > this on SmartNet, as does SolarWinds and a number of other vendors > I've worked with. We don't typically slip on the dates intentionally, > but our procurement and legal groups have a habit of fighting over > wording on the contracts. > > David. > > Having worked in the past at a shop that sold managed support agreements for software we sold - the overhead for staffing and code and blacklisting type data sets are spread out in the yearly support agreement.A lapsed customer has not funded the delta changes in code and data set from lapsed data to renewal date, but will get to take advantage of the work. While a new customer also will not fund these on a new starting contract, that is normally considered some cost of acquiring new business. Now in some cases on the other end of the transaction I've found it cheaper to buy 'new' then it was to 'true up' the support.I haven't found a vendor that wouldn't go that route, even if it involved getting some escalation on the sales side first.At that point it's the cost of customer retention vs new business that the vendor needs to worry about.However if you are happy with the product, and the renewal isn't more then 'new' purchases - we all shouldn't be baulking having to 'true up' contracts. -- --- James M Keller
Re: IPv6 RA vs DHCPv6 - The chosen one?
On 12/21/2011 11:28 PM, William Herrin wrote: > On Tue, Dec 20, 2011 at 1:27 AM, Ravi Duggal wrote: >> We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends >> DHCPv6 to do what RA does. And now, we have >> draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise >> the NTP information that is currently done via DHCPv6. >> >> My question is, that which then is the more preferred option for the >> operators? > "Yes." > > We want both. We'll try both. And in a couple years when the > percentage Internet use of IPv6 is out of the single digits, we'll let > you know what worked in which situations. > > We probably don't need one configuration protocol to rule them all. > IPv4 has PAP/CHAP over PPP and DHCP over Ethernet plus a number of > more minor ones like bootp (DHCP's semi-compatible predecessor) and > rarp. We really don't suffer for the choice. > > Regards, > Bill Herrin > > > Yes +1 I would consider RA+SLAAC for residential/hotel/company guest, etc. Any place you don't care about host configuration tracking, authentication, accounting, etc. DHCPv6 for fully managed environments with NAC / Auditing requirements. DHCPv6 would let you control per host/host class which router(s) on the network to use explicitly, vs RA with just preferences for each router. Both should be able to provide the same type of information, and let the administrators choose which deployment method meets the requirements for their environment. -- --- James M Keller
Help with quagga BGP config for ipv6 route-server
I am trying to set up BGP peering with a route-server, concurrently dual-stack.
BGP 4 over an IPv4 connection works fine. A separate BGP 6 over IPv6 fails:
with an "[Error] No common capability".
I am using quagga 0.99.20 on ubuntu 10.04.03. I don't know what the
route-server is.
I have tried to tell both quagga to not be strict about capabilities or not
negotiate them at all.
My quagga config includes:
router bgp XX
no bgp enforce-first-as
no bgp default ipv4-unicast !! tried with and without this
bgp router-id XX
network XY/24 route-map SetAttr
neighbor XX4 remote-as XX
neighbor XX4 activate
neighbor XX4 next-hop-self
neighbor XX4 send-community
address-family ipv6
network XY6/48 route-map SetAttr
neighbor XX6 remote-as XX
neighbor XX6 activate
neighbor XX6 next-hop-self
neighbor XX6 send-community
neighbor XX6 soft-reconfiguration inbound
The code, I think, that's triggering the error is:
/* Check there is no common capability send Unsupported Capability
error. */
if (*capability && ! CHECK_FLAG (peer->flags, PEER_FLAG_OVERRIDE_CAPABILITY))
{
if (! peer->afc_nego[AFI_IP][SAFI_UNICAST]
&& ! peer->afc_nego[AFI_IP][SAFI_MULTICAST]
&& ! peer->afc_nego[AFI_IP][SAFI_MPLS_VPN]
&& ! peer->afc_nego[AFI_IP6][SAFI_UNICAST]
&& ! peer->afc_nego[AFI_IP6][SAFI_MULTICAST])
From tcpdump, my side's open message includes:
Open Message (1), length: 57
Version 4, my AS XX, Holdtime 180s, ID XX4 !! XX4 is my V4
address
Optional parameters, length: 28
Option Capabilities Advertisement (2), length: 6
Multiprotocol Extensions (1), length: 4
AFI IPv4 (1), SAFI Unicast (1)
0x: 0001 0001
Option Capabilities Advertisement (2), length: 2
Route Refresh (Cisco) (128), length: 0
Option Capabilities Advertisement (2), length: 2
Route Refresh (2), length: 0
Option Capabilities Advertisement (2), length: 6
32-Bit AS Number (65), length: 4
no decoder for Capability 65
0x: e0c5
Option Capabilities Advertisement (2), length: 2
Unknown (66), length: 0
no decoder for Capability 66
The route-server's response is:
Open Message (1), length: 45
Version 4, my AS XX, Holdtime 240s, ID XY4 !! XY4 is his V4 address
Optional parameters, length: 16
Option Capabilities Advertisement (2), length: 14
Multiprotocol Extensions (1), length: 4
AFI IPv6 (2), SAFI Unicast (1)
0x: 0002 0001
To which I respond:
Notification Message (3), length: 27, OPEN Message Error (2), subcode
Capability Message Error (7)
When I add "dont-capability-negotiate" to the config, I send:
Open Message (1), length: 29
Version 4, my AS 57541, Holdtime 180s, ID XX4
Optional parameters, length: 0
I get back:
Open Message (1), length: 45
Version 4, my AS XX, Holdtime 240s, ID XY4
Optional parameters, length: 16
Option Capabilities Advertisement (2), length: 14
Multiprotocol Extensions (1), length: 4
AFI IPv6 (2), SAFI Unicast (1)
0x: 0002 0001
I respond:
Notification Message (3), length: 27, OPEN Message Error (2), subcode
Capability Message Error (7)
I'm a developer and former rfc writer, not a network operator.
thanks nanog,
--
David Waitzman
BBN Technologies
Re: bgp update destroying transit on redback routers ?
Aha, it looks that our Quebecer friends from Hostlogistic (AS46609) have again been advertising their now famous funny aggregate with their mad Brocade router, since yesterday 10pm UTC (that is 5pm in Quebec)... Same route to 206.125.164.0/22, same AGGREGATOR attribute full of 0. At least I can say that the patched Ericsson's bgpd stopped reseting the sessions. regards, Olivier Le 2 déc. 2011 à 23:14, Jeff Tantsura a écrit : > Hi Alexandre, > > You are right, the behavior is exactly as per RFC4271 section 6: > "When any of the conditions described here are detected, a > NOTIFICATION message, with the indicated Error Code, Error Subcode, and Data > fields, is sent, and the BGP connection is closed. > So because ASN 0 in AGGREGATOR is seen as a malformed UPDATE we send 3/9 and > close the connection. > > Ideally it should be treated as "treat-as-withdraw" as per > draft-chen-ebgp-error-handling, however please note - this is still a draft, > not a normative document and with all my support it takes time to implement. > > Once again, we understand the implications for our customers and hence going > to disable ASN 0 check. > > P.S. We have strong evidence that the update in question was caused by a bug > on a freshly updated router (I'm not going to disclose the vendor) > > Regards, > Jeff > > > -Original Message- > From: Alexandre Snarskii [mailto:s...@snar.spb.ru] > Sent: Friday, December 02, 2011 6:36 AM > To: Jeff Tantsura > Cc: nanog@nanog.org > Subject: Re: bgp update destroying transit on redback routers ? > > On Thu, Dec 01, 2011 at 04:56:43PM -0500, Jeff Tantsura wrote: >> Hi, >> >> Let me take it over from now on, I'm the IP Routing/MPLS Product >> Manager at Ericsson responsible for all routing protocols. >> There's nothing wrong in checking ASN in AGGREGATOR, we don't really >> want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 >> (draft-ietf-idr-as0-00) came into the worlds. > > This draft says that > > If a BGP speaker receives a route which has an AS number of zero in the > AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a > WITHDRAW. This same behavior applies to routes containing zero as the > Aggregator or AS4 Aggregator. > > but observed behaviour was more like following: > > If a BGP speaker receives [bad route] it MUST close session immediately with > NOTIFICATION Error Code 'Update Message Error' and subcode 'Error with > optional attribute'.
Re: IPv6 RA vs DHCPv6 - The chosen one?
> In many environments RA is a catastrophic disaster. Some operators need > to be able to do everything with RA turned off on routers, disabled on > hosts and filtered on switches. While in some environments, typically with small number of devices, its indispensable. Small businesses may not want the complexity of setting up a central server (for DHCP) - SLAAC works very well in such environments. Today, we can get NTP server information only with DHCP (DNS info is supported by both DHCP and RAs). DHCP only works after RAs have been processed. In some environments (mobile IPv6) delays in acquiring NTP and other servers information is critical and waiting for DHCP to come up may not be acceptable. Glen
