-Hammer-
"I was a normal American nerd"
-Jack Herer
On 7/16/2012 11:18 PM, Jimmy Hess wrote:
On 7/16/12, -Hammer- <bhmc...@gmail.com> wrote:
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)
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
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.
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
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