Let's clear the air. I agree with Srihari's email on IPV6CP and new options. Now let's see what the PPP interop issues are:
The sender PPP node is ND compliant when it issues a unicast NS for NUD before sending any data. The PPP peer of this sending node has a bug as to why the peer is not responding with an NA? Let's focus on this interop issue rather than asking for 2461bis or PPP to be changed. It's an orthogonal issue to ask if one should change 2461bis that requires an IPv6 node to perform reachability detection before communicating with another node. As for any changes needed by PPP and IPV6CP, do note, DHCPv6 cannot be used for other options and addresses in PPP if the client is SLAAC. Hemant -----Original Message----- From: Ole Troan (otroan) Sent: Thursday, July 19, 2007 6:52 PM To: James Carlson Cc: Hemant Singh (shemant); [EMAIL PROTECTED]; JINMEI Tatuya / ????; ipv6@ietf.org; Dave Thaler Subject: Re: Neighbor Discovery and PPP links >> 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 ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
