using "reserved" IPv6 space

Mon Jul 16 18:26:08 UTC 2012

On the HSRP/ND part , this all falls in the First Hop redundancy areana
and can be achieved via any of the following and each has its merits and
cons..

1) Using ND -- need to tune the "IPv6 nd reachable time" to achieve the
faster failover
2) Using any of the First hop redundancy protocol ( HSRP, VRRP , GLBP)
3) Default route selection.

So depending on the network convergence need  etc , any  or combination of
above can be looked at.

Thx
Rajendra 

On 7/16/12 9:09 AM, "-Hammer-" <bhmccie at gmail.com> wrote:

>Inline -
>
>-Hammer-
>
>"I was a normal American nerd"
>-Jack Herer
>
>
>1) (This one is currently a personal issue) I am still building up a true
>IPv6 skillset. Yes, I understand it for the most part but now is the time
>to apply it.
>
>Frankly, IMHO, the best way to build up a truly useful IPv6 skill set is
>to start applying what you don't know and see what happens. For the most
>part, you will find that it is truly "96 more bits, no magic".
>
>------- Completely agree. Been playing in GNS3 on the basics and we're
>starting to play in a full lab soon.
>
>> 2) All the reading you do doesn't prepare you for application and the
>>vendors aren't necessarily helping. Feature parity across platforms and
>>vendors beyond just "interface x/x/x" and "ipv6 address
>>fe80:blah:blah::babe:1" seems to seriously be lacking. When I try to
>>take what I understand and apply it beyond the basics I often see
>>hurdles.  Example? HSRP IPv6 global addressing on Cisco ASR platform. If
>>it's working for you hit me offline. Example2? Any vendor product beyond
>>a router or switch. CheckPoint FW? F5 LB? Netscaler LB or AF? The WAN
>>guys may be rolling deep in IPv6 but not everyone else. I just got an EA
>>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
>>the customers so there was no need to make an effort....
>
>You probably meant 2001:db8:b1aa:b1aa::babe:1  (blah isn't hex and
>fe80::/10 is link local. 2001:db8::/16 is the example prefix)
>
>------- I stand corrected. :)
>
>   For the most part, HSRP really isn't even necessary or useful in IPv6
>since ND should take care of what HSRP did for IPv4.
>
>
>------- On the WAN? Sure. On my Internet facing equipment? I disagree.
>RAs and ND and all that fun stuff needs to be suppressed.
>  
>
>  I believe F5 has rolled out IPv6 in a subset of their products and that
>you need pretty recent versions to get IPv6 functionality from them. The
>ARIN Wiki (http://www.getipv6.info) may be a good source of information
>on various vendor statuses. Contribute what you know/find out there as
>well, please.
>
>
>------- Yes they have and NetScaler is running solid as well. My issues
>are when you go beyond basic features of any product with IPv6 things get
>tricky. I need content switching with redirects and whatnot and based on
>the few efforts I've seen so far I'm not optimistic. Again, routers and
>switches seem to be further ahead than other products. They all have
>their limits in advanced features. Back to my ASR comment.
>  
>
>Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is
>being able to eliminate NAT. NAT was a necessary evil for IPv4 address
>conservation. It has no good use in IPv6.
>
>
>-------That is clearly a matter of opinion. NAT64 and NAT66 wouldn't be
>there if there weren't enough customers asking for it. Are all the
>customers naive? I doubt it. They have their reasons. I agree with your
>"purist" definition and did not say I was using it. My point is that
>vendors are still rolling out baseline features even today.
>
>> 3) When I'm not preoccupied attempting to digest the fundamentals I am
>>well aware of the retooling of the brain that is required for this in a
>>network design. Last year I reached out to Team Cymru and attempted to
>>build an IPv6 router template to match their IPv4 template. It was a
>>completely different animal. Ironically most of the STIGs and NSA
>>reference garbage I used was ten years old but still applied. After
>>going thru all those docs my brain hurt trying to orient my ACLs
>>properly and go thru all the different attributes you want to block
>>where and when. Then I spent some time trying to work our design schemas
>>for our ARIN space with the WAN design team. What I'm trying to say is
>>that Roberts comments are spot on. It is a very different way of
>>thinking on a small scale and a large scale and you can't take your IPv4
>>logic and apply it. I've tried and it's just slowing me down.
>
>Yes and no. If you have been doing IPv4 long enough to remember pre-NAT
>IPv4, then, you just need to remember some of the old ways of IPv4. If
>you have no recollection of IPv4 without NAT, then, you are correct, it
>is a huge paradigm shift to go back to the way the internet is supposed
>to have been before we ran out of addresses.
>
>
>------- This isn't specific to you Owen, but the group in general. I have
>been around for a while. Not as long as some others here. NAT is a
>feature and it does have a place. Security. I'm sorry that this
>frustrates people but security is a layered approach and it starts off
>simple. If you have a network that doesn't need exposure to the Internet
>or to someone else you can get fancy with anything from a FW to control
>source and destination or AD controls so only the accounting team can get
>in. Sure. They all work. You can also NAT them. Make them invisible. Or
>null the traffic. The more fundamental the point of defense is the easier
>it is to understand and sometimes the more difficult it becomes to
>bypass. Complex security adds a greater potential for vulnerabilities. If
>you want to protect your car stereo you could lock a cover over it right?
>But if you could, wouldn't you also just lock the car doors when you
>leave it? I'm not going to tell you that NAT guarantees you anything. We
>all know nothing is foolproof. But it is a fundamental feature that works
>for that purpose. Do I plan on NATting our edge Internet traffic? No. Not
>for IPv6. Because the protocol was not designed for it. But have I ruled
>it out as an option for some environments? No.
>
>Bring on the flames. I know this is going to get people stirred up. I
>promise not to ignore the thread....
>  
>
>
>
>