using "reserved" IPv6 space
-Hammer-
bhmccie at gmail.com
Tue Jul 17 12:27:45 UTC 2012
-Hammer-
"I was a normal American nerd"
-Jack Herer
On 7/16/2012 11:18 PM, Jimmy Hess wrote:
> On 7/16/12, -Hammer- <bhmccie at 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
>
More information about the NANOG
mailing list