[bug #55972] The Neighbour Solicitation used to do IPv6 address resolution was wrong

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[bug #55972] The Neighbour Solicitation used to do IPv6 address resolution was wrong

Wilfred
URL:
  <https://savannah.nongnu.org/bugs/?55972>

                 Summary: The Neighbour Solicitation used to do IPv6 address
resolution was wrong
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: kevingao
            Submitted on: Thu 21 Mar 2019 01:16:36 PM UTC
                Category: IPv6
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
            lwIP version: git head

    _______________________________________________________

Details:

The Neighbour Solicitation was used to do IPv6 address resolution or Duplicate
Address Detection. For IPv6 address resolution, lwip always use the link local
address as the source address, this could cause network unreachable in below
scenario.
1,configure one global IPv6 address on one netif, such as 2001::2 on eth0 whos
MAC address was 00:00:00:00:00:22;
2,ping the peer side which was Linux, ping succeed and on Linux one new
neighbour cahe was created, 2001::2 + 00:00:00:00:00:22,
3,change the MAC address of netif eth0 from 00:00:00:00:00:22 to
00:00:00:00:00:33;
4,Ping the peer side again, ping failed and last about 10s, after then, ping
succeed;
5,the reason of ping failed was that Linux still using the old neighbour cache
(2001::2 + 00:00:00:00:00:22), after 10s, Linux get the new MAC address by
multicast Neighbour Solicitation (2001::2 +  00:00:00:00:00:33), then ping
succeed.
6, why the ping failure last 10s, it was the sum of 5s(Neighbour cache changed
from STALE to Delay, and then from Delay to Probe)+ 3s (Linux send 3 unicast
NS, and each one was 1s) + 2s(Ping interval).

The attached file was one real example, pls check. The other attach file was
my modification, pls review.



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Thu 21 Mar 2019 01:16:36 PM UTC  Name: 11.pcap  Size: 5KiB   By:
kevingao

<http://savannah.nongnu.org/bugs/download.php?file_id=46601>
-------------------------------------------------------
Date: Thu 21 Mar 2019 01:16:36 PM UTC  Name:
choose-source-address-based-on-target-address.patch  Size: 1KiB   By: kevingao

<http://savannah.nongnu.org/bugs/download.php?file_id=46602>

    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?55972>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/


_______________________________________________
lwip-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

[bug #55972] The Neighbour Solicitation used to do IPv6 address resolution was wrong

Wilfred
Update of bug #55972 (project lwip):

                  Status:                    None => Fixed                  
             Open/Closed:                    Open => Closed                

    _______________________________________________________

Follow-up Comment #1:

Applied, thanks for the patch!

    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?55972>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/


_______________________________________________
lwip-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

[bug #55972] The Neighbour Solicitation used to do IPv6 address resolution was wrong

Wilfred
Follow-up Comment #2, bug #55972 (project lwip):

Hi, I am sorry for the previous patch as it was bad. In IPv6, the way to judge
whether one host was neighbour is very different from IPv4. pls refer the blog
on
"https://blog.ipspace.net/2012/11/ipv6-on-link-determination-what-is-it.html"
for more info, you can also refer RFC4861 and RFC5942 for more official
statements about IPv6 On-Link determination.
As a conclusion, In IPv6, it is possible that the neighbour is in one
different subnet with the Neighbour Solicitation Sender. so lwip should NOT
try to choose the source address based on the target address because it is
likely that there was no such one address. The correct way is to try to use
any valid address as the source of NS msg. pls review the attached patch
again.

(file #46768)
    _______________________________________________________

Additional Item Attachment:

File name: try-to-use-any-valid-address-as-source-of-NS.patch Size:0 KB
   
<https://savannah.nongnu.org/file/try-to-use-any-valid-address-as-source-of-NS.patch?file_id=46768>



    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?55972>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/


_______________________________________________
lwip-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

[bug #55972] The Neighbour Solicitation used to do IPv6 address resolution was wrong

Wilfred
Follow-up Comment #3, bug #55972 (project lwip):

for the ping failed issue I reported, the best fix method is to update the
peer side's neighbour cache by sending one Neighbour Advertisement actively,
with override flag. There was two way to do this, 1) make nd6_send_na not one
static function and call it after L2 address changed; 2) call nd6_send_na at
the last of netif_issue_reports, this modification is take IPv4 gratituous ARP
as reference because GARP is sent out after L2 address changed, but I suggest
to add the 3rd input argument for netif_issue_reports to make the caller
decide which address used to send NA. the second way I prefer.

    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?55972>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/


_______________________________________________
lwip-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-devel