Re: using "reserved" IPv6 space

[-Hammer- <bhmccie () gmail com>]

-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 () 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