Hi,
Prefix length for link-local address should be 64, not 10.
This patch fixes prefix length of link-local address.
Following patch is against 2.4.19.
Thanks in advance.
-------------------------------------------------------------------
Patch-Name: Fix Prefix Length of Link-local Addresses
Patch-Id: FIX_2_4_19_LINKLOCAL_PREFIXLEN-20020928
Patch-Author: YOSHIFUJI Hideaki / USAGI Project <[email protected]>
Credit: YOSHIFUJI Hideaki / USAGI Project <[email protected]>
-------------------------------------------------------------------
Index: net/ipv6/addrconf.c
===================================================================
RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/addrconf.c,v
retrieving revision 1.1.1.1
retrieving revision 1.1.1.1.20.1
diff -u -r1.1.1.1 -r1.1.1.1.20.1
--- net/ipv6/addrconf.c 2002/08/20 09:47:02 1.1.1.1
+++ net/ipv6/addrconf.c 2002/09/27 17:17:06 1.1.1.1.20.1
@@ -783,7 +783,7 @@
struct in6_addr addr;
ipv6_addr_set(&addr, __constant_htonl(0xFE800000), 0, 0, 0);
- addrconf_prefix_route(&addr, 10, dev, 0, RTF_ADDRCONF);
+ addrconf_prefix_route(&addr, 64, dev, 0, RTF_ADDRCONF);
}
static struct inet6_dev *addrconf_add_dev(struct net_device *dev)
@@ -1158,7 +1158,7 @@
flag |= IFA_HOST;
}
if (idev->dev->flags&IFF_POINTOPOINT)
- plen = 10;
+ plen = 64;
else
plen = 96;
@@ -1208,7 +1208,7 @@
{
struct inet6_ifaddr * ifp;
- ifp = ipv6_add_addr(idev, addr, 10, IFA_LINK, IFA_F_PERMANENT);
+ ifp = ipv6_add_addr(idev, addr, 64, IFA_LINK, IFA_F_PERMANENT);
if (ifp) {
addrconf_dad_start(ifp);
in6_ifa_put(ifp);
From: YOSHIFUJI Hideaki / 吉藤英明 <[email protected]>
Date: Tue, 08 Oct 2002 00:05:59 +0900 (JST)
Prefix length for link-local address should be 64, not 10.
This patch fixes prefix length of link-local address.
Following patch is against 2.4.19.
Patch is applied, thank you.
BTW, we start to run into conflicts now and most of USAGI patches now
I need to apply some parts by hand. Here is one example, with this
patch:
@@ -783,7 +783,7 @@
struct in6_addr addr;
ipv6_addr_set(&addr, __constant_htonl(0xFE800000), 0, 0, 0);
- addrconf_prefix_route(&addr, 10, dev, 0, RTF_ADDRCONF);
+ addrconf_prefix_route(&addr, 64, dev, 0, RTF_ADDRCONF);
}
static struct inet6_dev *addrconf_add_dev(struct net_device *dev)
Note in this hunk the __constant_htonl() which was transformed
to plain htonl() by already accepted USAGI patch.
It is not such a big deal now, but it may soon become larger as
bigger USAGI patches are applied. We will need to synchronize
at some point.
In article <[email protected]> (at Mon, 07 Oct 2002 11:55:30 -0700 (PDT)), "David S. Miller" <[email protected]> says:
> BTW, we start to run into conflicts now and most of USAGI patches now
> I need to apply some parts by hand. Here is one example, with this
> patch:
:
> It is not such a big deal now, but it may soon become larger as
> bigger USAGI patches are applied. We will need to synchronize
> at some point.
Agreed.
So,... What kind of patches do you prefer, now?
- on top of plain kernel (2.4.19, 2.4.20, 2.4.21-preXX, or whatever)
- plain kernel + on top of our whole patch?
- ???
--
Hideaki YOSHIFUJI @ USAGI Project <[email protected]>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
From: YOSHIFUJI Hideaki / 吉藤英明 <[email protected]>
Date: Tue, 08 Oct 2002 09:37:21 +0900 (JST)
So,... What kind of patches do you prefer, now?
- on top of plain kernel (2.4.19, 2.4.20, 2.4.21-preXX, or whatever)
- plain kernel + on top of our whole patch?
- ???
If you send patches against 2.4.20-pre9, it would be fine.
On Tue, Oct 08, 2002 at 12:05:59AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B wrote:
> Hi,
>
> Prefix length for link-local address should be 64, not 10.
> This patch fixes prefix length of link-local address.
>
> Following patch is against 2.4.19.
Huh?
Without reading the kernel routing table code a bit more, I'm not certain
what that change does, but it looks as if it might be changing the
connected route for a link local from fe80::/10 to fe80::/64.
I'd actually say that is wrong.
All link local's are currently supposed to have those top bits
('tween 10 and 64) zero'd, however any address within the link local
prefix _is_ on link / connected and should go to the interface.
i.e. it's perfectly valid for me to assign a link local of fe80:1910::10
to an interface and expect it to be work, likewise for a packet
destined to any link local address to trigger ND.
DF
In article <[email protected]> (at Wed, 9 Oct 2002 17:00:18 +0100), Derek Fawcus <[email protected]> says:
> All link local's are currently supposed to have those top bits
> ('tween 10 and 64) zero'd, however any address within the link local
> prefix _is_ on link / connected and should go to the interface.
>
> i.e. it's perfectly valid for me to assign a link local of fe80:1910::10
> to an interface and expect it to be work, likewise for a packet
> destined to any link local address to trigger ND.
First of all, please don't use such addresses.
By spec, auto-configured link-local address is fe80::/64
and connected route should be /64.
If you do really want to use such addresses (like fe80:1920::10),
you can put another route by yourself, at your own risk.
We should not configure in such way by default.
and, we should even have to add "discard" route for them
by default for safe.
--yoshfuji
On Thu, Oct 10, 2002 at 01:54:32AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B wrote:
> In article <[email protected]> (at Wed, 9 Oct 2002 17:00:18 +0100), Derek Fawcus <[email protected]> says:
>
> > All link local's are currently supposed to have those top bits
> > ('tween 10 and 64) zero'd, however any address within the link local
> > prefix _is_ on link / connected and should go to the interface.
> >
> > i.e. it's perfectly valid for me to assign a link local of fe80:1910::10
> > to an interface and expect it to be work, likewise for a packet
> > destined to any link local address to trigger ND.
>
> First of all, please don't use such addresses.
Why not, they are perfectly legal?
> By spec, auto-configured link-local address is fe80::/64
> and connected route should be /64.
Yes auto-configured have fe80:0:0:0: in their upper 64 bits, but that
is just for autoconfigured addessses. That is a seperate issue to which
prefix desinates link local.
Connected routes don't have to be /64, things work correctly even if
one picks any other value.
> If you do really want to use such addresses (like fe80:1920::10),
> you can put another route by yourself, at your own risk.
No - what I'm saying is that all link locals should go to the link.
There is no risk inherent in using such an address or link local prefix.
If a mechanism is required such that autoconfig generates the correct
type of address, then add it. But that doesn't _require_ that
the connected route be /64.
I happen to use link locals like the quite often, since it makes
testing and reading packet traces a hell of a lot easier.
> We should not configure in such way by default.
> and, we should even have to add "discard" route for them
> by default for safe.
Why. In what way is it not 'safe' to have any link local address
sent onto the link? They'll either reach a destination or not,
but given that they'll never leave the link, they can't be inherently
unsafe.
DF
On Thu, 10 Oct 2002, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote:
> In article <[email protected]> (at Wed, 9 Oct 2002 17:00:18 +0100), Derek Fawcus <[email protected]> says:
>
> > All link local's are currently supposed to have those top bits
> > ('tween 10 and 64) zero'd, however any address within the link local
> > prefix _is_ on link / connected and should go to the interface.
> >
> > i.e. it's perfectly valid for me to assign a link local of fe80:1910::10
> > to an interface and expect it to be work, likewise for a packet
> > destined to any link local address to trigger ND.
>
> First of all, please don't use such addresses.
>
> By spec, auto-configured link-local address is fe80::/64
> and connected route should be /64.
>
> If you do really want to use such addresses (like fe80:1920::10),
> you can put another route by yourself, at your own risk.
>
> We should not configure in such way by default.
> and, we should even have to add "discard" route for them
> by default for safe.
Personally I think the interfaces should be configured with a /64 but
there should be a discard route for the whole /10.
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
At Wed, 9 Oct 2002 17:00:18 +0100,
Derek Fawcus <[email protected]> wrote:
> Without reading the kernel routing table code a bit more, I'm not certain
> what that change does, but it looks as if it might be changing the
> connected route for a link local from fe80::/10 to fe80::/64.
Why do you want to use /10 prefix for link-local address ?
RFC2373 defines link-local address format as below.
| 10 |
| bits | 54 bits | 64 bits |
+----------+-------------------------+----------------------------+
|1111111010| 0 | interface ID |
+----------+-------------------------+----------------------------+
> All link local's are currently supposed to have those top bits
> ('tween 10 and 64) zero'd, however any address within the link local
> prefix _is_ on link / connected and should go to the interface.
If you wan to use /10 prefix for link-local address, you can add the
link-local address with /10 prefix to interfaces and routing table
manually at your own risk, but it should not be a default behavior.
-- Yuji Sekiya
On Thu, Oct 10, 2002 at 06:46:16AM +0900, Yuji Sekiya wrote:
> At Wed, 9 Oct 2002 17:00:18 +0100,
> Derek Fawcus <[email protected]> wrote:
>
> > Without reading the kernel routing table code a bit more, I'm not certain
> > what that change does, but it looks as if it might be changing the
> > connected route for a link local from fe80::/10 to fe80::/64.
>
> Why do you want to use /10 prefix for link-local address ?
> RFC2373 defines link-local address format as below.
It also states that all fe80::/10 are link local and all fec0:/10 are
site local (sect 2.4)
> | 10 |
> | bits | 54 bits | 64 bits |
> +----------+-------------------------+----------------------------+
> |1111111010| 0 | interface ID |
> +----------+-------------------------+----------------------------+
and for site local it says use the following:
| 10 |
| bits | 38 bits | 16 bits | 64 bits |
+----------+-------------+-----------+----------------------------+
|1111111011| 0 | subnet ID | interface ID |
+----------+-------------+-----------+----------------------------+
whereas draft-ietf-ipngwg-addr-arch-v3-10.txt says:
| 10 |
| bits | 54 bits | 64 bits |
+----------+-------------------------+----------------------------+
|1111111011| subnet ID | interface ID |
+----------+-------------------------+----------------------------+
So we've already changed what is recommended in the top bits for site
local, if someone can think of a use for the top bits in link local
they'll probably be defined. (Do you arbitrarily restrict the bits
in site local addresses?)
However link locals are a bit different. Once you have matched fe80:/10
then by definition the rest of the address specifies a directly
connected neighbour. As that's what link locals are - host routes
to directly connected neighbours. There isn't really a connected
prefix as such, that is only there to trigger ND.
Making a restriction that all link local neighbour entries have to match
fe80::/64 rather than the full fe80::/10 is pointless, it gains nothing
and makes an arbitrary restriction for no real purpose.
> > All link local's are currently supposed to have those top bits
> > ('tween 10 and 64) zero'd, however any address within the link local
> > prefix _is_ on link / connected and should go to the interface.
>
> If you wan to use /10 prefix for link-local address, you can add the
> link-local address with /10 prefix to interfaces and routing table
> manually at your own risk, but it should not be a default behavior.
My point is that it isn't really a route. Once you've matched fe80::/10
then you know that you've got a link local address, and you switch
to looking up a connected neighbour entry in the conceptual neighbour
cache.
Other than allowing the use of the whole address field, the only
difference in behaviour between the two forms would possibly
be in the type of ICMPv6 error generated for a non existant neighbour
addressed by a link local with those high bits set.
If the prefix to match link locals is /10 then type 1 code 3 would
be generated, whereas if /64 is used (together with a /10 drop) then
type 1 code 0 would be generated.
Anyway, I'll not bother following up again in this thread.
If you don't see the point, then forget it.
DF
I think the change was made because some TAHI test
failed without it, USAGI people is this right?
Most of USAGI changes are of this nature. :-)
From: Derek Fawcus <[email protected]>
Date: Thu, 10 Oct 2002 00:29:02 +0100
There are areas where the TAHI tests expect a certain behaviour
when more than one behaviour is acceptable.
Great, that's what I was trying to find out.
Now I just need to know if this link-local prefix case
is one such issue. :-)
On Wed, Oct 09, 2002 at 04:14:14PM -0700, David S. Miller wrote:
>
> I think the change was made because some TAHI test
> failed without it, USAGI people is this right?
>
> Most of USAGI changes are of this nature. :-)
There are areas where the TAHI tests expect a certain behaviour when
more than one behaviour is acceptable.
As I recall there is an issue around the behaviour of a packet being
received with a zero length payload. The TAHI tests seem to expect
one type of ICMPv6 response, whereas depending upon the value of
next header and the order in which header field validations occur,
two different types of ICMP error can be generated.
Specifically parameter problem identifying the payload field or the
next header field. I seem to remember this being triggered when a
jumbo header is received by a node that doesn't understand jumbograms.
DF
On Wed, Oct 09, 2002 at 04:24:38PM -0700, David S. Miller wrote:
> From: Derek Fawcus <[email protected]>
> Date: Thu, 10 Oct 2002 00:29:02 +0100
>
> There are areas where the TAHI tests expect a certain behaviour
> when more than one behaviour is acceptable.
>
> Great, that's what I was trying to find out.
>
> Now I just need to know if this link-local prefix case
> is one such issue. :-)
That I can't answer, since I've not had that one specifically thrown at
me as a test failure condition.
However, in a previous email I did indicate the two different ICMPv6
errors that could be generated. So I guess it's a case of see if this
was a TAHI failure, and if so then is it that TAHI want's to get a
'no route to destination' when 'address unreachable' should suffice.
DF
At Wed, 09 Oct 2002 16:24:38 -0700 (PDT),
++ David S. Miller <[email protected]> wrote:
> There are areas where the TAHI tests expect a certain behaviour
> when more than one behaviour is acceptable.
>
> Great, that's what I was trying to find out.
>
> Now I just need to know if this link-local prefix case
> is one such issue. :-)
No, there is no test item in TAHI test that supposes
link-local prefix is /64 :-)
The reason we change the prefix length from /10 to /64 is
following spec and adapting other imprementations.
-- Yuji Sekiya
On Thu, Oct 10, 2002 at 08:41:52AM +0900, Yuji Sekiya wrote:
>
> The reason we change the prefix length from /10 to /64 is
> following spec and adapting other imprementations.
I said I wouldn't comment futher on the spec issue.
I know of at least one other implementation that allows any set of bits
within the link local range to be specified. (Two if you include the
current/previous Linux behaviour :-)
Changing to restrict the allowed link local addresses doesn't _enhance_
interoperability. Leaving it as it is/was doesn't harm anything.
DF
At Wed, 09 Oct 2002 16:45:04 -0700 (PDT),
** David S. Miller <[email protected]> wrote:
> The reason we change the prefix length from /10 to /64 is
> following spec and adapting other imprementations.
>
> I think Derek's explanation shows that the specification
> allows the /10 behavior.
Hmm... we interpret the spec as /64 prefix.
> Also, I suspect that since Derek works for Cisco, some "other
> implementations" behave how he describes. :-)
I have cisco box which installed IPv6 IOS.
But it defines no prefix length at an interface,
FastEthernet4/1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::201:64FF:FEA3:ED55
and outgoing interface of routing table is NULL ? :-)
L FE80::/10 [0/0]
via ::, Null0, 7w0d
-- Yuji Sekiya
On Wed, Oct 09, 2002 at 04:45:04PM -0700, David S. Miller wrote:
> From: Yuji Sekiya <[email protected]>
> Date: Thu, 10 Oct 2002 08:41:52 +0900
>
> The reason we change the prefix length from /10 to /64 is
> following spec and adapting other imprementations.
>
> I think Derek's explanation shows that the specification
> allows the /10 behavior.
But as someone else pointed out (sorry I'm to lazy to check the thread),
one would still be able to manually adjust the Linux routing table to get it
into the /10 behaviour.
So frankly I'm not too fussed which behaviour is the default, I was just
pointing out (what to me seemed to be) a change of dubious quality.
(Then letting myself get into an argument over specs - when will I learn :-)
DF
From: Yuji Sekiya <[email protected]>
Date: Thu, 10 Oct 2002 08:41:52 +0900
The reason we change the prefix length from /10 to /64 is
following spec and adapting other imprementations.
I think Derek's explanation shows that the specification
allows the /10 behavior.
Also, I suspect that since Derek works for Cisco, some "other
implementations" behave how he describes. :-)
On Thu, Oct 10, 2002 at 09:00:34AM +0900, Yuji Sekiya wrote:
> At Wed, 09 Oct 2002 16:45:04 -0700 (PDT),
> ** David S. Miller <[email protected]> wrote:
>
> > The reason we change the prefix length from /10 to /64 is
> > following spec and adapting other imprementations.
> >
> > I think Derek's explanation shows that the specification
> > allows the /10 behavior.
>
> Hmm... we interpret the spec as /64 prefix.
>
> > Also, I suspect that since Derek works for Cisco, some "other
> > implementations" behave how he describes. :-)
>
> I have cisco box which installed IPv6 IOS.
> But it defines no prefix length at an interface,
>
> FastEthernet4/1 is up, line protocol is up
> IPv6 is enabled, link-local address is FE80::201:64FF:FEA3:ED55
>
> and outgoing interface of routing table is NULL ? :-)
>
> L FE80::/10 [0/0]
> via ::, Null0, 7w0d
Turn on 'debug ipv6 nd', 'debug ipv6 icmp', 'debug ipv6 pack d'
Then do 'ping ipv6' specify a link local of say fe80:1910::10 and
an egress interface, and watch what happens.
DF
At Thu, 10 Oct 2002 01:04:39 +0100,
Derek Fawcus <[email protected]> wrote:
> Turn on 'debug ipv6 nd', 'debug ipv6 icmp', 'debug ipv6 pack d'
>
> Then do 'ping ipv6' specify a link local of say fe80:1910::10 and
> an egress interface, and watch what happens.
OK.
Oct 10 09:09:15: ICMPv6-ND: DELETE -> INCMP: FE80:1910::10
Oct 10 09:09:15: ICMPv6-ND: Sending NS for FE80:1910::10 on FastEthernet4/1
Oct 10 09:09:15: IPV6: source FE80::201:64FF:FEA3:ED55 (local)
Oct 10 09:09:15: dest FF02::1:FF00:10 (FastEthernet4/1)
Oct 10 09:09:15: traffic class 224, flow 0x0, len 72+8, prot 58, hops 255, originating
Oct 10 09:09:15: IPv6: Sending on FastEthernet4/1
Oct 10 09:09:15: IPv6: Encapsulation failed
Encapsulation failed ... ??? :-)
-- Yuji Sekiya
On Thu, Oct 10, 2002 at 09:00:34AM +0900, Yuji Sekiya wrote:
>
> I have cisco box which installed IPv6 IOS.
Did I mention any specific names :-)
> But it defines no prefix length at an interface,
Not really suprising, it's meaningless.
> FastEthernet4/1 is up, line protocol is up
> IPv6 is enabled, link-local address is FE80::201:64FF:FEA3:ED55
>
> and outgoing interface of routing table is NULL ? :-)
>
> L FE80::/10 [0/0]
> via ::, Null0, 7w0d
Well, that prefix is on all ipv6 enabled interfaces. so again a bit
meaningless. Anyway, that's showing a Local entry not a connected entry.
DF
On Thu, Oct 10, 2002 at 09:14:45AM +0900, Yuji Sekiya wrote:
> At Thu, 10 Oct 2002 01:04:39 +0100,
> Derek Fawcus <[email protected]> wrote:
>
> > Turn on 'debug ipv6 nd', 'debug ipv6 icmp', 'debug ipv6 pack d'
> >
> > Then do 'ping ipv6' specify a link local of say fe80:1910::10 and
> > an egress interface, and watch what happens.
>
> OK.
>
> Oct 10 09:09:15: ICMPv6-ND: DELETE -> INCMP: FE80:1910::10
> Oct 10 09:09:15: ICMPv6-ND: Sending NS for FE80:1910::10 on FastEthernet4/1
> Oct 10 09:09:15: IPV6: source FE80::201:64FF:FEA3:ED55 (local)
> Oct 10 09:09:15: dest FF02::1:FF00:10 (FastEthernet4/1)
> Oct 10 09:09:15: traffic class 224, flow 0x0, len 72+8, prot 58, hops 255, originating
> Oct 10 09:09:15: IPv6: Sending on FastEthernet4/1
> Oct 10 09:09:15: IPv6: Encapsulation failed
>
> Encapsulation failed ... ??? :-)
Well there was no one to respond to the NS, so it couldn't figure out
what dest MAC address to shove in the ethernet packet. Hence the
ethernet encap failed.
Say if you sent such a packet over the link to the router, and it
tried to forward it without the neighbour being there, you should
get an ICMP error generated.
But anyway it was trying to resolve a neighbour entry, if someone
responded, it'd have sent the packet.
Now try it with a box on the link which will respond to the NS for that
address.
DF
At Thu, 10 Oct 2002 01:21:09 +0100,
Derek Fawcus <[email protected]> wrote:
> Now try it with a box on the link which will respond to the NS for that
> address.
OK. I have assigned fe80:1910::10/64 link-local address to
USAGI linux box and tried to ping ipv6.
Target IPv6 address: fe80:1910::10
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands? [no]:
Output Interface: FastEthernet4/1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80:1910::10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Oct 10 09:27:35: IPV6: source FE80::201:64FF:FEA3:ED55 (local)
Oct 10 09:27:35: dest FE80:1910::10 (FastEthernet4/1)
Oct 10 09:27:35: traffic class 224, flow 0x0, len 64+16, prot 58, hops 255, originating
Oct 10 09:27:35: IPv6: Sending on FastEthernet4/1
-- Yuji Sekiya
On Thu, Oct 10, 2002 at 09:35:26AM +0900, Yuji Sekiya wrote:
> OK. I have assigned fe80:1910::10/64 link-local address to
> USAGI linux box and tried to ping ipv6.
>
> Target IPv6 address: fe80:1910::10
> Repeat count [5]:
> Datagram size [100]:
> Timeout in seconds [2]:
> Extended commands? [no]:
> Output Interface: FastEthernet4/1
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to FE80:1910::10, timeout is 2 seconds:
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
>
> Oct 10 09:27:35: IPV6: source FE80::201:64FF:FEA3:ED55 (local)
> Oct 10 09:27:35: dest FE80:1910::10 (FastEthernet4/1)
> Oct 10 09:27:35: traffic class 224, flow 0x0, len 64+16, prot 58, hops 255, originating
> Oct 10 09:27:35: IPv6: Sending on FastEthernet4/1
Well what do you know? At least one implementation supports that type of
config.
Anyway, I as said in an earlier email, do whatever you want. I just
considered that change to be dubious.
DF
At Thu, 10 Oct 2002 01:42:37 +0100,
Derek Fawcus <[email protected]> wrote:
> Well what do you know? At least one implementation supports that type of
> config.
???
I can underdtand there is no interoperability issue with cisco box
(with /10 link-local prefix ?) and USAGI kernel(with /64 link-local
prefix). :-)
-- Yuji Sekiya
On Thu, Oct 10, 2002 at 09:56:24AM +0900, Yuji Sekiya wrote:
>
> I can underdtand there is no interoperability issue with cisco box
> (with /10 link-local prefix ?) and USAGI kernel(with /64 link-local
> prefix). :-)
Mind it's interesting that the above currently works. I suspect that
this is because the ping was originated on the cisco box, and hence
ND was triggered, with the linux box probably gleaning info from the
NS to create a STALE entry. That STALE entry would then probably have
been probed to get a REACHABLE entry.
What happens if you clear the ND entries (on both boxes), swap the
link local addresses, then ping from the Linux box to the cisco box?
I suspect that the ping will fail. As ND will never be triggered, and
hence the host routes will not be created.
Another alternative would be if one was say fe80:1910::10 and the other
say fe80:2010::20, that would probably fail with the ping originated
from the linux end, but I'm not sure if the linux box would respond
when the ping was originated from the cisco end. Assuming my guess
about the gleaning above is correct, it probably will.
DF