[167621] in North American Network Operators' Group
Re: turning on comcast v6
daemon@ATHENA.MIT.EDU (Eric Oosting)
Fri Dec 20 17:45:07 2013
In-Reply-To: <75E34391-D8F2-4AE8-932F-C58F6A23149B@ox.com>
Date: Fri, 20 Dec 2013 17:44:47 -0500
From: Eric Oosting <eric.oosting@gmail.com>
To: Matthew Huff <mhuff@ox.com>
Cc: nanog2 <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Fri, Dec 20, 2013 at 5:16 PM, Matthew Huff <mhuff@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 <owen@delong.com> wrote:
>
> >
> > On Dec 20, 2013, at 12:50 PM, Matthew Huff <mhuff@ox.com> wrote:
> >
> >>
> >> On Dec 20, 2013, at 3:23 PM, Owen DeLong <owen@delong.com> wrote:
> >>
> >>>
> >>> On Dec 20, 2013, at 6:29 AM, Matthew Huff <mhuff@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=92t 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=92s 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 statical=
ly
> 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 addresse=
s.
> They just don't. Some OS's won't disable SLAAC unless you disable autocon=
f
> on the switch. When you
> >
> > Not all devices have working IPv6 stacks. OK, they=92re broken, complai=
n
> 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 gatewa=
y
> 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 th=
e
> =93advantages" 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=92t work perfectly in the beginning either. Enterprises spent
> many years getting vendors to correct issues with their iPv4 products and
> we=92re just starting that process with IPv6.
> >
> > I=92m asking what=92s broken in the protocol design since that=92s 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 wi=
th
> 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 an=
d
> get them to fix their IPv6 implementations.
> >
> > Owen
> >
>
>
>
