> I have one issue with APPENDIX A.  The direct mention of the on-link
 > assumption was removed from the appendix (from the second bullet item
 > 1), but it is still implied by the text that remains.  The text is:
 > 
 >      1) If no Router Advertisement is received on any interfaces, a
 >         multihomed host will have no way of knowing which 
 > interface to
 >         send packets out on, even for on-link destinations.
 >         One possible approach for a multihomed node would be 
 > to attempt
 >         to perform address resolution on all interfaces, a step
 >         involving significant complexity.
 > 
 > Why would a multihomed host ever attempt to perform any address
 > resolution on any interface unless it assumed that the 
 > destination was
 > on-link on one of those interfaces?  It should not make this 
 > assumption
 > at all.  While the text is accurate in stating that this involves
 > significant complexity, it should not suggest that doing 
 > on-link address
 > resolution for a node to which it has no route is a "possible
 > approach".  If you're multihomed and you have no route to a 
 > destination,
 > then send back an ICMP destination unreachable.  It should 
 > be as simple
 > as that.

=> How do you know if you have no route to the destination?
Could it not be on one of the links? The difference is that
this case does not _assume_ that the destination is on-link, which
was there before. 

In any case, this issue was discussed with Jinmei last week and 
here is the suggested text that we agreed on. Please let me know
if you have a comment:

>> 1) If no Router Advertisement is received on any interfaces, a
>> multihomed host will have no way of knowing which 
>> interface to
>> send packets out on, even for on-link destinations.  One
>> possible approach for a multihomed node would be to 
>> attempt to
>> perform address resolution on all interfaces.  The same
>> argument applies to a singlehomed node that does not receive
>> any Router Advertisement, but the step in the multihomed case
>> involves significant complexity.


Hesham

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to