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). ;-)
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.
Real story:
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.
--
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@xxxxxxxxxxxxxx>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
|