ip6_output(): routing link local addresses

[Edgar Fuß]

Can someone in the know give me please give a clue how ip6_output() routes
link-local addresses? I can't find any special case in there or in
in6_selectroute()/selectroute() for that.
Is there some magic elsewhere in the routing cache or what do I overlook?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ignatios Souvatzis]

Post by Edgar Fuß
Can someone in the know give me please give a clue how ip6_output() routes
link-local addresses? I can't find any special case in there or in
in6_selectroute()/selectroute() for that.
Is there some magic elsewhere in the routing cache or what do I overlook?

Not having looked at the code recently - but: why should there be?
They're still IPv6 (L3) addresses and use the same mechanism as
the others, go through neighbor discovery, etc.

The only magic involved is that functions like Neighbour Discovery use
(one of) the link-local address as the sender for the _transport_, and
the src/dst scope comparison.

Route selection is then done through the normal in6_selectroute()
mechanism, which is a call to selectroute().

Regards,
-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Edgar Fuß]

Post by Ignatios Souvatzis
but: why should there be?

Because you need to take the scope into account.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Edgar Fuß

Post by Ignatios Souvatzis
but: why should there be?

Because you need to take the scope into account.

(From memory, fuzzy.)

Link-local addresses look like

fe80::stuff

when sent *on the link*. However, such an address used not on a link
does not obviously correspond to any particular link.

So, you see something like

fe80::stuff%fxp0

when printed, and this is doing some magic stuffing the ifindex byte for
fxp0 in a byte in the address (low byte of the top half?) that is
otherwise must-be-zero. This is how it's in the routing table, and the
addresses are munged on the way out/in so they are in this form for
applications and in standard form on the wire.

I probably misremember somewhat, but this is highly likely a useful
clue.

[Edgar Fuß]

and this is doing some magic stuffing the ifindex byte for fxp0

That's the (32 bit) zone/scope id.

in a byte in the address (low byte of the top half?)

Second-to-top 16-bit word (addr16[1]).

This is how it's in the routing table

A-ha! Thanks.
Can someone elaborate on how these magic routing table entries look like?

but this is highly likely a useful clue.

Yes. I did notice the stuffing and unstuffing but didn't consider the routing
table might contain these KAME-munged addresses.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Edgar Fuß]

So which of the two forms (scope in sin6_scope_id or KAME-stuffed into
sin6_addr) do the rt* routines expect?
My impression is that although rtcache_setdst() takes a sockaddr (as do
rtalloc() and rt_matchaddr()), they in the end (via rtoffset) only operate
on sin6_addr, so the would need the KAME-stuffed form.
But that would mean I either overlook something or even the relativey
high-level ip6_output() routine would need to be called with the
KAME-stuffed form.

The point I'm asking all this is that I'm investigating why ipf fails to
send TCP RSTs over link-local addresses. I've tracked this down as far as
that ipf6_fastroute() calls nd6_output() with a gateway route, causing
EHOSTUNREACH. My impression is that ipf_fastroute6() fails to tell the
routing routines about the LL scope -- I just don't know whether it should
do the KAME stuffing before calling the routing routines or whether it
should call rtcache_setdst() with sin6_scope_id filled in?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Edgar Fuß]

Post by Edgar Fuß
The point I'm asking all this is that I'm investigating why ipf fails to
send TCP RSTs over link-local addresses. I've tracked this down as far as
that ipf6_fastroute() calls nd6_output() with a gateway route, causing
EHOSTUNREACH. My impression is that ipf_fastroute6() fails to tell the
routing routines about the LL scope -- I just don't know whether it should
do the KAME stuffing before calling the routing routines or whether it
should call rtcache_setdst() with sin6_scope_id filled in?

Stuffing the scope into addr16[1] makes it work (for me).
I tested this on 7.1; I can't tell whether the pre-4.99.11 part is correct.

Shall I file a PR?

[神明達哉]

At Thu, 20 Jul 2017 15:08:34 +0200,

Post by Edgar Fuß

Post by Edgar Fuß
The point I'm asking all this is that I'm investigating why ipf fails to
send TCP RSTs over link-local addresses. I've tracked this down as far as
that ipf6_fastroute() calls nd6_output() with a gateway route, causing
EHOSTUNREACH. My impression is that ipf_fastroute6() fails to tell the
routing routines about the LL scope -- I just don't know whether it should
do the KAME stuffing before calling the routing routines or whether it
should call rtcache_setdst() with sin6_scope_id filled in?

Stuffing the scope into addr16[1] makes it work (for me).
I tested this on 7.1; I can't tell whether the pre-4.99.11 part is correct.

I suggest using utility functions defined in scope6.c instead of

Post by Edgar Fuß
+ /* KAME */
+ if (IN6_IS_ADDR_LINKLOCAL(&u.dst6.sin6_addr))
+ u.dst6.sin6_addr.s6_addr16[1] = htons(ifp->if_index);

These two lines could (should) be:

if ((error = in6_setscope(&u.dst6.sin6_addr, ifp,
&u.dst6.sin6_scope_id)) != 0)
goto bad;
if ((error = sa6_embedscope(&u.dst6, 0)) != 0)
goto bad;

It tries to hide as many implementation details as possible, and also
covers other types of IPv6 scoped addresses (in practice unicast
link-local may be the only type you're interested in, but in principle
you'd need to expect it could be, e.g., a scoped multicast address).

--
JINMEI, Tatuya

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Edgar Fuß]

Post by 神明達哉
I suggest using utility functions defined in scope6.c instead of

In the end, probably yes. I just changed the code as little as poosible.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Edgar Fuß]

Post by Edgar Fuß
Shall I file a PR?

kern/52469.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de