netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Ward <david.ward@ll.mit.edu>
To: Mark Smith <lk-netdev@lk-netdev.nosense.org>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH] Update Neighbor Cache when IPv6 RA is received on a router
Date: Sun, 16 Aug 2009 01:47:09 -0400	[thread overview]
Message-ID: <4A879D5D.1010202@ll.mit.edu> (raw)
In-Reply-To: <20090816120027.3d510139.lk-netdev@lk-netdev.nosense.org>

Mark, thank you very much for your response.

On 08/15/2009 10:30 PM, Mark Smith wrote:
> Hi David,
>
> On Sat, 15 Aug 2009 20:19:54 -0400
> David Ward <david.ward@ll.mit.edu> wrote:
>
>> When processing a received IPv6 Router Advertisement, the kernel
>> creates or updates an IPv6 Neighbor Cache entry for the sender --
>> but presently this does not occur if IPv6 forwarding is enabled
>> (net.ipv6.conf.*.forwarding = 1), or if IPv6 Router Advertisements
>> are not accepted (net.ipv6.conf.*.accept_ra = 0), because in these
>> cases processing of the Router Advertisement has already halted.
>>
>> This patch allows the Neighbor Cache to be updated in these cases,
>> while still avoiding any modification to routes or link parameters.
>>
>
> I'm a bit confused what benefit this has.

I apologize for not making that clear. It allows routers to utilize the 
Neighbor Cache to keep track of neighboring routers, which are learned 
about through the periodic Router Advertisements. By doing so, 
applications communicating through upper layers can make use of the 
Neighbor Cache, for example, as a basis for initiating dynamic peering 
between neighboring routers. Non-routers are already able to keep track 
of their neighboring routers in the Neighbor Cache; this simply allows 
routers to do the same.

This cannot be achieved through Neighbor Advertisements, because they 
are usually sent in response to a direct Neighbor Solicitation, while 
Router Advertisements are periodically multicast to the all-nodes group.

> Is the intent to avoid a Neighbor Solicitation being triggered when a
> recent RA has already provided the router's link local address,
> therefore reducing by a small mount ND traffic?

No. This patch does not preclude the need to send a Neighbor 
Solicitation to another router to determine reachability. That would 
violate RFC 4861, which states that a Router Advertisement "MUST NOT be 
treated as a reachability confirmation".

In the dynamic router peering scenario, the Neighbor Cache entry could 
be used to learn that the neighboring router exists and is a potential 
peer -- but reachability must still be determined before a peering 
session could actually be attempted.

>> This continues to satisfy RFC 4861, since any entry created in the
>> Neighbor Cache as the result of a received Router Advertisement is
>> still placed in the STALE state.
>>
>> Signed-off-by: David Ward <david.ward@ll.mit.edu>
>> ---
>>  net/ipv6/ndisc.c |   14 ++++++++------
>>  1 files changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
>> index 1ba42bd..44b4c87 100644
>> --- a/net/ipv6/ndisc.c
>> +++ b/net/ipv6/ndisc.c
>> @@ -1151,10 +1151,6 @@ static void ndisc_router_discovery(struct
>> sk_buff *skb)
>>                 skb->dev->name);
>>          return;
>>      }
>> -    if (in6_dev->cnf.forwarding || !in6_dev->cnf.accept_ra) {
>> -        in6_dev_put(in6_dev);
>> -        return;
>> -    }
>>
>>      if (!ndisc_parse_options(opt, optlen, &ndopts)) {
>>          in6_dev_put(in6_dev);
>> @@ -1163,6 +1159,10 @@ static void ndisc_router_discovery(struct
>> sk_buff *skb)
>>          return;
>>      }
>>
>> +    /* skip route and link configuration on routers */
>> +    if (in6_dev->cnf.forwarding || !in6_dev->cnf.accept_ra)
>> +        goto skip_linkparms;
>> +
>>  #ifdef CONFIG_IPV6_NDISC_NODETYPE
>>      /* skip link-specific parameters from interior routers */
>>      if (skb->ndisc_nodetype == NDISC_NODETYPE_NODEFAULT)
>> @@ -1283,9 +1283,7 @@ skip_defrtr:
>>          }
>>      }
>>
>> -#ifdef CONFIG_IPV6_NDISC_NODETYPE
>>  skip_linkparms:
>> -#endif
>>
>>      /*
>>       *    Process options.
>> @@ -1312,6 +1310,10 @@ skip_linkparms:
>>                   NEIGH_UPDATE_F_ISROUTER);
>>      }
>>
>> +    /* skip route and link configuration on routers */
>> +    if (in6_dev->cnf.forwarding || !in6_dev->cnf.accept_ra)
>> +        goto out;
>> +
>>  #ifdef CONFIG_IPV6_ROUTE_INFO
>>      if (in6_dev->cnf.accept_ra_rtr_pref && ndopts.nd_opts_ri) {
>>          struct nd_opt_hdr *p;
>> --
>> 1.6.0.4

  reply	other threads:[~2009-08-16  6:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-16  0:19 [PATCH] Update Neighbor Cache when IPv6 RA is received on a router David Ward
2009-08-16  2:30 ` Mark Smith
2009-08-16  5:47   ` David Ward [this message]
2009-08-29  7:04 ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A879D5D.1010202@ll.mit.edu \
    --to=david.ward@ll.mit.edu \
    --cc=lk-netdev@lk-netdev.nosense.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).