Speaking individually, as someone involved in the original NUD discussions...
> Hi Margaret, > > > "2.4 RFC2461 - Neighbor Discovery for IPv6 > > > > > > Neighbor Discovery is described in [RFC-2461]. This > > > specification is a mandatory part of IPv6. > > > > > > 2.4.1 Neighbor Discovery in 3GPP Networks > > > > > > In GPRS and UMTS networks, some Neighbor Discovery > > > messages can cause unnecessary traffic and consume > > > valuable (limited) bandwidth. GPRS and UMTS links > > > resemble a point-to-point link; hence, the host's > > > only neighbor on the cellular link is the default > > > router that is already known through Router Discovery. > > > Therefore, while the host must support Neighbor > > > Solicitation and Advertisement messages, their use > > > in address resolution and next-hop determination is > > > not necessary and the host may choose to not initiate > > > them. > > > > I don't think that we should include the last sentence of > > this paragraph. Some of the thinking behind NUD is: 1) it's intended to test end-2-end IP connectivity at the neighbor-to-neighbor level. Even of L2 can indicate to L3 when the L2 link "goes away", that doesn't mean NUD is not necessary. The IP module on the neighbor may not be functioning properly, even though the L2 link is up. NUD detects such situations. 2) If NUD indicates there is a problem with neighbor connectivity, there are some steps to take to try and find an alternate path. Rerunning ND may result in a new link-layer address being found for the destination that reestablishes connectivity. Or, perhaps the neighbor is actually a router and an alternate router can be found. 3) NUD is only used if there is IP traffic thorough some neighbor, but the upper layers (TCP, specifically) are not telling the IP/NUD layer that ACKS are coming back. I.e., normally, if there is (say) TCP usage, NUD won't need to be used at all. So no extra/unnecessary traffic. >From the above, I don't quite buy the argument that NUD is not needed on the link for the reasons given in the document. On the other hand, I understand that things are more complex in some scenarios (like the target of the document at issue). Specifically: 1) 3GPP will be using lots of UDP (RTP and friends) and maybe not so much TCP? So upper layer hints may not be readily available (or, in anycase, there is no document explainig how to do this). 2) If (and only if) there is only a single p2p (e.g., no other interfaces to other networks), there is presumably no recovery possible in the case that NUD fails. So one could argue, what's the point? But the celluar document could do a better job of explaining these issues and the tradeoffs than it does. > My feeling is that upper-layer protocols are out of scope of > this document, and I am uncomfortable making a recommendation on > including them in this document. I think that it would be possible > to say that, when available, these mechanisms can be used, > something like this: Actually, it makes sense to me to encourage stack builders to be smart about providing feedback from upper layers to lower layers in order to avoid the need for NUD _in those cases where it makes sense to from the NUD protocol perspective_. Not mentioning this, seems like not providing good guidance. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
