* IPv6 neighbor advertisements
@ 2010-03-26 5:51 Haile Seifu
2010-03-26 6:07 ` David Miller
0 siblings, 1 reply; 3+ messages in thread
From: Haile Seifu @ 2010-03-26 5:51 UTC (permalink / raw)
To: netdev
Hi,
I have been running some tests involving IPv6 neighbor discovery.
When a neighbor advertisement is received by the Kernel and the
follwing is true:
- the advertisement's solicited flag is set,
- the advertisement's override flag is clear,
- the advertisement's link layer address differs from what is in
the corresponding neighbor cache entry, and
- the corresponding neighbor cache entry state is neither
INCOMPLETE or REACHABLE
then it appears that the cache entry gets updated from STALE/DELAY to
REACHABLE. According to RFC 2461/4861 section
7.2.5, the advertisement in the above scenario should be ignored and
MUST NOT update the neighbor cache entry
I was curious about why the following code in net/core/neighbour.c,
function neigh_update, updates the neigh->confirmed
and neigh->updated fields (in lines 1039-1041) when the else-condition
(the scenario described above) is still possible in
lines 1055-1056.
By the way, the "new" flag is set based on the solicited flag of the
neighbor advertisement, so the if-condition on line 1039 will
be true.
net/core/neighbour.c (version linux-2.6.34-rc1):
982 int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new,
983 u32 flags)
984 {
...
...
...
1039 if (new & NUD_CONNECTED)
1040 neigh->confirmed = jiffies;
1041 neigh->updated = jiffies;
1042
1043 /* If entry was valid and address is not changed,
1044 do not change entry state, if new one is STALE.
1045 */
1046 err = 0;
1047 update_isrouter = flags & NEIGH_UPDATE_F_OVERRIDE_ISROUTER;
1048 if (old & NUD_VALID) {
1049 if (lladdr != neigh->ha && !(flags &
NEIGH_UPDATE_F_OVERRIDE)) {
1050 update_isrouter = 0;
1051 if ((flags & NEIGH_UPDATE_F_WEAK_OVERRIDE) &&
1052 (old & NUD_CONNECTED)) {
1053 lladdr = neigh->ha;
1054 new = NUD_STALE;
1055 } else
1056 goto out;
1057 } else {
1058 if (lladdr == neigh->ha && new == NUD_STALE &&
1059 ((flags & NEIGH_UPDATE_F_WEAK_OVERRIDE) ||
1060 (old & NUD_CONNECTED))
1061 )
1062 new = old;
1063 }
1064 }
.
.
.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: IPv6 neighbor advertisements
2010-03-26 5:51 IPv6 neighbor advertisements Haile Seifu
@ 2010-03-26 6:07 ` David Miller
2010-03-26 14:40 ` Haile Seifu
0 siblings, 1 reply; 3+ messages in thread
From: David Miller @ 2010-03-26 6:07 UTC (permalink / raw)
To: haile.seifu; +Cc: netdev
Keep in mind that net/core/neighbour.c is for IPV4 ARP too.
So if there is a conflict between what is allowed by ipv4
and what is allowed by ipv6 in this scenerio, that would
explain it.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: IPv6 neighbor advertisements
2010-03-26 6:07 ` David Miller
@ 2010-03-26 14:40 ` Haile Seifu
0 siblings, 0 replies; 3+ messages in thread
From: Haile Seifu @ 2010-03-26 14:40 UTC (permalink / raw)
To: netdev; +Cc: David Miller
Hi,
Yes, but the neighbor entry can be checked for the protocol type and
then the confirmed/updated field can be reset if the else condition is
taken.
On Fri, Mar 26, 2010 at 2:07 AM, David Miller <davem@davemloft.net> wrote:
>
> Keep in mind that net/core/neighbour.c is for IPV4 ARP too.
>
> So if there is a conflict between what is allowed by ipv4
> and what is allowed by ipv6 in this scenerio, that would
> explain it.
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-03-26 14:40 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-03-26 5:51 IPv6 neighbor advertisements Haile Seifu
2010-03-26 6:07 ` David Miller
2010-03-26 14:40 ` Haile Seifu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.