Hemant Singh writes: > Hemant Singh writes: > > [...] Why does PPP need NUD if PPP > > control protocol supports keepalive for the data connection - if > > keepalive is missed, the PPP connection will be terminated. > > Because addresses (e.g. RFC3041 addresses, manually configured > addresses, addresses derived from a prefix which is no longer being > advertised in the RA, etc.) can go away even though the PPP connection > stays up. > > <hs> Not quite. If the network layer in PPP link has to send packets, > then a new NCP session has to be established and IPV6CP (as defined in > RFC 2472 to be NCP protocol for PPP over IPv6) will negotiate the new > addresses of both ends. I expect that even when an IPv6 PPP end point is > manually configured, there are means available on the client to enforce > a new IPV6CP session. Once the new address is negotiated by IPV6CP, PPP > keepalive will maintain reachability. Am I missing anything here?
Yes, you don't need IPv6CP to add addresses. IPv6CP negotiates an interface identifier that can be used with stateless addrconf. The client can construct as many other interface identifiers as it wants (e.g. for RFC3041 addresses) and need not use IPv6CP for them, but it does have to do DAD for them. [...] > > Personally, I won't use address resolution or NUD in a PPP link. > > Then you will fail in cases like the one I noted above, and you won't be > RFC compliant. RFC2461 requires NUD on _all_ links. (I don't think > anyone is arguing it doesn't.) > > <hs> No. See my response above. On a related note, as you and Ole have > agreed upon, a PPP link always knows the link-layer address, so this PPP > interoperability problem you reported can be fixed if the PPP client > never issues an NS for address resolution - this is a mcast NS, not a > unicast NS that is sent by NUD. I'm not talking about mcast NS's in my response you're saying No to. I'm talking about unicast NUD. Unicast NS's are used on all links (except for router-to-router links that you have some other mechanism for) per RFC2461. [...] -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
