On Fri, Dec 20, 2013 at 5:16 PM, Matthew Huff <mh...@ox.com> wrote: > Owen, > > Have you ever worked in a corporate environment? Replacing equipment can > be a 5-7 year window and has to be justified and budgeted. Replacing a > piece of equipment because it's an incomplete IPv6 implementation (which > has changed considerably as it has been deployed), isn't feasible.
Not to put words in Owen's mouth, but let me explain how I interpret what he was saying: Vote with your feet. It's simple ... maybe you can't replace everything in your network that doesn't support IPv6, ( I wish we all had that kind of discretionary budgets) but you can still base purchasing decisions on IPv6 support, and by and large, that isn't happening. Enterprise purchasing just isn't driven by IPv6 features ... if anything, its a check box feature for vendors and ignored by decision makers. Until the enterprise says to the widget salesperson: "i'm not buying this until and unless you truly commit to supporting IPv6" we're stuck where we are. We don't necessarily need you to replace everything in your network that doesn't support it today, we need you to not put a single thing in your network new, or used, that doesn't. Believe me, the vendors will get the message and suddenly even the legacy stuff will start to be fixed. Remember what a PITA it was to get novel to support IPv4? They didn't do it until they had to. -e > There are a lot of things that have changed as IPv6 has been deployed > such as DHCPv6 (not even talking about setting default GW via DHCP, but > things such as DNS servers, DNS domain name, etc). Not all vendors > especially ones in niche markets can update the firmwares that often, and > certainly not unless they have a business justification. > > > > On Dec 20, 2013, at 4:07 PM, Owen DeLong <o...@delong.com> wrote: > > > > > On Dec 20, 2013, at 12:50 PM, Matthew Huff <mh...@ox.com> wrote: > > > >> > >> On Dec 20, 2013, at 3:23 PM, Owen DeLong <o...@delong.com> wrote: > >> > >>> > >>> On Dec 20, 2013, at 6:29 AM, Matthew Huff <mh...@ox.com> wrote: > >>> > >>>> With RA, what is the smallest interval failover will work? Compare > that with NHRP such as HSRP, VRRP, etc with sub-second failover. > >>> > >>> RA and VRRP are not mutually exclusive. What you can’t have > (currently) is routing information distributed by a DHCP server which may > or may not actually know anything about the routing environment to which it > is sending such information. > >>> > >>>> In corporate networks most of the non-client systems will be > statically addressed with privacy addresses turned off. This is for > regulatory, audit, security and monitoring requirement. One of the many > challenges of ipv6 in a corporate environment. > >>> > >>> There’s no problem doing this in IPv6. You can easily statically > address a system and you can easily turn off privacy addresses. You can > even do that and still get your default router via RA or you can statically > configure the default router address. > >>> > >>> As such, can someone please explain what is the actual missing or > problematic requirement for the corporate world? > >>> > >>> Owen > >> > >> Reality. > >> > >> Owen, not all OS and especially hardware appliances (dedicated NTP > appliances, UPS cards, ILO), etc... will work with RA and static addresses. > They just don't. Some OS's won't disable SLAAC unless you disable autoconf > on the switch. When you > > > > Not all devices have working IPv6 stacks. OK, they’re broken, complain > to the vendor and get them to fix their product or buy a working product > from a different vendor. > > > >> do that, they loose the ability to pickup RA. Some will only work with > link local gateway addresses, some will only work with link global gateway > addresses. There is a lot of cruft out there in the enterprise world that > claims IPv6 > > > > Link Local gateway addresses are required functionality in IPv6. A > device which requires a global gateway address is > > broken. See above. > > > >> compatibility, but in the real world doesn't work consistently. Almost > all can be made to work, but require custom configuration. Far too much > work for many organizations to see value in deployment. In at least on IT > department I know of, IPv6 is banned because the CIO read about one of the > “advantages" of IPv6 is bringing back the p2p model of IP, and most > corporate management has zero interest in having any p2p connectivity > within their network. > > > > IPv4 didn’t work perfectly in the beginning either. Enterprises spent > many years getting vendors to correct issues with their iPv4 products and > we’re just starting that process with IPv6. > > > > I’m asking what’s broken in the protocol design since that’s what the > IETF can attempt to fix. > > > > > >> For our desktop environments (Windows 7 and RHEL6) we have two > different configurations on the switches on separate VLANs using SLAAC with > DHPCv6 and that works fine with RA announcing the NHRP. Other equipment, > not so much. > > > > Sounds like you need to contact the vendors for that other equipment and > get them to fix their IPv6 implementations. > > > > Owen > > > > >
