Re: [PATCH][IPV6][NDISC] unify ipv6 output routine

["Mika Penttilä" <mika.penttila@kolumbus.fi>]

YOSHIFUJI Hideaki / ???? wrote:

>In article <4023D6FB.9010909@kolumbus.fi> (at Fri, 06 Feb 2004 20:03:39 +0200), Mika Penttilä <mika.penttila@kolumbus.fi> 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). ;-)
>  
>
ip6_output2() doesn't resolve link-layer addresses. We don't even have a 
neighbour, in

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.
>
>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.
>  
>

You just described how the normal link layer address resolving goes. It 
doesn't apply here. Again, there is no dst->neighbour.



--Mika