hurdles. Example? HSRP IPv6 global addressing on Cisco ASR platform. If HSRP is a legacy proprietary protocol; try VRRP. Stateless autoconfig and router advertisements can obviate (eliminate/reduce)
On 7/16/12, -Hammer- <bhmccie@gmail.com> wrote: the need in many cases; albeit, with a longer failure recovery duration. This isn't PAGP vs LACP again is it? Can someone show me a sunset document for HSRP from Cisco? Yes, VRRP, I use it as well. But that's not the point. The point is that it's a feature from a vendor that lacks
this morning from CheckPoint for NAT66. This should have been ready for prime time years ago. I guess the vendors weren't getting the push from NAT66; you're talking about something that is not a mainline feature, an experimental proposition; RFC6296 produced in 2011. Very few IPv6 deployments should require prefix translation or any kind of NAT technology with IPv6, other than the IPv4 transition technologies.
So... NO.. they should not have had this ready "for prime time" years ago. I disagree. I was asking security vendors what they were doing about
-Hammer- "I was a normal American nerd" -Jack Herer On 7/16/2012 11:18 PM, Jimmy Hess wrote: parity across the product suites. Like most of the folks out there, I run IOS, NX-OS, IOS-XE, etc and that's just from Cisco. Feature parity is a big gripe that doesn't have an easy solution. I feel for the vendors but at the same time I'm frustrated when I read a document on a function and realize afterwards I can only deploy it on "some" of my up to date products. That's the point. these kinds of future needs years ago. Many years ago. They all conceded that they had had similar requests from other customers but the demand wasn't there yet. They should have had more vision on their road maps but they focused on basic functionality of the protocol and not features beyond that and now they are playing catch up. I understand, they were focused on what features were getting the attention. That's business. But everyone knew the depletion rates and everyone knew that whether the pompous USA wanted it or not IPv6 was coming in the late 2000s and early 2010s. So they should have been more diligent. You can pull up any marketing document from any vendor and they will tell you IPv6 is fully supported. But when you implement features (who the heck runs a default config these days?) you really test the functionality of the product.
There are other things they should have been working on, such as getting the base IPv6 implementation correct, V6 connectivity, V6-enabled protocols, support for the newer RA/DHCPv6 options, and support for the newer more fully baked IPv4 transition specs such as 6to4, NAT-PT, and bugfixing.
I'll take the stable platform, that has the standards-specified features, over one with bells and whistles, and the latest experimental draft features such as 6to6, that are not required to deploy IPv6, thanks. I agree. Stability. But a stable platform that doesn't have the features I need is not a stable platform I can invest in. Cart before horse.
-- -JH