[ipv6hackers] "Stick to limited IPv6 deployments, businesses warned"

[Tim Chown]

On 5 Sep 2012, at 20:59, Tomas Podermanski <tpoder at cis.vutbr.cz> wrote:

> On 9/4/12 11:41 PM, Tim Chown wrote:
>> 
>> http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01.txt
> 
> I know about that. Another very similar draft
> http://tools.ietf.org/html/draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01.
> However I haven't found any implementation of this yet. Neither hw
> devices nor sw packages like ISC DHCP supports it. So it isn't still
> option for today.

Not yet, but it seems to have support to move forward.  As you say, the big test is whether ISC implements it.  Based on the author list, I'm guessing Cisco will.

>>> Some more about that is on
>>> http://ipv6.vutbr.cz/article/flow-based-monitoring-of-ipv6/ (slide 6)
>>> and more detailed description in the article
>>> http://ipv6.vutbr.cz/article/design-of-data-retention-system-in-ipv6-network/.
>> We harvest the necessary information from switch/router devices. There's a few open source packages that do this.
> 
> What specific packages do you use? We currently use MetNAV
> (http://metanav.uninett.no/) for this purpose, but there are some
> disadvantages here. Similar project netdisco (http://www.netdisco.org/)
> have some supports for gathering neighbor cache from local network, but
> not from MIBs.

Ah, NAV, yes we use that along with some other customised stuff.  The NAV support team is very good; they've just taken on a full-time developer to push it forward, so may be even more amenable to new feature requests now.

I understand Cisco are working on something too, based on a discussion a couple of IETFs ago.

I just feel in a campus environment expecting to lock everything down to DHCPv6 is not realistic; hence, if you want accountability, you need to deploy harvesting/monitoring tools that do that job for you.

Tim