Hi Dave, (Is something up with the 6man mailing list? I've had a few replies, including one from Philip, none of them have CC'd ipv6@ietf.org, nor have I seen any replies via the list, and yet below seems show that a copy of Philip's email made it through. I have received a 3 I-D action emails via the list since I posted. I'm pretty sure nothing has changed in my email client to stop it showing or processing CC's. Quite strange.)
Question at the end. On Tue, 13 Jul 2010 23:12:17 +0000 Dave Thaler <dtha...@microsoft.com> wrote: > > -----Original Message----- > > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > > Philip Homburg > > Sent: Tuesday, July 13, 2010 8:02 AM > > To: Mark Smith > > Subject: Re: ND NS/NA support required on point-to-point links? > > > > In your letter dated Sun, 11 Jul 2010 12:03:43 +0930 you wrote: > > >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. > > > > The problem is that for some reason access providers tend to disable > > support for > > ND on point-to-point links. Which in turn requires stacks on consumer > > machines > > to disable it as well. > > > > I have 4 point-to-point links and last time I checked, none of them support > > ND. > > From RFC 4861: > > Unless specified otherwise (in a document that covers operating IP > > over a particular link type) this document applies to all link types. > > However, because ND uses link-layer multicast for some of its > > services, it is possible that on some link types (e.g., Non-Broadcast > > Multi-Access (NBMA) links), alternative protocols or mechanisms to > > implement those services will be specified (in the appropriate > > document covering the operation of IP over a particular link type). > > The services described in this document that are not directly > > dependent on multicast, such as Redirects, Next-hop determination, > > Neighbor Unreachability Detection, etc., are expected to be provided > > as specified in this document. The details of how one uses ND on > > NBMA links are addressed in [IPv6-NBMA]. In addition, [IPv6-3GPP] > > and[IPv6-CELL] discuss the use of this protocol over some cellular > > links, which are examples of NBMA links. > > That means that Neighbor Discovery using multicast NS need not be > done on point-to-point links, but Neighbor Unreachability Detection > still is done. > I'm a bit confused by that. My understanding of NUD was that it's main function is to ensure that existing entries in the neighbor cache are valid. If NUD fails, then the entry is removed from the neighbor cache so that next time that destination IPv6 address is sent to, the absence of a neighbor cache entry would trigger an NS/NA transaction. So if ND NS/NA transactions aren't performed on these point-to-point links, wouldn't that mean there is nothing for NUD to validate? What would be the target address of the NUD probes if they can take place without ND NS/NA transactions priming the neighbor cache with entries? Thanks, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
