Hemant Singh (shemant) writes: > Ole and Dave agreed upon: "for PPP links we always know the link-layer > address". I too agree with that. Why issue an NS to resolve an address > on such a link when the address is always known? > > As for NUD, 2461 NUD sections also say if upper layer protocols can > determine reachability, NUD is not invoked.
Right. However, PPP is a lower-layer protocol. I don't know why TCP would be signaling address reachability, but that's what the RFC seems to allow. It says nothing about the link-layer itself signaling reachability. > 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. PPP has both signals from the physical layer (if present) and an optional LCP Echo-Request mechanism that can be (and often is) used to implement a link-layer keepalive. You're right that NUD shouldn't be needed, and yet that's just what RFC 2461 says. > The PPP interoperability problem that Dave raised is a general problem > outside of PPP too in that when a host is expected to forward data out > of the host, the host is performing address resolution. The default > router or other directly connected PPP client may not respond to this NS > causing the host to sit waiting for an NA. We have raised such a point > in 2nd paragraph of Introduction section of our I-D. So, why would a reasonable peer fail to respond to an NS? Even if you don't believe that the existing RFC requires the use of ND for point-to-point links, why would you fail to respond to a solicitation for your own address? > http://www.ietf.org/internet-drafts/draft-wbeebee-nd-implementation-pitf > alls-01.txt I don't see a reference to point-to-point links there. > Personally, I won't use address resolution or NUD in a PPP link. Further > I wouldn't also use DAD in a PPP link because I agree with text in RFC > 2472, section 5 that says > > "Therefore it is recommended that for PPP links with > the IPV6CP Interface-Identifier option enabled the default value of > the DupAddrDetectTransmits autoconfiguration variable [3] be zero." Note that IPv6 addresses can be configured manually and can potentially come from other sources that do not guarantee uniqueness. That doesn't sound like a good recommendation to me. The whole point to inventing IPCP (for IPv4) was because we had chaos on SLIP links, where fumble-fingered users would sometimes set the same address on both end, with hilarious results. Why duplicate that history? (However, I do like the idea of getting rid of that 'R' bit, at least in some cases. The less it's seen, the better.) > Further, all of us have agreed that PPP IPV6 ND behavior belongs in an > IPv6 RFC, not a PPP specific RFC. Strongly agreed. > I think RFC 2461bis is clear for PPP > ND behavior. Apparently, it's not. I've read it several times, and it still seems to support the same model as before, which is that NS is required, and that newly-created neighbor cache entries must go to INCOMPLETE state and use NS before becoming REACHABLE. There are no exceptions for point-to-point links that I can see, and the ones that others seem to be citing are ambiguous at best. > 7. Known IPv6 ND Implementation Problems . . . . . . . . . . . . 15 > 7.1. Incorrect host data forwarding behavior after > receiving an RA with no PIO . . . . . . . . . . . . . . . 16 > 7.2. A DHCPv6 host sending 9 NS(DAD)s . . . . . . . . . . . . . 20 > 7.3. Incorrect host behavior after automatic insertion of a > directly connected route during address acquisition . . . 22 > 7.4. Aggregation router sending Redirects when hosts > communicate to each other from behind different modems . 25 Nine DADs is a problem? It might be a local problem for the sender (it'll take a while to get that address ready), but it hardly seems like a serious implementation issue. Looking forward to reading that text. ;-} -- 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 [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
