Subject: RE: 2461bis update

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 1 Jun 2005 14:11:23 -0400

> On Wed, 2005-06-01 at 12:16, Soliman, Hesham wrote:
 > > => How do you know if you have no route to the destination?
 > 
 > You consult your forwarding table.
 > 
 > > Could it not be on one of the links?
 > 
 > It could be if you have a forwarding table entry that points 
 > to one or
 > more of your local interfaces.
 > 
 > >  The difference is that
 > > this case does not _assume_ that the destination is on-link, which
 > > was there before. 
 > 
 > I does assume that that the destination is on-link.  In 
 > outbound packet
 > processing, you don't attempt to do link-layer address 
 > resolution until
 > you've done the forwarding table lookup and done on-link 
 > determination.

=> I'll try to answer all of the above here if possible:
The text does not say that you should do address resolution 
before consulting your neighbor cache or forwarding table and do
on-link determination. Although, this can probably be made clearer. 
So, I think the clarification needed is in the order of steps. I.e.
The current text seems to skip a couple of steps.

 > 
 > > 
 > > 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.
 > 
 > The same argument does not apply to single homed nodes.  The point of
 > removing the on-link assumption was to make sure the node 
 > does _not_ do
 > address resolution in the absence of a route to the destination.  Are
 > you saying that it's ok to do that if you have more than one network
 > interface?  That's how I read this text.

=> You seem to make this assumption because the text does not explicitly
spell out the order of events. Would it be clearer if the text explains 
that address resolution is only done if the on-link determination 
process indicates that the destination is onlink? If you agree with this 
I can send suggested text.

Hesham

 > -Seb

===========================================================
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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Sebastien Roy <[email-masked]>
Date: Wed, 01 Jun 2005 14:22:14 -0400

> The current text seems to skip a couple of steps.

Maybe, but I don't see the need for the text at all.  If implementors
want to play cute games with ND, then let them.

> I can send suggested text.

It would be better than what's there now, but ideally, the text should
just be removed entirely.  Doing address resolution on multiple links
can lead to ambiguous results.  There could be multiple destinations
responding to the same address, and you don't know which one you're
talking to.  This hasn't been studied enough to even be mentioned.  If
particular implementations want to do this, they can.  There's nothing
in the spec that prevents them from doing it.

Please consider removing the text as Jinmei has already suggested in
previous posts (and I apologize for having missed those messages last
week).

Thanks,
-Seb

---

From: "Radhakrishnan.S" <[email-masked]>
Date: Thu, 02 Jun 2005 18:10:51 +0530

<snip>

> previous posts (and I apologize for having missed those messages last

Even i support the removal of text. I had raised this during a discussion in 
v6ops mailing list and Jinmei had told that time its getting removed.