>> All I am saying is, if IPV6CP is used to negotiate one interface-id, >> when multiple addresses, that Dave pointed out, are needed for the same >> client, why not use IPV6CP to negotiate interface-id's for even these >> addresses? > > We'd have to discuss that on the PPP list, but my take on it is that > it'd likely be incompatible with existing implementations. I don't > know that anyone expects more than one IPV6CP Interface-Identifier > option -- I know for certain that the open source ppp-2.4 > implementation wouldn't handle it right. > > I think it'd be pretty strange operationally as well. You'd end up > with multiple link-local addresses. > > I don't think I agree with pushing this issue down into PPP. We don't > do that for Ethernet, so why would PPP be special?
I second that. the whole point of ND not being ARP was to allow for the same provisioning mechanisms to be used on multiple media. lets not go down the IPCP rathole. before we redesign the rest of IPv6. have we reached consensus on the original question yet? i.e is it required that an IPv6 node before communicating with another node performs reachability detection using NS/NA? to me it is pretty clear that answer has to be no. in common deployments a node doesn't know the next-hop address anyway. if a clarification is needed to emphasise that the neighbour discovery protocol must be supported on any multicast capable link, then I will not object to that. /ot -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
