YOSHIFUJI Hideaki / ???? wrote:
ip6_output2() doesn't resolve link-layer addresses. We don't even have a
In article <4023D6FB.9010909@xxxxxxxxxxx> (at Fri, 06 Feb 2004 20:03:39 +0200), Mika
Penttilä <mika.penttila@xxxxxxxxxxx> says:
Kazunori Miyazawa wrote:
Yoshifuji-san and I send the patch which unifies IPv6 output routine and remove
RTF_NDISC again. It resolves an issue of IPv6 IPsec with neighbor discovery
without a flag.
You break multicast replies, see what ndisc_build_ll_hdr() does...
It doesn't "break."
The ip6_output2() resolves and inserts link-layer address appropriately.
If it did, we would have noticed (by conformance test or even by
usual operation). ;-)
ndisc_dst_alloc(dev, NULL, ip6_output2); case.
BTW, Miyazawa-san, we do not need ndisc_build_ll_hdr() anymore.
Compiler warns it. Please remove it. Thanks.
Here's the description:
dst->neighbour owns the neighbour entry for the destination.
For multicast, we know its link-layer address
(filled in ndisc_constructor()).
For unicast, the link-layer address may be unknown.
ip6_output2() will call ip6_output_finish() and
it tries inserting the link-layer header.
The destination link-layer address is used if it is known (*).
(Note: you remember that we know link-layer address for multicast.)
If the link-layer address is not known or invalid,
we queue the packet and resolve the link-layer address for the destination.
Here, since the neighbour entry is "invalid," *multicast* NS is sent.
The NS packet passes similar path.
We know the destination for the NS is multicast and
what the link-layer address is, and the packet is sent via (*).
We will send the queued packet when we got NA from that node.
A node may send NS without source link-layer address option
while we do not know the link-layer address for the source of the NS.
We need to send NA in reply to this NS.
Original code cannot handle this case. The new code path can.
You just described how the normal link layer address resolving goes. It
doesn't apply here. Again, there is no dst->neighbour.