Hemant Singh (shemant) writes: > Hemant Singh (shemant) writes: > > 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. > > <hs> I know PPP is a p2p model. I was using the term server to refer to > the server bug in the PPP Interop problem that Dave explained. This is > what Dave said:
Yes; I saw that. Part of the disconnect here is in the use of NBMA as a representation of a collection of PPP links. That seems like one of the real hazards. > common interface. Hence from the server's perspective, it's not a > point-to-point link, but rather an NBMA link. From the client's > perspective, the client thinks it's a point-to-point link, and there's > no way to discover that the server thinks otherwise.] I think that's yet more reason to treat all links as equal and use the same procedures everywhere. However, even if we got this issue cleared up, I think there's still a problem with the NBMA representation. From the server's point of view, the clients all must have some sort of link-layer address so that they can be distinguished. From the client's point of view, no such address is known or knowable. This implies that the client cannot create reasonable response because it cannot fill in the SLLA option correctly. Either the server's NBMA-synthesizing code needs to fix this up, or it's going to take yet more hacks to the neighbor discovery state machine to make it run right. (Essentially assuming that these NBMA peers have already-known addresses.) > > 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. > > <hs> But the peer is reachable in this p2p model ! Some bugs can result in a lack of connectivity. This looks like one of them. My question here is why this specific bug should be considered special enough that we ought to carve out exceptions in order to make it work. Why is that? If some system had gotten the checksum computation or byte order wrong in some field, we wouldn't write workarounds for those errors as well, would we? > 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. > > <hs> Let's not start preparing text for changes to 2461bis for PPP > unless we can first discuss what to do about the server bug that Dave > pointed out. I'm not trying to prepare any changes for 2461bis, except to show how complicated it would be in order to carve out the exception that I think you're proposing here. -- 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 --------------------------------------------------------------------
