[ipv6hackers] IPv6 Address Resolution in Linux 2.6.27

[Mudric, Dusan (Dusan)]

Hi,

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?

Regards, 
Dušan Mudrić 

Software Architect
Endpoints & Video Solutions
Avaya Global Communication Systems
Telephone: (613) 595-9045
425 Legget Drive, Ottawa, Ontario, K2K 2W2

"I have always believed, and I still believe, that whatever good or bad fortune may come our way, we can always give it meaning and transform it into something of value." - Hermann Hesse