> > > > 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. > >Can you detail what your objection to the last sentence is?
Saying that a host "may choose to not initiate" NUD messages is the same thing as saying that a host may choose not to comply with the NUD portions of RFC 2461, which clearly indicates that hosts send NUD-related NA and NS messages in certain situations, such as when an IPv6 packet is sent to/through a neighbor whose neighbor cache entry is in the PROBE state. I object to telling cellular host implementers that they don't have to comply with portions of RFC 2461. RFC 2461 is a mandatory, core IPv6 specification, and all IPv6 nodes should comply with it. Your suggested text will not result in a significant decrease in traffic over the wireless interface. In fact, the suggested text will not result in the elimination of _any_ NUD messages in the most typical case where everything is working properly. And, even if we do form a rough consensus (despite my objections) that cellular hosts do not have to comply fully with the NUD-related portions of RFC 2461, your proposed text is insufficient to specify what cellular hosts should/shouldn't implement. If a host fully complies with RFC 2461, with the single exception that it doesn't initiate any NUD-related NS or NA messages, it could reach a point where it can't send any IPv6 packets at all. Let me explain further... Lets assume that a cellular host (CH) is attempting to establish communication with a web server on the Internet (WS), using a 3GPP GGSN as its default gateway, of course. Let's further assume that the neighbor cache on the CH already includes an entry for the GGSN, with the IsRouter bit set, due to previous Router Advertisements received from the GGSN -- otherwise, the CH wouldn't have an IPv6 address. This entry will be in the STALE state, as defined in RFC 2461 section 6.3.4. First, let's look at what happens when all is going well... ND indicates that address resolution is unnecessary when the link-layer address of the neighbor is already known. This would apply in the 3GPP case, so no address resolution step would be required for CH to determine the link-layer address of the GGSN. When the CH attempts to connect to the WS, with the neighbor cache entry in the stale state, no NUD NS will be sent. The HTTP/TCP/IPv6 packet will be sent to the WS, and the neighbor cache entry will be moved to the DELAY state. As long as a TCP acknowledgement is received, and upper layer advice provided to ND, within 5 seconds, no NUD messages are require. Going forward, the neighbor cache will continue to be updated by the TCP layer whenever a newill proceed without any NUD messages at all. IMPORTANT POINT: No NS or NA messages are sent, at all, in the case where full connectivity exists between the CH, the GGSN and the WS. This would be true even if we were willing to initiate NUD messages, so your proposed optimization does not actually save any bandwidth in normal operation. But, what will happen when something goes wrong? Let's assume that there is a network failure, perhaps between the GGSN and the WS, that is preventing traffic from passing between the CH and the WS. The CH may make repeated attempts to connect, over an extended period of time (greater than 35 seconds), with the neighbor cache entry progressing from the REACHABLE state, to the STALE state, to the DELAY state, to the PROBE state. At that point, no HTTP/TCP/IPv6 packets will be sent (for any traffic to or through the GGSN -- which is all traffic that the CH might send) until two-way reachability can be established between the CH and the GGSN. This would normally happen through the GGSN's response to a NUD NS message sent by the CH, but what happens if the CH chooses not initiate those messages, as suggested in the cellular host draft? Nothing. No IPv6 packets will ever be sent by the CH again, until it is rebooted. Obviously this is not a desireable outcome. So, along with your statement that the cellular host may choose not to initiate NUD-related NS messages, you would also need some changes to the NUD state machine to avoid entering the PROBE state. This is a non-trivial change to ND, and I don't think that we should suggest it in this document. Margaret > > 2.4.1 Neighbor Discovery in 3GPP Networks > > > > The host must support the Neighbor Solicitation and > > Advertisement messages for neighbor unreachability > > detection as specified in [RFC-2461]. > > > > In GPRS and UMTS networks, it is very desireable to > > conserve bandwidth. Therefore, hosts stacks used in > > these environments should include a mechanism in > > upper layer protocols (such as TCP) to provide > > reachability confirmation when two-way reachability > > can be confirmed (see RFC-2461, section 7.3.1). > > These confirmations will allow the suppression of > > most NUD-related messages. > >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: > > 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. > Additionally, upper-layer protocols can provide > reachability confirmation when two-way reachability > can be confirmed (see RFC-2461, section 7.3.1). > These confirmations allow the suppression of > most NUD-related messages. 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. > > > [If there are any upper-layer 3GPP protocols that can > > provide reachability confirmation, meeting the definition > > in the ND spec, we should mention them here.] > >I don't have the 3GPP documentation in front of me, perhaps one of the other >authors can comment here. > > > Please note that the IPv6 specs consistenly misspell neighbour as > > "neighbor" :-). We should also use that spelling in this > > specification. > >Actually, Neighbour is the correct spelling in British English, >so I would not classify it as a misspelling (I think that several >of the authors of the document have been taught British English). >However, we should be consistant in the document. > >John -------------------------------------------------------------------- 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] --------------------------------------------------------------------
