[ipv6hackers] IPv6 Address Resolution in Linux 2.6.27

[Hannes Frederic Sowa]

On 02/11/2013 04:31 PM, Mudric, Dusan (Dusan) wrote:
> I experience Address Resolution problem while using Linux 2.6.27.
> 
> A and B use global IPv6 addresses. 
> . 2009::6:173 - 'A'  global address (the capture monitors its port) . 2009::6:172 - 'B' global address
> 
> Both A and B are about 8 seconds in the reachable states (STALE / DELAY / PROBE) with full audio, and then ~30 seconds in the INCOMPLETE state. This happens periodically.
> 
> Media behavior when phones talk P2P:
> RTP directions   #reference packet  Starting time Time diff [seconds]
> 172 <- -> 173          940                                13.5                  -
> 172     -> 173        1779                                21.5                 8
> 172 <- -> 173        4134                               63.9              42
> 172     -> 173         4983                               71.9                8
> 172 <- -> 173        7361                             114.3             42
> 172     -> 173         8211                             122.4               8
> 
> I added debug info in net\ipv6\ndisc.c ndisc_recv_na() to print src and dst IPs.
> I added debug info in neigh_update() to print LL address and a new state I enabled NEIGH_PRINTKx and ND_PRINTKx
> 
> Observations:
> 1. 173 discover and lose 172 address in periodic manner - 8 / 42 / 8 / 42 / .
> 2. When 173 loses 172 (and when it gets it again) we see ICMPv6 traffic: NS from 173 to 172 and NA from 172 to 173 . During the time 173 can't reach 172 there are ICMPv6 NS messages from 173 and NA to 173. 173 ndisc_recv_na() is not called. NAs are silently discarded somewhere. At the same time, 173 neighbor cache entry does not follow the RFC4861. neigh_update() state changes from INCOMPLETE to STALE do DELAYED after the first timeout. It should stay in INCOMPLETE. From DELAYED state it goes to PROBE which is allowed by RFC. It stays in PROBE for 3sec (3 NS retransmissions) and goes to FAILED state. 2sec later is send NS again and goes into DELAYED state.
> 3. NDP:
> a. 172 sends only 3 solicitation request for 173 during the capture period, while 173 sends solicitation to 172 every second b. 173 reach 172 only after 172 sends advertisement to 173' LL address (not the global one and without the "override" flag)
> 
> If you need a Wire Shark trace, I can provide it.
> 
> Q: Is this a known problem? If yes, is there a patch for it?

The linux ndisc resolving did get a major update (neighbours won't be
tracked in the routing table anymore). These changes are available from
davem's net-next linux tree and will hit v3.9. May I ask you to check if
these patches solve the problem for you? The old implementation did have
some known glitches.