Subject: IPv6 Address Resolution in Linux 2.6.27

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Fri, 8 Feb 2013 18:12:50 +0000

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)

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<http://www.answers.com/topic/hermann-hesse/>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 8 Feb 2013 19:32:14 +0100 (CET)

> Q: Is this a known problem? If yes, is there a patch for it?

I believe this is not the correct list for asking these questions. The 
linux netdev is probably more suitable place to ask linux specific 
questions.

Then again, I doubt you'll get much enthusiasm there to fault find a 
kernel that was released in october 2008.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Fri, 08 Feb 2013 18:51:09 -0300

Hi, Dusan,

On 02/08/2013 03:12 PM, Mudric, Dusan (Dusan) wrote:
> ·         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. 

If at some point ND had been successful for such address, I think such
entry should remain in the "STALE" state rather than move to INCOMPLETE
(of the top of my head).

> 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)
> 

For this kind of scenario, it's usually helpful if you can provide a
packet trace (e.g. tcpdump formated). That said, as noted by others the
Linux netdev might be a better place to ask this question... or for
instance, you might want to ask it on the ipv6hackers mailing-list:
<http://lists.si6networks.com/listinfo/ipv6hackers/>

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492