> > Even if I did know the other side's global address, monitoring pings > > cannot be sent to fe80::2. We'll have to ping c001:cafe::2 and > > manually link that status with fe80::2 peering session on the NMS. > > I would hate to do that with hundreds of sessions running inside my network. > > That's always been a causes mistakes. We want to monitor what's > > acutally running and not some alias address. > > yes, I see that point. > how do you troubleshoot when you get a OSPFv3, RIP, or ISIS neighbor down > message? > cause then you'd only have a link-local address or a CLNS address. or is BGP > troubleshooting different in some way?
As of right now, we also have IPv4 addresses on the same links. The traps we receive normally include enough info (e.g. circuit id, interface name, IP address, whatever) that we can easily identify the link. Having links with only IPv6 link-local addresses *and* no further info included in the traps would be unacceptable. All our core links are configured with "normal" (global) IPv6 addresses. We are fully aware of the fact that the routers also use IPv6 link local addresses as *next hop* for most protocols (e.g. iBGP, IS-IS). We don't deal with these link local addresses at all under normal circumstances - instead we deal with the interface names that the routers also helpfully tell us. Similarly, all our IPv6 eBGP peerings are configured with global IPv6 addresses - here the IPv6 next hop is also a global IPv6 address. So, to sum up: yes, we know that the IPv6 link local addresses exist on our routers, no we don't normally "deal" with these addresses in any way. Steinar Haug, Nethelp consulting, sth...@nethelp.no -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
