#262 IPv6 Support

[Oliver Gorwits]

11:58 < JvI_work> 16:16:27< JvI_work> ok, quick update on IPv6:
11:58 < JvI_work> 16:16:53< JvI_work> SNMP::Info has the lldp_addr() method that returns LLDP neighbor advertised management address
11:58 < JvI_work> 16:17:47< JvI_work> which only implemented IPv4 and MAC types and is a sort of roulette as to which is returned to the caller, if 
                  a neighbor advertises more than one
11:58 < JvI_work> 16:18:27< JvI_work> ...but lldp_ip() was also present which will only return IPv4
11:58 < JvI_work> 16:19:19< JvI_work> so I added IPv6 support to lldp_addr() and updated the docs that it does not return everything that a remote 
                  advertises
11:58 < JvI_work> 16:19:48< JvI_work> and then added lldp_ipv6() and lldp_mac() to return remote IPv6 and MAC management addresses, if present.
11:58 < JvI_work> 16:21:34< JvI_work> Haven't had time to do more on the Netdisco side, maybe next week. Did test the SNMP::Info methods against 
                  IPv6 enabled HP switches though, looks good.
11:58 < JvI_work> (Sep 4 2015)
12:02 < JvI_work> Looks like the above SNMP::Info changes went into release 3.29
12:03 < JvI_work> ...so I guess the next step is to make some changes to Netdisco to collect this info, store it in the DB and display it.

08:24 < JvI_worq> oliver: yes, generally you'd want to reduce all results from neighbor discovery protocols down to unique neighbors. IMHO that's a 
                  task for Netdisco, because once a neighbor is discovered, Netdisco knows all its IPv4, IPv6 and MAC addresses.
08:25 < JvI_worq> I guess extending Netdisco with IPv6 support for devices should start with storing the IPv6 addresses & prefixes (cf subnets)
08:25 < JvI_worq> processing neighbor entries for IPv6 would be a logical next step
08:26 < JvI_worq> and maybe then optimizing the processing of neighbor entries...