Hemant Singh (shemant) writes: > I am saying when the M bit is clear, then a node cannot acquire an > address using DHCPv6. However, I agree with you DHCPv6 is much better > alternative than PPP. > > Now, I'd like to focus the discussion back to how will the PPP peer > (which is a server)
Nit: PPP doesn't define "client" or "server." It's peer-to-peer. > going to fix the bug when this peer hasn't responded > to the NUD unicast NS? I have already said the source PPP client that > issued the unicast NS is 2461bis complaint. I don't think it should "fix" the problem. If the peer fails to respond as expected, it has to declare the remote address to be unreachable. I'm not sure why we'd necessarily expect the side that's working right to work around bugs in the other side. (In fact, it could be argued that this is a good state of affairs: malfunctioning gear may in fact have other bugs, and it's better to detect this early rather than later.) Yes, it'd be possible to carve out a hole in NUD and say that if there's _never_ a response from the peer to any NS for the life of the link, and if the link is specifically point-to-point and without link layer addresses, and if the link-layer is known to perform keepalive- like operation, then the NS sender could "assume" that the address is actually reachable. That seems like needless complexity to me, though. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
