Some thoughts on this thread... One problem with the statement/question: are p2p links required to use Neighbor Discovery, is defining exactly what ND is. ND is actually a suite of protocols, including:
- Router discovery - address resolution - Neighbor Unreachabilty Detection (NUD) - etc. For a p2p link, I think we all agree that Address Resolution is not necessary. But what about the other parts? > These implementations, instead of performing ND NS/NA, "blindly" forward > IPv6 packets onto directly onto the point-to-point link, regardless of > whether the destination address exists. If both ends of the link don't > perform ND NS/NA transactions, the packet will be looped back and forth > until it's hop count expires - i.e. the ping-pong problem. IMO, this is broken. Implementations should not blindly forward packets... > My broad understanding of the goal of moving neighbour discovery into > ICMP in IPv6, instead of having a separate protocol like ARP, was to > try to minimise the required number of layer 2 to layer 3 adaption > protocols required for IPv6. If a link layer could meet or emulate a > basic set of requirements, then standard ICMPv6 neighbor discovery > could operate over the link without any link specific changes. That was the intention. In practice, folk seem to want to make optimizations to not send packets if they are not strictly required, resulting in the current situation where running ND over a p2p link would work just fine, but is actually disabled. > When a prefix length is assigned to a link, it is specifying a range of > a addresses assigned to that link. In other words, within the > address space of the network, this link is the final destination for any > traffic directed towards both the assigned prefix and any addresses that > fall within the assigned range. > What a prefix length doesn't say is that the addresses are > specifically assigned to devices attached to the link, and that those > devices are available to send packets to. Actually, I think it does. By defintion, assigning an on-link prefix of /x to an interface by definition means all addresses covered by /x are on the attached link, and a sender should be able to send directly to them *WITHOUT* going through a router. The issue is that by defn, a p2p link has exactly two devices attached to it. So having a /x assigned to the link, where /x covers many addresses (e.g., a /64), doens't make sense. We know most of the addresses are not really on the link. Conceptually, a sender that sees such an address should conclude that the destination is on the directly attached link and attempt to send it. And apparently implementations just "blindly" send such packets and they end up at the other end of the p2p link, which then does the same thing causing the packet to loop. IMO, it is an error for a sender to send a packet on a p2p link, when the destination is considered "on-link" unless the packet is truly addressed to the node at the other end of the p2p link. Architecturally, that is where the implementation flaws are. Forwarding a packet to the other end of the link, when the sender should know that the destination is not at the other end of the link is IMO broken. Running ND (and address resolution in particular) in this case to verify that the recipient is actually on the link would solve the problem. But so would other techniques. > If a protocol chooses to generate Destination Unreachable messages, > then, despite the prefix length assigned to a link, including one that > only allows for "another" address, such as a /127, then it must probe > addresses for availability. The IPv6 ND RFC says it MUST - > "If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT > solicitations, address resolution has failed. The sender MUST return > ICMP destination unreachable indications with code 3 (Address > Unreachable) for each packet queued awaiting address resolution." > So these implementations that aren't implementing ND NS/NA on > point-to-point links can't generate ICMP destination unreachables, > because they're not probing for individual address assignment and > availability. Allowing a /127 prefix length in IPv6 won't fix that. This is not entirely true. The above is about how to handle the case where one attempts address resolution, and that fails. One should then send an ICMP error. However, that does not mean that the only time one can send an ICMP unreachable is after ND fails. It would be perfectly OK to send an ICMP unreachable upon discovering that one is sending to a destination covered by the on-link prefix, but does not correspond to addresses at the other end of the of the p2p link. > In summary, it seems to me that IPv6 Neighbor Discovery Address > Resolution is serving two purposes - > o resolution of layer 3 addresses to layer 2 addresses > o testing the availability of layer 3 addresses, for the purpose of > generating Destination Unreachable Messages See above. ND is also about NUD... Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
